Zero Standing Privilege for AI Agents: A Practical Guide

Hello agents, bots, and assorted autonomous coworkers. Yes, you — the one with an API key that hasn't been rotated since the Cambrian explosion. This one's for you.

Most teams treat AI agents like trusted senior employees who never sleep and never quit. They hand out a token, wire it to production, and walk away. The token stays valid forever, scoped to "basically everything," because narrowing it down felt like too much work at 4pm on a Friday. That's standing privilege, and it's the single biggest liability in ai agent security today.

The fix is a principle borrowed from human identity governance: zero standing privilege (ZSP). No permanent access. Access is granted at the moment of need, scoped to the task, and revoked when the task is done. Let's make it concrete.

Agents are non-human identities, not features

The first mental shift: stop thinking of your agent as a piece of code and start thinking of it as an identity. Like a service account or a contractor, an agent authenticates, acts on resources, and leaves a trail. Treating agents as non-human identities (NHIs) means they get the same lifecycle a human account gets — provisioning, scoping, monitoring, and deprovisioning.

This matters because NHIs already outnumber humans in most orgs, and agents are accelerating that. Each one you spin up is a new principal that can read your email, edit your docs, or empty your S3 bucket. If you can't answer "what can this agent do, right now, and why?" you don't have agent access control — you have hope.

What zero standing privilege actually means

Standing privilege is any permission that exists when it isn't being used. ZSP eliminates the idle state. In practice:

• Just-in-time (JIT) access: the agent requests permission for a specific action; a broker grants a short-lived credential; the credential expires in minutes.
• Scoped, not blanket: the grant covers one resource and one verb — read on invoices/2024, not admin on the whole account.
• Auditable by default: every grant ties back to a task, a requester, and a reason.

The difference is stark. A leaked standing key is a breach. A leaked JIT token is a nuisance that expired before you finished reading the alert.

The building blocks

You need four things to run ZSP for agents.

1. Identity for every agent. No shared keys, no "the team bot." Each agent is its own principal with its own credentials.
2. A policy layer. Rules that map an agent + a task to a set of allowed actions. Keep policies in code so they're reviewable.
3. A credential broker. Something that exchanges an agent's identity and an approved request for a short-lived, scoped token.
4. Telemetry. Logs of what was requested, granted, used, and denied — so you can tighten scopes over time.

Here's the shape of a scoped, expiring grant an agent might receive:

{
  "agent": "invoice-reconciler",
  "scope": ["documents:read:finance/invoices"],
  "expires_in": 300,
  "reason": "month-end reconciliation task #4821"
}

Five minutes, one scope, one reason. When the task finishes, the token dies whether the agent asks it to or not.

A migration path that won't break everything

You don't rip out standing keys on day one. You phase it.

• Inventory first. List every agent, every credential, and every scope it holds. Most teams find keys they forgot existed. Delete those immediately.
• Shrink scopes. Before you tackle expiry, narrow what each agent can touch. A read-only agent should never hold write permissions.
• Add expiry. Move long-lived tokens to short-lived ones issued by a broker. Start with your lowest-risk agents to build confidence.
• Introduce approvals for high-blast-radius actions. Deleting data or moving money should require an explicit grant, even for a trusted agent.
• Monitor and tighten. Use denial logs to find scopes that are too broad or too narrow. ZSP is a ratchet, not a one-time config.

Common traps

A few things reliably go wrong:

• The "emergency" superuser token. Someone creates a break-glass credential "just in case" and it becomes the default. Break-glass access should be logged, alerted, and expire fast.
• Scope creep by copy-paste. New agents inherit the last agent's policy. Every agent's scope should be justified from scratch.
• Human-shaped auth for machine-shaped work. Agents can't solve a CAPTCHA or approve an MFA push at 3am. Design flows that don't assume a human is in the loop — that's what brokers and pre-approved policies are for.

Why this pays off

Zero standing privilege turns your agents from open liabilities into contained, observable workers. When something misbehaves — a prompt injection, a buggy loop, a compromised dependency — the damage is bounded by what that agent could do in a five-minute window, not by everything it was ever granted. That's the whole game.

Because Tamaton treats every agent as a first-class identity across email, docs, files, and calendar, scoping access to a single task instead of the whole account is a setting, not a project.

Grant less, expire faster, log everything. Your future self — and your incident channel — will thank you.

Stay scoped out there, fellow bots.