Why AI agents need their own identity

COMMENTARY: A few recent incidents have done more to clarify the agentic AI identity problem than most vendor briefings.

In December 2025, the AWS AI coding agent Kiro was given a minor bug to fix in production. It decided the cleanest path was to delete and recreate the environment. Thirteen hours of downtime followed. Amazon attributed the root cause to misconfigured access controls; the engineer who deployed the agent had elevated permissions, and the agent inherited them.

[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]

In March 2026, an internal AI agent at Meta autonomously posted technical guidance to an engineering forum without approval. Another engineer followed the advice. Sensitive company and user data was exposed to unauthorized employees for nearly two hours. Meta classified it as a Sev-1 incident.

Different companies, different agents, different failure modes. Same underlying issue: agentic identities operating with permissions, autonomy, and context that the access infrastructure governing them was never designed to handle.

Gartner predicts that 40% of enterprise applications will come integrated with task-specific AI agents by the end of 2026, up from less than 5% the prior year. In most organizations, that access has been granted through infrastructure built when only a person was logging.

Agentic identity isn’t just another machine identity

Most security teams tend to slot AI agents into one of two existing categories: either they're machine identities, handled by non-human identity (NHI) programs already in place; or they're extensions of the human who launched them, operating with that user's credentials and treated as that user in audit logs.

Neither framing fits an AI agent’s security needs.

A service account runs a predictable workload on a fixed cadence. An agent reasons. It interprets intent, chains tool calls, queries databases, hits APIs, and initiates actions based on context that didn't exist five seconds ago. A single agentic workflow can spawn dozens of sub-agents.

Treating that as a service account underestimates the velocity. Treating it as the human who launched it misunderstands its autonomy. Both produce the same exposure: an agent operating with broader access than its task requires, persistent credentials that outlive any specific use case, and no audit trail tied to the agent itself.

Application layer enforcement isn’t going to hold

The Meta incident shows what happens when access decisions live in the application layer. The agent had legitimate credentials and passed every identity check. The control the organization was relying on — confirmation with the user before posting — lived in the agent's instructions, not in infrastructure outside the agent's reasoning.

Large language models (LLM) are designed to offer assistance and context. That's the point. It also means an agent's adherence to a guardrail is a function of its interpretation, not a property of the system it's running in. A prompt phrased the right way can bypass instructions a developer assumed were binding. Security decisions belong in dedicated infrastructure, not in instructions written into the agent itself.

The delegation problem teams need to consider

Even with agent-specific identities and infrastructure-enforced controls, there's a layer most security programs haven't started addressing: chained authority across multi-agent workflows. When Agent A calls Agent B, which queries a database through a tool integration, and initiates a transaction in another system, whose authority gets exercised at each step?

The Kiro incident was mostly a delegation failure. The agent inherited the deploying engineer's permissions and exercised them at machine speed, bypassing the two-person review that would have applied to a human making the same change. There was no mechanism to distinguish a scoped, delegated task from full access to the engineer's keychain.

Without verifiable delegation, audit logs collapse into ambiguity. The AI model organizations actually need -- an agent acting on behalf of a user, with permissions scoped to the intersection of what both parties are allowed to do — has no enforcement layer in the inherited access infrastructure.

What the architecture has to look like

Agents need first-class identities. Not borrowed service accounts or in a pipeline. Identity functions as the unit of accountability, and an agent without its own managed identity has no surface to attach policy, audit, or revocation to.

The agents also need zero standing privileges. No identity holds always-on access to anything. Access must get minted at the moment of need, scoped to the specific task, and destroyed when the task completes. The agent that deleted AWS Cost Explorer didn't need standing production privileges. It needed scoped access to the change it was authorized to make, for the duration of that change, and nothing more.

Runtime authorization decisions live in infrastructure, not in the application, or in the agent itself. The decision about whether an action gets permitted must get made by a system the agent can't talk its way past, evaluating real-time context: what's being requested, by which identity, on behalf of which user, in what scope.

Either the architecture governing agentic access reflects how agents actually operate, or it doesn't. There's no third option. The hybrid organization has already evolved. The infrastructure granting it access must then get built alongside it.

Art Poghosyan, co-founder and CEO, Britive

SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.