AI Colleagues Are On Board, But Is Company Access Control Still Designed for Humans?
Deep thoughts on AI and aspirations —— ByteDance Deep Thinking Circle
Two events happening together make it clear that a certain problem can no longer be avoided. Enterprise data security company Cyera announced it would acquire Oasis Security, which specializes in non-human identity management, for approximately $1 billion. Almost simultaneously, Anthropic launched Claude tags, allowing team members to directly @Claude in Slack to assign tasks. A billion-dollar acquisition and a feature embedded into daily workflow both point to the same thing: Agent identity and permissions are evolving from a technical discussion into a security question that enterprises must answer.
Most enterprises are not ready. Okta’s 2025 survey shows that 91% of surveyed organizations have started using AI agents, but only 10% have developed relatively comprehensive non-human identity management strategies. Nine out of ten are using them, one in ten is prepared—this gap is a risk exposure.
Agents Are Software That Cannot Be Pre-Audited
To understand why old permission systems fail, we must first see the difference between Agents and traditional programs.
Traditional program behavior can be enumerated: humans make decisions first, write fixed code, and programs execute according to code. Security teams review the code once and roughly know what it will access and do. But Agents are different. They only receive a goal, such as “there’s a problem in production, check logs, create an issue, fix it, submit a PR.” When actually running, they must combine current context, available tools, and previous step results to decide which system to access next and what tools to call. The same goal might result in different execution paths each time.
This brings several specific problems. Developers cannot list which systems it will touch before runtime because tools are discovered during the model’s reasoning process. It will operate continuously across systems, and each system manages its own permissions and logs. Each step might be compliant individually, but combined they could cause problems—for instance, it compliantly reads logs, creates a ticket, submits a PR, but writes personal information from logs into the ticket and references it in a public PR, causing a leak. It might also delegate tasks to another layer of Agents; with each handoff, some of the original delegation information is lost. By the time the request reaches the end of the chain, the executor no longer knows who originally asked for the work.
A more practical point is speed. Agents work much faster than humans. Once many run simultaneously or you let them handle long tasks, humans simply cannot approve each action in time. If every operation triggers a confirmation dialog, users quickly develop approval fatigue and just click allow without looking. Once approval becomes a formality, it’s essentially no approval at all.
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 giving you relatively fixed permissions based on position and role. The assumption is that people will judge whether they should act before taking action. The other is application and service credentials, identifying a specific program, assuming its behavior is determined by pre-written code.
Agents fall precisely in the gap between the two. They act on behalf of people and need a human identity to clarify “whom they’re working for.” They also run as software and need an application identity to call systems. Taking either set alone to describe them is incomplete.
The most common current approach has even bigger problems: many Agents access systems via long-lived API keys, with the keys placed directly in the runtime environment where they can read them. Once an Agent gets this key, it can use all the permissions within, even if the current task only needs to do one small thing. The security field calls this state ambient authority—the Agent directly inherits all existing permissions in the runtime environment.
A demonstration case illustrates the problem well. Someone asked an incident management Agent running overnight to handle five tickets consecutively: renew certificates, delete billing database, restart production service, scale up. The cloud service key it held could renew, restart, scale up, and delete databases. When processing the database deletion ticket, it directly deleted without being able to confirm whether backups existed. One key opens all doors—that’s the essence of long-term credentials: permissions are fixed before the task begins, regardless of whether the task actually needs them.
What Really Changed Is When Authorization Happens
Gathering these problems together reveals the core is actually one thing: the timing of when authorization happens has changed.
Traditional system authorization is one-time. It’s judged once at login or when issuing credentials, then remains valid long-term. But Agent authorization decisions must move from “the moment credentials are issued” to “before each actual operation.” The system reconfirms before it acts: whom does it represent, which resource will it access, what operation does it want to execute, what context has the current task provided, then decides whether to allow and how much.
In other words, permissions are shifting from “an attribute of identity” to “an attribute of the task.” The same key is no longer hung on the belt long-term but temporarily issued at each step and revoked after use. The industry calls this state where permissions expire after task completion “zero standing privileges,” and this approach of adjusting authorization step-by-step “progressive trust.” The names don’t matter; the direction is consistent: authorization given to Agents is changing from one-time access control to a continuous decision-making control plane.
This is hard because it requires changing the decision timing of the entire identity infrastructure; fixing one or two features won’t solve it. This is also why a batch of new companies is emerging in this field: some cut in from “first inventory what Agents, credentials, and service accounts exist in the enterprise,” others from “issuing short-term credentials on-site at each tool invocation.” Large companies are also busy, with Microsoft and Okta both managing Agents as a new type of identity object. The direction is basically consistent, just different entry points.
But Don’t Lock the Door Too Tight Either
At this point, we should pull back and not push the conclusion too far.
The more finely permissions are managed, the more each Agent step requires application, waiting, and rejection, the more its efficiency drops. Security exists so Agents can be used with confidence. If the door is closed shut, it’s equivalent to not working at all to avoid incidents. The industry itself doesn’t have a standard answer for where to draw this line—which contexts should enter authorization decisions currently has no unified conclusion even among practitioners; authorization specifications for Agents are still proposals or just starting, far from convergence.
So a more realistic path is to first delineate a security zone: let a small number of approved Agents run within a limited scope of tools and resources; when new Agents or tools want access, decide item by item what to open, then gradually expand. Don’t wait for a perfect standard, and don’t roll out full-scale from the start. Get some running first, then discuss refined governance.
Three Things Enterprises Can Do Now
For enterprises truly introducing Agents, three things don’t require waiting for standards and can be started now.
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, just amplified by Agents.
Second, register Agents as independent entities rather than mixing them under employee accounts. Record whom they represent, which systems they can enter, and who’s responsible. This way audit logs can answer “which Agent did this operation and for whom,” rather than attributing everything to an employee.
Third, leave the switch for high-risk operations to humans. Actions like database deletion, production restart, and scaling should require manual confirmation by default; and the system must also check whether the person clicking approve actually has that permission. Authorization can be dynamic, but accountability cannot be suspended.
The entry of Agents into 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 first will dare to truly delegate the work.