Zero standing permissions for AI agents: why blank slate matters

At a glance

What this is: The article argues that AI agents should start in a blank-slate state, with sensitive tools disabled by default and permissions granted only for bounded tasks.

Why it matters: That matters because IAM, PAM, and NHI teams need controls that reduce standing authority before agent behaviour can chain across tools, data, and systems.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read PermitIO's guidance on zero standing permissions for AI agents

Context

Zero standing permissions for AI agents means the agent begins with no durable sensitive access and receives only the capabilities it needs for a specific task. In agentic AI environments, that matters because the primary identity security problem is not authentication alone, but whether the runtime can reach tools, connectors, memory, and execution paths without an explicit grant.

The article’s core point is that broad defaults feel useful in demos but create risk debt in production. Once browser, terminal, write, memory, and MCP access are all active at startup, the governance problem becomes standing authority, not just model behaviour.

For IAM and NHI programmes, this is the same old least-privilege lesson in a new runtime shape. The difference is that agents can combine permissions quickly enough that the control gap shows up as blast radius, auditability, and revocation speed rather than as a simple access request failure.

Key questions

Q: How should security teams implement zero standing permissions for AI agents?

A: Start with a blank-slate baseline, then grant only the tool classes needed for a specific task and revoke them automatically when the task ends. Pair that with logs for each allow and deny decision so you can prove what authority existed. The goal is to remove durable sensitive access, not just reduce it.

Q: Why do AI agents create more access risk than traditional automation?

A: AI agents can decide at runtime which tools to use, when to use them, and how to chain actions across systems. That makes standing permissions more dangerous because the same access can be combined in ways a traditional scripted workflow would not. The risk is blast radius, not only volume of activity.

Q: What breaks when toolset pinning is used without runtime authorisation?

A: Toolset pinning limits what is visible, but it does not decide whether a specific action is safe in the current context. Without runtime checks, a visible tool may still be overused, misused, or chained into a broader incident. Good governance separates capability exposure from execution approval.

Q: How do teams know whether their agent permission model is actually working?

A: Look for fewer standing privileges, shorter grant lifetimes, and a clear audit trail for every sensitive action. If agents can still write, execute, delegate, or reach connectors without a bounded reason and expiry, the model is not working. Visibility into denied actions is as important as the allowed ones.

Technical breakdown

Zero standing permissions and blank-slate startup

Zero standing permissions, or ZSP, means an agent has no always-on authority to sensitive tools when idle or at startup. Access is granted narrowly for a task, then revoked automatically after completion or timeout. In practice, this shifts the security model from trusting the model not to misuse tools to preventing the model from reaching tools it has not been granted. That is the right baseline for any agent touching terminals, connectors, or long-lived memory.

Practical implication: design startup states so sensitive capabilities are absent until an explicit task grant is issued.

Static toolset pinning versus runtime authorisation

Static gating and runtime policy solve different problems. Toolset pinning decides which capability classes are visible before the session begins, while runtime authorisation evaluates each attempted action in context and can allow, deny, or constrain it dynamically. Static controls shrink the exposed surface area. Runtime controls handle the cases where a visible capability is still too risky for the current data, user, or environment. Mature agent governance needs both, not one disguised as the other.

Practical implication: separate baseline capability reduction from per-action policy enforcement in your control design.

Capability risk changes with tool class

Not all agent permissions carry the same blast radius. Read access mainly raises leakage concerns, while write access can alter configs or persist malicious state. Execute access can compromise hosts, delegation can amplify privilege through sub-agents, MCP connectors can expose third-party systems, and memory writes can preserve poisoned or sensitive context. The security issue is not just whether the tool exists, but how much authority it adds to the agent’s decision loop and how hard it is to revoke later.

Practical implication: classify agent tools by consequence before deciding which ones may be granted at runtime.

Threat narrative

Attacker objective: The objective is to trigger agent actions that reach beyond the intended task boundary and create unauthorized access, leakage, or system change.

1. Entry begins when an agent starts with broad default access to browser, terminal, write, memory, and MCP tools instead of a blank-slate baseline.
2. Escalation follows when one bad prompt or misread intent chains across multiple granted tools faster than a human can intervene.
3. Impact is broad operational and data exposure across systems, because standing permissions let the agent act beyond the intended task scope.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Blank-slate startup is a governance assumption, not a UI preference: agent systems were built around the idea that available tools can be left on because the model will use them responsibly. That assumption fails when a single session can chain browser, terminal, write, memory, and MCP reach into one fast action path. The implication is not “add more controls later”, but that standing authority is the wrong starting state for agent governance.

Zero standing permissions is the agentic version of least privilege, but the risk boundary is the runtime: conventional IAM can review who has access, yet agent systems need to prove what access existed for a moment, not just what existed at provisioning time. That is why task-scoped grants and automatic revocation matter. Practitioners should treat runtime authority as the governable unit, not the account alone.

Static tool pinning and runtime policy solve different halves of the same problem: pinning reduces exposed surface area, while runtime checks constrain what the agent can do inside that surface. The article is right to separate them, because confusing capability visibility with authorization creates false confidence. The practitioner conclusion is that a visible tool is not a safe tool, only a controllable one.

Agent risk becomes an identity blast-radius problem the moment delegation is allowed: once an agent can spawn or chain sub-agents, the permission model stops being about one identity and starts becoming about inherited privilege. That is where review cadences, approval flows, and revocation logic often break down. The governance question is no longer whether the agent can act, but how far authority can propagate before oversight reappears.

Ephemeral credential trust debt: the article exposes a common failure mode in agent programmes where convenience creates standing authority that is later treated as temporary in name only. That premise is designed for human-paced workflows with visible sessions and review points. It fails when agent actions can begin, branch, and complete before any human sees the grant, so practitioners must rethink access lifetimes as a core control boundary.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• A related governance lens is the OWASP NHI Top 10, which helps teams map agent tool abuse and scope drift to concrete control failures.

What this signals

Ephemeral credential trust debt is the right way to think about agent permission sprawl. The longer teams leave browser, terminal, connector, or memory access active by default, the more they accumulate authority that is easy to grant and hard to justify later.

With 80% of organisations already seeing AI agents act beyond intended scope, per AI Agents: The New Attack Surface report, the practical programme question is no longer whether agents need controls, but whether those controls operate at session speed.

The governance signal to watch is whether your IAM and PAM processes can describe runtime privilege, not only assigned privilege. If you cannot explain who granted the capability, for what task, and until when, agent governance is still running on human-workflow assumptions.

For practitioners

• Default sensitive tools to disabled at startup Make browser, terminal, write, MCP, delegation, and durable memory writes opt-in rather than present from session start. Use a safe starter bundle for routine development work so productivity remains usable without creating silent standing authority.
• Separate baseline pinning from runtime approval Keep capability classes pinned at configuration level, then add per-action policy decisions for high-risk calls such as execute, write, connector access, and sub-agent spawning. That separation makes it possible to see where surface-area reduction ends and true authorisation begins.
• Grant time-bounded access with explicit revocation Use short-lived grants for terminal, MCP, and memory writes, and require automatic expiry at task completion. Add logs for every allowed and denied tool call so later investigation can reconstruct what authority actually existed during the session.
• Limit delegation depth and privilege inheritance Require child agents to inherit equal-or-lower privileges only, and cap recursion depth so the control plane does not disappear inside chained execution. This keeps one task from becoming an uncontrolled privilege amplifier across multiple agent instances.

Key takeaways

• AI agents create a standing-authority problem when sensitive tools are enabled at startup.
• The evidence is already visible: most organisations have seen agents act outside intended scope, and many still cannot fully audit what those agents touched.
• Blank-slate startup, runtime approval, and automatic revocation are the controls that turn agent access from open-ended authority into bounded execution.

Key terms

• Zero Standing Permissions: A security model in which an agent has no durable sensitive access when idle or at startup. Permissions are granted only for a bounded task and then revoked, reducing the chance that latent authority can be misused by prompts, mistakes, or chained actions.
• Runtime Authorisation: A decision made at the moment an action is attempted, based on current context such as task type, identity, sensitivity, and environment. For agent systems, it is the control that decides whether a visible capability may be used right now, not just whether it exists.
• Capability Pinning: A configuration pattern that restricts which tools or tool classes are available before an agent session begins. It lowers exposed surface area, but it is not the same as approval, because a pinned tool can still be misused unless runtime policy constrains each call.
• Identity Blast Radius: The amount of damage an identity can cause if its permissions are used incorrectly or maliciously. In agentic systems, blast radius grows quickly when write, execute, delegate, connector, or memory privileges can be combined within one session or across sub-agents.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by PermitIO: Zero Standing Permissions for AI Agents: Lessons from Hermes Blank Slate and Toolset Pinning. Read the original.