Secure AI Agents in Production: Replace Human Logins with Scoped, Revocable Agent Identities

When production AI agents reuse human logins, agent actions are attributed to the human whose login is being used. The audit trail is useless for blame, forensics, or compliance. Production AI agents are not users. They do not type passwords or wait for second factors. They run in pipelines, call tools, write files, open tickets, and move data. An agent is wired to a human account, a shared service account, or a long-lived API key. It works. Then it does something unexpected. The logs show a person's name.

Legacy identity and access management assumptions are built around human login and interactive authorization. That model assumes the thing logging in is a person.

What changed

An agent's identity, by contrast, gets asserted by the infrastructure around it: an IAM role, a workload token, something that was never meant to stand in a queue and prove it's a person.

OAuth 2.1, PKCE, and MCP leave non-human authentication to the authorization server open. The gap is that non-human authentication is not fully defined.

AI-native vendor enterprise growth is outpacing comparable access-control change.

The rollout checklist

Use this checklist before an agent touches production data. Every agent action should be attributable, scoped, and revocable.

1. One identity per agent

   A shared identity is not recommended; each agent should get its own identity.

2. Workload-asserted identity. The agent should receive its identity from the runtime, not from a person. The platform should assert the agent's identity at startup. The agent should not carry a human password, a personal token, or a copied session.
3. Short-lived task-scoped tokens. Tokens should be issued narrow and short-lived, per task, instead of one broad token that covers an entire session.
4. Audit attribution. Every action should record the agent identity, the task, the permission, and the result. If a human approved the task, record that too. The audit trail should answer: which agent did what, under which permission, for which task, and with what outcome.
5. Revocation controls. Revocation must work at the agent, task, and token levels. If an agent is compromised, stop it. If a task is abandoned, kill its token. Revocation should not require deleting the agent or rolling a shared credential.

What to do next

Start with the agents already in production. Inventory them. Flag any agent that uses a human login, a shared service account, or a long-lived token.

Build the identity path before the next launch. The platform should create the agent identity, assert it to the workload, issue task-scoped tokens, and record the audit trail. The agent should not request broad access by itself. It should request a task. The platform should decide whether the task is allowed, what scope it gets, and how long the token lives.

Make delegation a policy decision, not a code shortcut. If an agent acts for a user, the user's consent should be visible in the audit trail. If an agent acts for another agent, the chain should be explicit. Shorten long chains. Narrow broad scopes. Cut long lifetimes.

Test revocation. Stop an agent. Revoke a token. Cancel a delegation. Confirm that the agent can no longer act. Confirm that the audit trail shows the stop. If revocation is slow, partial, or invisible, it is not production-ready.

Then set the operating rule: no human login for agents. No shared service accounts for agents. No broad session tokens for agents. No unattributed actions in production.