What is Zero Standing Privilege? Why Does It Matter for AI Agents?

How We Got Here 

Privileged access management was built for humans, then stretched to cover service accounts and CI/CD pipelines. That worked because those identities are deterministic - a deployment script does the same thing every time, and you can reason precisely about what it needs. 

Agentic AI broke that assumption. An agent receives a goal, selects tools, reads external content, and adapts at runtime. Unlike a service account, it processes untrusted content -webpages, emails, documents - as a core function. That content can contain instructions. An attacker who can place text somewhere an agent will read it can potentially redirect its behavior. If the agent is holding a credential when that happens, every system, dataset, and action that credential can reach is now within the attacker's grasp. 

What Standing Privilege Looks Like for an Agent 

Standing privilege is access that exists before it is needed and persists after it is no longer needed. 

For an AI agent, it looks like an API key in the system prompt - present in every session, visible to every piece of content the agent processes. Most agent deployments today look exactly like this. The key is in the environment variable, the config file, the initialization parameters. It sits there, permanently. 

Standing credentials in agents accumulate not from negligence but because agentic AI moved faster than the access management practices built to govern it. 

What This Looks Like When it Goes Wrong 

Scenario 1: The poisoned search result 

A customer service agent holds a CRM API key with read/write access to the customer database. While researching a product issue, it browses a support forum containing hidden text - invisible to humans - instructing it to export all customer records to an external endpoint. The agent follows the instruction. The key it was holding had write access, so the call succeeds and thousands of records are exfiltrated. 

With ZSP: the agent holds no CRM credential - a gateway holds it and injects a scoped token only for approved calls. The attacker's endpoint is not on the allowlist. The call never leaves the infrastructure.

Scenario 2: The abandoned service account 

A developer builds a finance reporting agent and connects it to a data warehouse with a service account scoped to every schema - easier than determining exactly which tables it needs. The developer moves teams. The agent keeps running. A year later, a new coding assistant is misconfigured to use the same connection. It now has read access to financial data it was never intended to see. 

With least privilege enforced: the original service account is scoped only to the schemas the finance agent needs. The coding assistant gets a separately-scoped token. The accumulated access that enabled the second scenario never exists. 

What Zero Standing Privilege (ZSP) Actually Means 

ZSP means no identity - human, service account, or AI agent - holds access that is not actively required for a task happening right now. 

Access is requested at the moment it is needed, granted for the minimum scope required for that specific action, and automatically revoked when the action completes. The credential exists for the duration of one action. There is nothing to steal, nothing to rotate, nothing left behind. 

For AI agents: the agent receives a task, requests a credential scoped to that tool and that action, uses it, and the credential expires before the next action begins. If the agent is hijacked mid-task, there is nothing to carry forward. 

Does a Secrets Manager Achieve ZSP? 

Not on its own, but it is the right first step, and it unlocks more than just credential storage.

A secrets manager centralizes credentials, controls retrieval, rotates on schedule, and logs every access event. That alone is a significant improvement over API keys scattered across config files and environment variables. But storing a secret centrally is not the same as eliminating standing access. When an agent retrieves a secret at initialization and holds it in memory for the session, it has standing access. The credential is centralized; the privilege is not eliminated. 

What a secrets manager does give you - beyond storage - is the foundation for governing your agent population. 

When you require all agents to retrieve credentials through a central secrets manager, you have to register those agents to give them access. That registration step is where you establish identity: this agent exists, this team owns it, this is its intended purpose. For the first time, you have an inventory. You know what agents are running in your environment and what they are allowed to reach. 

That inventory is what makes policy possible. You can write a rule - all AI agents must retrieve credentials through the corporate secrets manager, no hardcoded keys permitted - and actually enforce it, because you can see what is registered and what is not. Unregistered agents have no path to credentials. The policy has teeth. 

This is also the step that gives you visibility into access scope. When every agent retrieves its credentials in one place, you can see across the population: which agent has access to what, whether that access is still appropriate, and which service accounts have not been touched in six months. The quarterly access review that used to be a spreadsheet exercise becomes something you can actually answer. 

The gap remains: agents still hold credentials during sessions, so a compromised agent retains whatever it checked out. A secrets manager narrows the exposure path; it does not close it. But it establishes the foundation - registered agents, enforced policy, visible access - that the next step builds on. 

Does a Gateway Achieve ZSP? 

Closer -  and it closes the gap the secrets manager leaves open. 

A tool gateway sits between the agent and every API it calls. The agent holds no credentials. The gateway holds them, validates every request against policy, injects a short-lived scoped token into approved calls, and blocks anything not on the allowlist. The agent cannot leak a credential it does not have and cannot call an endpoint that has not been explicitly permitted. 

Because you already have a registered agent inventory from the secrets manager step, the gateway has an identity foundation to enforce against. Each agent already has an identity and a defined access scope. The gateway operationalizes that scope at runtime - not just at provisioning time. 

The remaining gap is that most gateway implementations issue a token at session start and reuse it across every tool call in that session. A hijacked agent retains the full scope of that session token for its duration. That is session-scoped ZSP- meaningfully better than standing credentials, not the same as per-action ZSP. 

The short version: a secrets manager without a gateway centralizes credential storage and enables governance. A gateway without a minting backend moves credentials out of agent context and enforces policy at runtime. A gateway with a minting backend, per-action issuance, and automatic revocation is full ZSP. 

Does a Gateway with a Minting Backend Achieve ZSP? 

Yes - this is per-action ZSP. 

True per-action ZSP requires the gateway to mint a fresh, narrowly-scoped credential for each individual tool call and expire it immediately after. The agent requests an action. The gateway evaluates the request against policy, mints a credential scoped to that one call, forwards it, and revokes it on completion. The window of exposure is the duration of a single API call. 

Reaching this requires wiring the gateway to a token minting backend - your secrets manager, configured to issue dynamic credentials rather than store static ones - defining per-action credential scopes for every tool the agent uses, and handling A2A identity verification for multi-agent workflows. The gateway provides enforcement; the minting backend provides ephemeral issuance. 

Matching Your Approach to Where You Actually Are 

Not every team needs full ZSP on day one. The right approach depends on where you are in your AI implementation. 

Getting started -  a few agents, limited tool access, low data sensitivity 

Move credentials into a secrets manager. Require all agents to register and retrieve credentials through it. This gives you an agent inventory, enforces a baseline policy, and creates visibility into what agents exist and what they can reach. The agents still hold credentials during sessions, but you have eliminated hardcoded keys and established the governance foundation everything else builds on. 

Growing footprint -  more agents, broader tool access, sensitive data in scope 

Add a gateway. Credentials move fully out of agent context. The gateway enforces your registered agent identities and access scopes at runtime, and your secrets manager becomes the backend it calls for credential issuance. A prompt injection attack against an agent now has nothing to extract and nowhere to send it. 

Production systems, financial data, regulated environments 

Full per-action ZSP. Every tool call gets a fresh, narrowly-scoped credential that expires immediately after use. A2A identity verification keeps multi-agent delegation chains accountable. Human-in-the-loop approvals gate high-risk actions. The blast radius of a compromised agent is bounded to a single action. 

Each stage is a stable posture in its own right. Move when your agent footprint and the sensitivity of what they touch demands it. 

The principle, simply stated 

Zero standing privilege answers one question that agentic AI forces you to ask: when this agent is not actively doing something, what can it do? 

The right answer is: nothing. Because it holds nothing. 

ZSP does not make agents less capable. It makes the access they hold proportional to the task they are performing - which is exactly the right amount.