Agents & MCP
Designing Permission Ladders and Blast Radius Guards for Autonomous Agents
Relying on system prompts like be careful fails because LLM outputs are probabilistic. Robust agent systems separate agent intent from execution authority by evaluating actions against deterministic policy engines. Pre-authorize low-risk, reversible internal actions while enforcing explicit human approvals at irreversible boundaries.
September 10, 2026 5 min read
Curated by Oleksandr Kuzmenko, AI Product EngineerUpdated September 10, 2026Sources cited on every story
AI-assisted · editor-reviewedHow we use AI
Impact: High
Why it matters
You can prevent agent-driven data leaks and accidental production mutations by moving authorization out of prompts and into an application-level policy gate.
TL;DR
- 01Enforce tool execution boundaries in deterministic application code, not via LLM system prompts.
- 02Pre-authorize drafts and isolated replica reads to avoid human review bottlenecks during agent execution.
- 03Redact secrets and sensitive identifiers before feeding database responses into the agent context.
Why System Prompts Are Not Security Boundaries. A prompt instructing an agent to 'only take safe actions' is merely hopeful wording. Because language model tokens are generated probabilistically, tools like delete_repository will eventually be called if exposed directly. Instead, every agent proposal must pass through an application-level authorization layer where deterministic policies verify permissions, rate limits, and budget thresholds before any tool executes. ### The Risk Ladder Pattern. Rather than managing flat, permissive tool lists, map capabilities across an escalation hierarchy: observe, analyze, propose, draft, execute, publish, and destroy. Operations that produce reversible, private artifacts—such as writing local branches or staging draft tickets—should be pre-authorized. This separates computational labor from real-world commitment. ### Preventing Read-Based Exfiltration. Read-only permissions can still present catastrophic blast radiuses if the agent reads production secrets or customer databases and subsequently transmits summaries externally. Mitigate this by enforcing redaction filters at the data-fetching layer prior to context injection, ensuring the model never sees sensitive tokens.
Try it in 2 minutes
const policy = await policyStore.forUserAndAgent(req.userId, req.agentId); if (!policy.isAllowed(req)) { return { allow: false, reason: 'Denied by policy' }; } if (policy.requiresApproval(req)) { return { allow: false, approvalRequired: true }; } return { allow: true };typescript
✓ When to use
- Building autonomous coding agents or workflow bots connected to GitHub, databases, or cloud infrastructure.
- Deploying Model Context Protocol servers that expose internal tools and shared data sources to LLMs.
✕ When NOT to use
- Simple single-turn prompt-response tasks where no external tools or APIs are invoked.
- Completely offline read-eval-print loops operating in isolated temporary Docker containers.
What to do today
- Audit existing agent tools to ensure all write operations default to creating pending draft artifacts rather than executing live mutations.
- Implement a pre-context middleware to redact sensitive keys and PII fields before records enter agent memory.
- Move destructive actions behind an external policy gate requiring explicit human authorization.
Sources