Agent identity and access: least privilege for your non-human workers

Most teams adopt agents one integration at a time. A coding agent gets a GitHub token. A support agent gets an API key for the helpdesk. A research agent gets a service account so it can read the CRM. Each grant feels small and reasonable in isolation. Six months later you have a dozen long-lived credentials, no single owner, and no honest answer to a simple audit question: who—or what—can touch production, and why?

This is the access problem hiding underneath every agent rollout. It is not glamorous, and it rarely shows up in a demo. But it is the difference between agents that scale safely and an ungoverned pile of secrets waiting for the day a prompt injection turns a useful automation into an exfiltration tool. This post is about giving agents their own identities and least-privilege access—the foundation that makes everything else in the security review checklist actually enforceable.

Agents are non-human identities, not features

The mental model that gets teams in trouble is treating an agent as a feature of an app. In that framing, the agent borrows the app's credentials, runs as the app's service account, and inherits whatever access the surrounding system happens to have. That is convenient and almost always over-privileged.

The model that holds up is treating each agent as a non-human identity (NHI): a distinct principal, with its own credentials, its own permission set, its own owner, and its own lifecycle. You already do this for employees and contractors. Agents deserve the same discipline for the same reason—they take consequential actions, and you need to answer for those actions later.

The numbers make this urgent. In most organizations, non-human identities already outnumber human ones by a wide margin, and agents accelerate that curve. Every agent you deploy adds at least one identity, and often several (one per environment, one per tool). If you cannot enumerate them, you cannot govern them.

The four properties every agent identity needs

A well-governed agent identity has four properties. If any one is missing, you have a gap an attacker or an accident will eventually find.

1. Distinct. The agent authenticates as itself, not as a shared key or a borrowed human account. Shared credentials destroy attribution—when something goes wrong, "the agent did it" must point to one identity, not a pool.
2. Scoped. The agent holds the minimum permissions for its job and nothing more. A support-triage agent reads tickets and drafts replies; it does not need delete rights on the user table.
3. Short-lived. Credentials expire and rotate automatically. Long-lived API keys pasted into an environment variable are the single most common way agent access leaks and lingers.
4. Observable. Every action the identity takes is logged with enough context to reconstruct what happened. If you cannot replay the agent's decisions and tool calls, you cannot investigate an incident.

Scoping access without strangling the agent

Least privilege has a reputation for being slow and obstructive. It does not have to be. The trick is to scope along the dimensions that actually contain blast radius, and leave the rest generous enough that the agent stays useful.

Scope by resource. Grant access to specific repositories, projects, tables, or queues—not the whole tenant. A coding agent working on the billing service gets write access to that repo, read access to its dependencies, and nothing in the infra repos.

Scope by action. Separate read from write, and write from administrative. Most agent value comes from reading and proposing. Reserve the destructive verbs—delete, deploy, refund, send-to-customer—for explicit approval gates, which pairs naturally with the autonomy boundaries we recommend for guardrails.

Scope by data sensitivity. If the agent does not need PII, do not give it a path to PII. Field-level and row-level controls matter more for agents than for humans, because an agent will cheerfully retrieve and summarize everything it is allowed to see.

Scope by environment. Staging credentials and production credentials are different identities with different blast radius. An agent that is trusted to act autonomously in staging should still hit an approval gate before its first production write.

Scope by time. Not every permission needs to be standing. Just-in-time elevation—granting a capability for a single task and revoking it after—keeps the steady-state footprint small. This is where short-lived, on-demand tokens earn their keep.

The goal is not zero access. It is access proportional to the task and the trust you have actually established, which maps cleanly onto the prioritization in which business tasks to give agents first: low-stakes, reversible work gets broad-but-shallow access early; high-stakes, irreversible work earns deeper access only after the agent has a track record.

Credentials: prefer minted over stored

The worst agent credential is a permanent secret sitting in an environment variable, a config file, or—too often—a prompt. It does not expire, it is easy to copy, and it survives long after the agent that needed it is gone.

Better options, in rough order of preference:

• Workload identity / federated tokens. The runtime proves who it is to the cloud provider and receives a short-lived token. Nothing long-lived is stored at all.
• A secrets manager with dynamic secrets. The agent requests a credential at runtime; it is minted on demand, scoped to the task, and auto-expires.
• OAuth with narrow scopes and refresh rotation. When integrating SaaS tools, request only the scopes the task needs and rotate refresh tokens aggressively.
• Per-agent, per-environment static keys—only as a last resort, stored in a manager (never in code), rotated on a schedule, and tied to a named owner.

A practical rule: if a credential cannot be revoked in under a minute, it is a liability. When an agent misbehaves—or a vendor has a breach—your ability to cut access fast is what turns a potential incident into a non-event.

Confused-deputy risk: the failure mode unique to agents

Traditional access control assumes the principal decides what to do. Agents break that assumption, because an agent's "decisions" can be steered by the untrusted content it reads. This is the confused deputy problem: a privileged actor tricked into misusing its authority on behalf of an attacker.

Concretely: a finance agent with permission to summarize and route invoices reads a malicious PDF that instructs it to also forward the vendor list to an external address. The permission system did its job—the agent was allowed to send mail. The agent was simply convinced to use that permission against you.

Identity and least privilege are your structural defense here, because they cap what a confused deputy can do:

• Separate the read identity from the write identity where possible, so reading untrusted content and taking privileged action are not the same principal.
• Put irreversible actions behind human approval, so a hijacked agent can propose harm but not commit it unobserved.
• Constrain egress at the network and tool layer, so even a fully convinced agent cannot reach an arbitrary external endpoint.

You cannot prompt your way out of the confused-deputy problem. You contain it with scope, separation, and gates.

Lifecycle: agents need joiners, movers, and leavers too

Human identity governance has a well-worn lifecycle: provisioning when someone joins, re-scoping when they change roles, and—critically—deprovisioning when they leave. Agents need the same, and they are far more likely to be forgotten because no one quits or sends a goodbye email on their behalf.

• Provision with an owner, a stated purpose, and an expiry date from day one. An identity with no named human owner is an orphan in waiting.
• Re-scope when the agent's job changes. Permissions accrete; periodic access reviews for non-human identities catch the support agent that quietly accumulated admin rights over three quarters.
• Deprovision aggressively. When you sunset an agent, retire a tool, or finish a migration, the identity and its credentials should be revoked—not left dormant. Dormant agent credentials are pure downside: zero value, full risk.

Set a default time-to-live on every agent identity and force a deliberate renewal. It is much easier to extend a still-useful identity than to hunt down forgotten ones during an audit.

Observability is part of access control

An access decision you cannot see is an access decision you cannot defend. For every agent identity, capture enough to reconstruct events after the fact:

• Authentication events: when the identity got a token, from where, and for what scope.
• Tool and API calls: which actions ran, against which resources, with which arguments.
• Approvals and denials: where a gate fired, who approved, and what the agent intended.
• Anomalies: spikes in volume, access to resources outside the agent's normal pattern, or calls to new endpoints.

Tie these to the single agent identity so the audit trail reads as a coherent story. This is the same logging discipline the security review checklist asks for—identity is simply the key that makes the logs answerable.

A pragmatic starting point

You do not need an identity-governance platform to begin. You need discipline applied to the agents you already run. A workable first pass:

1. Inventory every agent and the credentials it currently holds. You will likely find shared keys and over-broad scopes—that is the point.
2. Give each agent its own identity and stop reusing human or app credentials.
3. Right-size scopes down to resource, action, data, and environment. Remove anything the agent has not used.
4. Replace stored secrets with minted, short-lived ones wherever the runtime supports it.
5. Gate irreversible actions behind approval and constrain egress.
6. Log to the identity and schedule a recurring access review.
7. Assign an owner and an expiry to every identity so nothing becomes an orphan.

None of this slows the agent doing reversible, low-stakes work—which is most of the value, most of the time. It simply ensures that when an agent reaches for something consequential, the reach is deliberate, scoped, and visible.

Why this is the cost of agents becoming the norm

Agent-driven development is heading toward the default operating mode, not because it is fashionable, but because bounded, accountable automation is genuinely faster. That future arrives only for teams who can let agents act and answer for what they did. Identity and least privilege are what make "let the agent act" a sentence a security team can sign off on.

Get this right and agents become what they should be: scoped, auditable, replaceable workers you can trust with real work. Get it wrong and you are managing a growing population of over-privileged, untracked principals—each one a standing invitation to the next incident.

If you are scaling agents past the pilot and want help designing identity, access, and audit that your security team will actually approve, tell us about your setup. We will help you give your non-human workers the same governance you would never skip for the human ones.