Why should an autonomous agent hold its own credentials instead of the operator's?

## The problem: borrowed permissions The quickest way to get an agent working is to run it with credentials that already exist — the engineer's cloud session, a shared CI service account, an admin API key sitting in an environment variable. It works immediately, and it is the single most common source of oversized blast radius in agent deployments. Permissions in every serious system are attached to a *principal*: a user, a service account, a machine identity. If the agent reuses a principal, it inherits that principal's entire permission set. An on-call SRE typically holds broad standing access — deployments, secrets, IAM, sometimes billing — because humans need latitude to respond to incidents. An agent driven by a language model, whose inputs may include a poisoned ticket description or a hostile log line, does not need that latitude and should never hold it. The agent's capability ceiling should be the union of the tasks it is meant to perform, not the union of what its operator happens to be allowed to do. ## What "agent as an identity" means concretely Four properties are what you are buying: **Its own principal.** The agent authenticates as itself — a service account, workload identity, or machine client — not as a person. Its role grants exactly the operations its tools need: for an SRE deploy agent, scaling a named set of deployments and reading logs from one namespace, with IAM, secret rotation and billing APIs absent from the role entirely. **Its own credentials, short-lived.** Prefer workload identity or short-TTL tokens over a long-lived key baked into config. A credential the agent holds for fifteen minutes is a much smaller prize than one that lives in a repo for a year. **Its own audit trail.** Every action lands in the log under the agent's principal. This is the property people underestimate. If the agent runs as the engineer, the cloud audit log shows the engineer performing a 3am rollback, and nobody can tell after the fact whether a human decided to do it or a hijacked agent did. Attribution is not bureaucracy — it is the difference between an incident you can reconstruct and one you cannot. **Its own lifecycle.** You can suspend, rotate or delete the agent's identity the moment it misbehaves, without disabling a person or breaking unrelated automation. Shared service accounts fail this test badly: revoking one breaks everything else that uses it, so in practice nobody revokes it. ## Delegation: on-behalf-of, not instead-of Many agents act for a specific user, which raises a genuine design question: should the agent's authority be its own, or the user's? The workable answer is usually both, recorded separately. The agent authenticates as itself and carries the requesting user as delegated context, so the effective permission is the *intersection* of what the agent may do and what that user may do, and the audit record names both. That prevents the two classic failures at once: an agent that can do more than the user who asked (privilege escalation through automation), and an agent whose actions are indistinguishable from that user's own clicks. The cost is real — per-user, per-agent identities multiply the number of principals your identity system has to manage, and the intersection logic has to be enforced somewhere authoritative, not in a prompt. That is why teams often start with one agent principal per *purpose* (deploy agent, triage agent, reporting agent) rather than per user, and add delegation only where the user's own authority genuinely matters. ## What this does not solve A distinct identity bounds authority; it does not stop the agent from misusing the authority it has. An agent scoped to scale deployments can still be talked into scaling the wrong one. Identity is one wall — narrow tool scopes, sandboxed execution and approval on irreversible actions are the others, and they are independent by design. What identity buys you is that when something goes wrong, the damage stops at the edge of that role and the log tells you exactly what happened. ## How to answer this in an interview Lead with inheritance: reusing a human session inherits that human's whole permission set. Then name the three concrete wins — narrow scoping, independent revocation, attributable audit — and give one example with a real deny in it ("scale these deployments and read logs; no IAM, no billing"). Mentioning delegation and the intersection rule signals you have actually deployed one of these rather than read about it.