Zero Standing Permissions for AI Agents: Lessons from Hermes Blank Slate and Toolset Pinning
Zero Standing Permissions for AI Agents: Lessons from Hermes Blank Slate and Toolset Pinning
Table of Contents
Teams running local coding agents have hit the same pattern repeatedly: broad defaults feel amazing in demos, then turn into risk debt in production. If browser, terminal, write, memory, and MCP reach are all active at startup, one bad prompt or one misread intent can chain across systems faster than a human can intervene.
That is why recent framework shifts matter. Hermes Agent's "Blank Slate" direction is a concrete implementation of the established zero standing permissions (ZSP) model for AI agents: start with minimal standing access, then grant what is needed for a bounded task and revoke it. The move is documented in MarkTechPost's Hermes Blank Slate coverage, the Hermes quickstart documentation, the Hermes toolsets reference, and the upstream Hermes commit implementing related changes.
What zero standing permissions means for AI agents
Zero standing permissions for AI agents means the agent holds no always-on authority to sensitive tools or data paths when idle or at startup. Access is granted narrowly, scoped to a specific task, and revoked automatically after completion or timeout. This shifts safety from "trust the model not to call dangerous tools" to "the model cannot call what it has not been granted."
For agent systems, ZSP can involve multiple layers such as baseline-deny configuration, explicit allowlisting for capability classes, and runtime checks that enforce context-aware approval. Hermes Blank Slate and toolset pinning exemplify the first two layers by reducing default exposure and requiring explicit enablement.
Should tools start disabled by default?
Yes, in most production and local-dev scenarios, tools should start disabled by default. "Default deny" reduces blast radius from prompt injection, model mistakes, and hidden chain-of-thought tool invocations. It also improves auditability, because every granted capability has an explicit reason and scope.
There are exceptions for low-risk developer workflows, but even then, prefer pre-approved bundles rather than global enablement. The key principle is that convenience should not silently become standing authority.
Permission models compared: all-on-by-default vs config-pinned vs runtime-authorized
| Model | How it works | Security posture | Operational friction | Best fit |
|---|---|---|---|---|
| All-on-by-default | Most or all tools enabled at startup | Weak: large attack surface and broad accidental power | Low upfront, high incident risk later | Throwaway prototypes only |
| Config-pinned | Allowed toolsets pinned in config; others disabled | Stronger: deterministic, least-privilege baseline | Moderate: requires curation and config discipline | Local agents, CI agents, stable workflows |
| Runtime-authorized | Baseline deny plus per-request approval/JIT grants | Strongest: contextual authorization and short-lived grants | Higher: policy, UX, and logging pipeline needed | Enterprise, regulated, multi-tenant agents |
An effective maturity path involves transitioning from all-on (prototype) -> config-pinned (stabilize) -> runtime-authorized (production hardening).
Disabled toolsets (MCP opt-in) vs runtime policy controls
"Disabled toolsets" and MCP opt-in are static capability gating. They decide what classes of tools are even visible to the agent before a run begins, often through startup config or allow/deny lists. This is excellent for shrinking the exposed surface area and aligning environment defaults.
Runtime policy is different: it evaluates each attempted action at execution time, using context such as user identity, resource sensitivity, task type, environment, and time window. Static gating answers "can this tool exist in this environment?" while runtime policy answers "can this exact action happen right now?" You generally need both: static controls for baseline reduction, while runtime controls complement them by reducing misuse within that surface.
Permit as an enforcement layer for dynamic runtime authorization and JIT grants
After static pinning is in place, Permit can be used as one of the enforcement layers to manage access control and permissions, potentially deciding whether a specific tool call is allowed at runtime and under what conditions. This enables just-in-time (JIT) grants for sensitive actions, such as temporary terminal execution or external connector use, with explicit TTLs and revocation.
In this model, the agent requests capability, Permit evaluates policy, and the execution gateway allows or blocks the call. You can encode constraints like "browser read-only for 15 minutes," "terminal only in sandbox directory," or "MCP connector limited to project X." The result is measurable least privilege: bounded scope, bounded time, and audit trails tied to each decision.
Risk classification by capability type
| Capability | Typical risk level | Primary failure mode | Default recommendation |
|---|---|---|---|
| Read (local/project files) | Medium | Data leakage | Allow scoped read paths only |
| Write (files/config) | High | Integrity damage, persistence of malicious changes | Deny by default; grant per task with rollback/logging |
| Execute (scripts/binaries) | Critical | Full host compromise, lateral movement | Off by default; sandbox + short TTL grants |
| Delegate (spawn sub-agents/tool chains) | High-Critical | Privilege amplification, loss of control plane visibility | Off by default; strict parent-child policy inheritance |
| Browse (web access) | Medium-High | Prompt injection, exfil via remote content | Read-only browsing, domain/egress controls |
| MCP connectors | High | Overbroad third-party system access | Connector-specific scopes; explicit opt-in |
| Terminal | Critical | Arbitrary command execution | Disabled baseline; JIT with command/path constraints |
| Memory (long-term agent memory) | High | Sensitive retention, policy drift via poisoned memory | Minimal retention, encryption, approval for writes |
Temporary grant guidance for browser, terminal, MCP, memory, and delegation
For web browser access, grant short read-only sessions and restrict high-risk domains, downloads, and automatic form submission. For terminal, use ephemeral sandbox environments, command allowlists, and strict directory boundaries with automatic expiration after task completion.
For MCP connectors, issue connector-scoped tokens with least privileges (for example, read-only repo metadata instead of full repo admin). For memory, allow read more often than write, and require explicit approval for durable writes to long-term memory stores. For delegation, require inheritance of equal-or-lower privileges only, plus hard limits on recursion depth and number of spawned agents.
Safest default permission model for local agents
The safest local default is: blank slate startup, config-pinned minimal toolsets, and runtime approvals for any write/execute/delegate/MCP action. Keep browsing read-only, disable terminal unless explicitly needed, and treat long-term memory writes as privileged operations.
In practical terms, local developer productivity remains good when you provide a small "safe starter bundle" (basic read tools plus constrained browse) and let everything else be JIT-approved. This preserves experimentation while preventing silent escalation.
Migration checklist for local and enterprise teams
Local teams
- Inventory all enabled tools and map them to read/write/execute/delegate classes.
- Move to blank-slate defaults and pin only essential toolsets.
- Add short-lived grants for terminal, MCP, and memory writes.
- Add session logs for every tool call and denial event.
- Introduce rollback/cleanup for write and execute workflows.
Enterprise teams
- Define policy tiers by data sensitivity and environment (dev/stage/prod).
- Separate static baseline controls (toolset pinning) from runtime authorization policy.
- Enforce JIT grants with expiry, reason codes, and approval paths for critical actions.
- Integrate audit logs with SIEM/GRC controls and incident response playbooks.
- Run red-team exercises for prompt injection, over-delegation, and connector abuse.
- Set measurable targets: fewer standing privileges, shorter grant lifetimes, lower denied-to-incident ratio.
Frequently asked questions
What is zero standing permissions for AI agents in one sentence?
It is a security model where an agent starts with no durable sensitive access and receives only narrowly scoped, time-limited permissions when needed. The goal is to eliminate always-on authority that can be abused by errors or attacks. In practice, this combines default-deny startup, explicit allowlists, and runtime checks.
Should AI tools really start disabled by default, even for internal teams?
Yes, because internal environments still face prompt injection, accidental misuse, and credential overreach. Starting disabled shifts risk decisions from implicit defaults to explicit approvals. Teams can still preserve velocity by predefining small safe bundles for common tasks.
How is MCP/toolset opt-in different from runtime policy enforcement?
MCP/toolset opt-in is a static pre-run control that decides what capabilities are available at all. Runtime policy evaluates each attempted action in context and can allow, deny, or constrain it dynamically. Static controls reduce surface area, while runtime controls reduce misuse within that surface.
Which permissions are highest risk: browse, terminal, memory, or delegation?
Terminal and unrestricted execute privileges are usually the highest risk because they can lead to host compromise. Delegation can become similarly dangerous if child agents inherit broad rights. Memory and browsing are also significant because they can cause long-lived data leakage or policy bypass, especially without scoped controls.
What are practical temporary-grant defaults for browser, terminal, MCP, memory, and delegation?
Use short TTL grants with explicit scope per capability and automatic revocation at task end. Keep browser read-only, terminal sandboxed, MCP connector-specific, memory writes approval-gated, and delegation depth-limited. The unifying rule is "least privilege plus least duration."
What is the safest default model for local agents?
Use blank-slate startup with only minimal read capabilities pinned, then require JIT authorization for write/execute/delegate/MCP and durable memory writes. This creates a strong security baseline without preventing development workflows. It also makes every privileged action auditable and revocable.
How should teams migrate from all-on-by-default without breaking productivity?
Adopt a phased rollout: inventory current tool use, pin minimal defaults, then add runtime authorization for high-risk actions. Start with visibility and logs before hard enforcement, so teams can tune policy with real usage data. This staged approach preserves delivery speed while steadily reducing standing privilege.