2938 Members
Join Permit's SlackTeams 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.
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.
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.
| 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" 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.
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.
| 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 |
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.
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.
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.
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.
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.
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.
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."
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.
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.
Co-Founder / CEO at Permit.io
