AI agents are new identities in your landscape

AI-generated content: this article was created with AI.

When an agent places an order, updates a customer record or sends an email, someone acted. In many organisations, the honest answer to the question of who that was is: a shared API key. One credential, configured once, used by several agents and sometimes by several teams. It works in a pilot. In production, it creates a security and audit problem that grows with every additional agent.

A shared key cannot be attributed. The target system sees the same caller for every agent and every user. It cannot be rotated per agent, because rotation affects everyone who uses it. It cannot be revoked selectively, because revoking it stops all agents at once. And in an audit, the question of who actually acted, and on whose behalf, stays open. For a CISO, this is the same problem as a shared administrator account, with the added complication that the actor is software making decisions based on model output.

The starting point is to treat every agent as a new identity in the landscape, with the same rigour as a service or a human user. Three patterns make that practical.

Pattern one, a workload identity per agent: each agent receives its own short-lived identity, issued by the platform at runtime. There are no static secrets in code or configuration files, and rotation happens automatically because credentials expire. This gives every agent a distinct name in logs and in the target systems, and it allows an individual agent to be disabled without affecting others. It also allows permissions to be reviewed per agent, in the same recertification cycles that already exist for service accounts.

Pattern two, OAuth 2.0 Token Exchange as specified in RFC 8693: when an agent acts on behalf of a person, it exchanges the user's token, together with its own workload token, for a new token scoped to the target system. In the request, the user's token is passed as the subject token, the agent's workload token as the actor token, and the request names the intended audience, such as the ERP interface, and a narrow scope, such as read access to orders. The resulting token carries both identities. The target system can authorise based on the person's rights and can still see that an agent performed the action.

Pattern three, least privilege per tool: scopes are granted per tool call, not per agent. An agent that can read orders does not automatically gain the right to change them. Read and write actions are separated, and write actions that have consequences require approval by a human before they are executed.

The result is an audit trail that answers the question internal audit and the CISO will ask: agent X acted on behalf of person Y, with scope Z, at time T. This is also the basis for incident response. If an agent behaves unexpectedly, its identity can be revoked and its actions reconstructed without guessing.

There are limits. Not every target system supports token exchange, and many legacy applications only know service accounts with broad permissions. The answer is not to give the agent such an account. A better pattern is a gateway in front of the legacy system that accepts the exchanged token, translates it into the system's own authorisation model with the narrowest possible rights, and logs the delegation chain. Another limit is operational. Short-lived identities and token exchange depend on a reliable identity infrastructure, and its availability becomes part of the agent's availability.

For an architecture or security team, the next steps are straightforward. First, inventory the credentials agents use today and identify every shared key. Second, define a standard for agent identity: who issues it, how long it lives, how it is revoked. Third, select the first target systems where token exchange is feasible and introduce it there, starting with systems where agents write. Fourth, design the gateway pattern for systems that cannot support it. Finally, check that your logs record subject, actor, scope and time for every agent action.

A useful question for the board: can we attribute every agent access to a person and a scope, today?

cloudstrata builds and operates AI platforms for enterprises. AI Foundry is our managed runtime for AI agents and provides multi-tenant workspaces, routing of models and tools, knowledge retrieval, evaluation hooks, usage and cost metering, audit trails and central governance. If agent identity is on your security roadmap, you can request a technical introductory conversation via cloudstrata.io/contact.