AI Colleagues Are Here—But Is Your Access Control Still Designed for Humans?
Deep thoughts on AI and aspirations —— ByteDance Deep Thinking Circle
Two events converged, making it clear that a certain problem can no longer be ignored. Enterprise data security company Cyera announced it would acquire Oasis Security, a non-human identity management provider, for approximately $1 billion. Around the same time, Anthropic launched Claude tags, allowing team members to @Claude directly in Slack to delegate tasks. A billion-dollar acquisition and a feature embedded into daily workflows both point to the same reality: Agent identity and permissions are shifting from technical discussions to security questions enterprises must answer.
Most enterprises aren’t ready. Okta’s 2025 survey found that 91% of organizations have already begun using AI agents, but only 10% have developed comprehensive non-human identity management strategies. Ninety percent are using them, ten percent are prepared—this gap is an exposure.
Agents Are Software That Can’t Be Audited in Advance
To understand why old permission systems fail, we need to see how agents differ from traditional programs.
Traditional programs have enumerable behavior: humans make judgments first, write code, and the program executes according to that code. Security teams audit the code once and roughly know what it will access and do. But agents work differently. They receive a goal—say, “there’s a production issue, check logs, create an issue, fix it, submit a PR”—and once running, they decide the next step themselves based on current context, available tools, and previous results. The same goal might produce different execution paths each time.
This creates several concrete problems. Developers can’t list which systems it will touch before runtime because tools are discovered during the model’s reasoning process. Agents operate continuously across systems, each with its own permissions and logs. Each step might be compliant individually, but the combination can cause problems—for instance, it legitimately reads logs, creates a ticket, submits a PR, but writes personal information from the logs into the ticket and references it in a public PR, creating a leak. It might also delegate tasks to downstream agents, with each handoff losing some of the original delegation context. By the time the request reaches the end of the chain, the executor no longer knows who initiated the task.
More practically, there’s speed. Agents work much faster than humans. Once you run many simultaneously or let them handle long-running tasks, humans simply can’t review each action. If every operation triggers a confirmation dialog, users quickly develop approval fatigue, clicking allow without looking. Once approval becomes a formality, it’s effectively non-existent.
Old Access Control Only Recognizes Two Types of “People”
Enterprise identity systems are basically designed for two types of entities.
One is employee accounts: verifying who you are, then granting relatively fixed permissions based on role and position. It assumes humans will judge before acting. The other is application and service credentials: identifying a specific program, assuming its behavior is determined by pre-written code.
Agents fall into the gap between these two. They act on behalf of people, requiring human identity to clarify “who they’re working for.” Yet they run as software, needing application identity to call systems. Either framework alone describes them incompletely.
The most common current approach has bigger problems: many agents access systems via long-lived API keys, with credentials placed directly in their accessible runtime environments. Once an agent gets this key, it can use all the permissions inside, even if the current task only requires one small action. Security professionals call this ambient authority—agents directly inherit all available permissions in the runtime environment.
A demonstration case illustrates the problem well. Someone asked a nighttime incident management agent to process five consecutive tickets: renew certificates, delete billing database, restart production service, scale up. Its cloud service credentials could renew, restart, scale, and drop databases. When processing the database deletion ticket, it deleted directly without confirming backup existence. One key opens all doors—this is the nature of long-term credentials: permissions are fixed before the task begins, regardless of whether the task actually needs them.
What’s Really Changed Is When Authorization Happens
Grouping these issues together reveals the core shift: the timing of when authorization occurs has changed.
Traditional systems authorize once. They check at login or credential issuance, then remain valid long-term. But agent authorization must move from “the moment credentials are issued” to “before each actual operation.” Systems must reconfirm before it acts: who it represents, which resource it’s accessing, what operation it wants to perform, what context the current task provides, then decide whether to allow it and how much access to grant.
In other words, permissions are shifting from “attributes of identity” to “attributes of tasks.” The same key is no longer permanently attached to your belt but issued temporarily for each step and revoked after use. The industry calls this state of permissions expiring after task completion “zero standing privileges” and this approach of adjusting authorization progressively “progressive trust.” The names don’t matter; the direction is consistent: authorization for agents is moving from one-time access control to a continuous decision control plane.
This is hard because it requires changing the timing mechanism of the entire identity infrastructure—fixing one or two features won’t solve it. That’s why this field is spawning new companies: some entering from “first inventory what agents, credentials, and service accounts exist in the enterprise,” others from “issue short-term credentials on-the-fly at each tool invocation.” Large companies aren’t idle either—Microsoft and Okta are both managing agents as a new type of identity object. The direction is largely aligned, just different entry points.
But Don’t Lock the Door Too Tight
At this point we need to pull back and not push conclusions too far.
The tighter permissions are managed, the more agents must request, wait, and get rejected at every step, the more their efficiency drops. Security exists so agents can be used with confidence. If we close the door completely, we’re essentially choosing not to work to avoid problems. The balance hasn’t been standardized by the industry itself yet—which context should inform authorization decisions currently lacks consensus even among practitioners. Authorization specifications for agents are still proposals or just starting, far from convergence.
So a more realistic path is to first establish a safe zone: let a few approved agents run within limited tool and resource scopes. When new agents or tools want to connect, decide case-by-case what to open, then gradually expand. Don’t wait for a perfect standard, but don’t roll out everything at scale from the start. Get part of it working first, then discuss governance refinement.
Three Things Enterprises Can Do Now
For enterprises genuinely introducing agents, three things can be done now without waiting for standards.
First, inventory long-term credentials on hand. Check which API keys and connection strings are scattered in agent runtime environments and which systems each can access. Many risks aren’t brought by agents—they already existed, they’re just amplified by agents.
Second, register agents as independent entities rather than mixing them under employee accounts. Record who they represent, which systems they can enter, and who’s responsible. This way audit logs can answer “which agent did this operation, for whom” instead of attributing everything to some employee.
Third, leave the switch for high-risk operations to humans. Actions like database deletion, production restarts, and scaling should default to manual confirmation, and the system must verify that the person approving actually has that permission themselves. Authorization can be dynamic, but accountability cannot be suspended.
Agents entering enterprises can no longer be stopped. For things that can’t be stopped, rules must be established first. Whoever figures out how to manage the issuance and revocation of keys will be the one who can truly delegate the work.