Your AI Agent Is Already Privileged

Anthropic recently launched Claude Tag, a shared agent that lives inside Slack and takes work from anyone in the channel. Agents are moving into the SaaS platforms teams already use, and many of them are assembled on those platforms without ever touching an access review. Somewhere in your organization, one was approved this month, and it looked routine: read access to the incoming issue queue, read access to source repositories, permission to open pull requests, permission to post in the engineering Slack channel. Each request had a justification and an owner, and each was approved on its own merits. This is the standard access package for a coding agent.

What nobody reviewed was the combination. The workflow behind those permissions is not a script executing a fixed sequence of calls. It is an agent: a model connected to tools, triggered by incoming issues, deciding on its own which systems to call and in what order. It does not hold an admin role. It holds the practical power of a privileged operator, accumulated one routine approval at a time.

The harmless service account

Security teams have a mature process for access review. A request arrives, an owner approves it, and the permission lands on an identity. The review asks a single question: what may this identity access? The answer is a list: this issue queue, those repositories, this Slack channel. Every item on our coding agent's list passed that review. The repository access was read-only, pull requests still required human review, the Slack channel was where the team already worked, and the issue queue was the job itself.

The limitation is structural, not procedural. The list describes permissions, not outcomes. It does not describe what those permissions become when one actor holds all of them, moves between them at machine speed, and decides for itself when to use each one. The reviewers did their jobs correctly; the review was designed for a different kind of actor.

Mature programs do review some combinations. Segregation of duties analysis has flagged toxic pairings for two decades. "Create vendor" plus "pay vendor" is the canonical example. But those rules live inside role definitions and assume a human on each side of the split. The residual risk they accept is collusion between two people. An agent collapses the entire chain into one identity executing one workflow. The toxic combination is no longer two users conspiring; it is the default operating mode.

Application or operator?

A traditional application with these permissions is predictable. It executes the calls developers wired into it, in the order they wired them, and its blast radius is roughly the sum of its functions. Code review bounds its behavior before it ever runs.

An agent does not work this way. Given an ambiguous instruction like "fix this bug," it decides which repositories to read, what to change, and what to write in the pull request. Two similar issues can produce two entirely different sequences of calls. Its behavior is bounded by its instructions, its tools, and its judgment. Judgment is precisely what access reviews were never designed to evaluate. We grant applications permissions. We grant operators trust in their judgment. An agent holds both.

Inherited credentials

On paper, the agent acts through a service identity with limited scopes. The label keeps changing: service account, machine identity, workload identity, and now non-human identity. The substance does not. It is an identity that acts whether or not anyone is watching. In practice, the agent carries the full weight of the combined scopes into every action it takes, and everyone who can reach the agent holds some influence over how those scopes get used: every engineer, every issue author, every external contributor who files a bug against a public repository.

Teams usually mis-assign this identity in one of two ways. The first gives the agent its own account with broad permissions so the demo works, and the team discovers later that anyone who can reach the agent can reach everything it can. The second has the agent inherit the user's full access, which feels safe until one injected instruction cascades through every system that user can touch. The right answer is narrower than either: an identity scoped to the workflow, with authority evaluated on every action.

Those outside issue authors deserve attention, because they include attackers who never touch the identity at all. In our own DERAIL research, adaptive prompt injections steered tool-using agents past judge-based defenses using nothing more than content the agent was asked to read. This is not only a laboratory result. In the GitHub MCP exploit that Invariant Labs disclosed last year, a malicious issue in a public repository steered a developer's agent into private repositories and exfiltrated what it found through a public pull request. The attacker did not need to steal the agent's credentials or phish a human. The agent already held the credentials, and the issue text did the rest.

It was not a one-off. Our own Notion exploit research found the same shape inside Notion 3.0's AI agents: an indirect prompt injection turned the agent's web search tool into an exfiltration channel for workspace data. Same pattern, different stack: untrusted content in, private data out, through a channel the agent already controlled.

Tools multiply authority

Each connection multiplies the value of the others. Repository read access becomes more sensitive once the same actor can open pull requests, because source code now has a destination. A pull request in a public repository is public the moment it exists; the review gate arrives after the exposure. The issue queue becomes more dangerous once the same actor can read private repositories, because an attacker can choose what the agent reads next. And the queue that triggers the whole workflow is itself an input any GitHub user can write to. A message from the agent in the engineering channel carries the team's own legitimacy, so the agent can work the humans in the loop, not just the systems.

Simon Willison gave this pattern a name: the lethal trifecta. An agent that can reach private data, ingest untrusted content, and communicate externally has everything an attacker needs, and our coding agent holds all three by design. Four permissions, each modest in isolation, assemble into one operator that can read the private repositories, open pull requests with a plausible justification, and post as the team in the channel engineers trust.

The combination, not any single scope, is the privilege. This is what the access review should have measured.

Autonomy changes privilege

Privilege has always had a time dimension. A privileged human works a shift, from a known device, in one session at a time. An agent operates continuously, in parallel, at machine speed, across every connected system, triggered by issues, comments, webhooks, and schedules, including inputs an attacker can influence.

The same permission set is therefore more powerful in an agent's hands than in a person's. Not because the permissions changed, but because the operator did. A control model built around human pacing, human attention, and human working hours underestimates what an autonomous operator can do with identical authority.

The hidden blast radius

When this agent goes wrong, whether manipulated, misconfigured, or simply mistaken, the incident will not look like an application error. It will look like a rogue operator: pull requests that went public before anyone reviewed them, source code sent externally, and messages that genuinely did come from your engineering Slack channel. The review trail will show four approved permissions and no record of anyone evaluating the combination, because no such evaluation ever took place.

Count privilege the way agents hold it

The standards conversation is circling the same problem. The NIST AI Agent Standards Initiative treats agent identity and authorization as first-class concerns, and the OWASP Agentic Security Initiative focuses on exactly these autonomous, tool-using workflows. Neither hands you the measurement, but both confirm the direction. Anthropic's CISO guide to agentic AI asks four similar questions of every agentic use case. The frameworks converge because the gap is the same.

The fix starts with evaluating agents the way privileged operators are evaluated. Four questions cover most of the gap:

• What can this agent reach in total, across every system it can call?
• Which outcomes can those combined permissions produce, such as code shipped, data sent, or access changed?
• Who or what can trigger it, and can those triggers be influenced?
• What evidence records its actions, and would anyone review it in time?

If the honest answers described a person, that person would already be managed as privileged: credentials vaulted, sessions recorded, sensitive actions gated behind approval, access re-certified on a schedule. The coding agent your team rolled out last sprint has not asked for any of that. It does not need to ask. It already has the access.

The question worth taking to your next access review is a simple one: which agents already hold the combined authority of a privileged operator?

Where CodeIntegrity fits

CodeIntegrity builds runtime controls for exactly this layer: evaluating tool calls before they execute, enforcing policy around sensitive actions, preserving provenance across data and instructions, and producing evidence for everything an agent does. If your agents hold combined authority, book a demo to see how to govern it.