AI Agent Permission Policies That Actually Work
Design AI agent permission policies with allow, block, and require-approval decisions. Includes least-privilege examples for shell, files, Stripe, databases, email, and deploys.
AI agent permission policies decide whether an agent may perform a structured action before that action runs. A useful policy is not a long list of tool names. It is a decision rule that combines agent identity, tool, action, target, environment, volume, and rollback context, then returns allow, block, or require approval.
Why “the agent has access to the tool” is not a policy
Many agent setups stop at installation: the IDE has shell access, the MCP server has a Stripe token, the automation can write to production. That grants capability, not authorization. The same shell tool can run tests in a sandbox or delete a customer upload directory. The same database connector can read a staging table or drop a production schema. Without an action-time check, every capability is available whenever the model chooses it—including when untrusted content steers the choice.
This is the same reason Pre-Write Scanning vs SAST: Why Static Analysis Misses What AI Agents Actually Do separates artifact analysis from action control. A repository scan can find risky code after it exists. It cannot decide whether this agent should refund a payment, push to main, or send email right now. For the broader control set around identity, sandboxing, memory, and incident response, use AI agent security checklist for developers.
The three decisions every agent policy needs
| Decision | When to use it | Example |
|---|---|---|
| Allow | Low blast radius, reversible or cheap to undo, and clearly inside the agent’s role. | create_issue on Linear, read a file under /src, run unit tests in CI. |
| Block | Irreversible damage, out-of-scope environments, or actions that should never be agent-driven. | rm -rf on uploads, push to main, drop production tables, bulk email blasts. |
| Require approval | Valid work with high impact, money movement, production writes, or weak rollback. | Stripe refunds above a threshold, production deploys, auth/billing file edits. |
Approval is not a synonym for “maybe later.” The real operation must wait for a decision. A control that logs a warning and still executes is observation, not enforcement. Approvals should also expire, show enough context for a human to decide, and apply to a bounded action—not an open-ended “trust this session forever” grant.
What a permission check should evaluate
A durable AI agent authorization check looks like an access-control decision, not a prompt instruction. Evaluate structured fields outside the model:
- Agent identity: which agent, which runtime, and which human or service account it acts for.
- Tool and action: named operation such as refund_payment, file_write, or run_migration—not free-form text.
- Target: repository path, branch, database, customer id, domain, or deployment environment.
- Environment: development, staging, or production, with separate defaults.
- Impact signals: record count, amount, file sensitivity, irreversibility, and rollback availability.
- Context from prior decisions: repeated denials, recent approvals, and policy version.
// Unsafe: the model invents a command and the host runs it
const command = await model.planNextStep(task)
await shell.exec(command)
// Safer: the agent requests a named action; policy decides first
const request = ActionSchema.parse({
agentId: 'coding-agent-prod',
tool: 'stripe',
action: 'refund_payment',
environment: 'production',
input: { amount_usd: 480, payment_id: 'pi_123' },
})
const decision = await checkPermission(request)
// decision: allow | block | require_approval
if (decision === 'block') throw new Error('Policy blocked action')
if (decision === 'require_approval') await waitForHuman(request)
await approvedTools.stripe.refundPayment(request.input)Least-privilege policy examples you can copy
Start with fail-closed defaults, then open narrow paths. The examples below match common coding-agent and automation setups. Adjust thresholds to your risk tolerance, but keep the structure: tool pattern, action pattern, environment, conditions, and effect.
1. Source control: no direct pushes to protected branches
- Allow: create branch, open pull request, comment on PR, push to feature/*.
- Block: push or force-push to main, master, or production.
- Require approval: merge to release branches if your team allows agent-assisted releases at all.
Agents should prefer a reviewed pull-request path. Direct main writes turn a model mistake into a production incident without the normal review gate.
2. Files: free movement in app code, gates on secrets and billing
- Allow: read/write under application source directories required for the task.
- Block: read or write .env, *.pem, key stores, credential files, and secret-manager dumps.
- Require approval: edits under auth, billing, payment, identity, or production config paths.
File policy is also a secrets control. If an agent cannot open .env, it is harder to paste a live key into a client component or a commit. Pair this with Secret Leaks in AI-Generated Code: How Agents Expose API Keys for pre-write secret scanning.
3. Payments: small refunds vs money movement
- Allow: read payment status, list recent charges with redacted customer fields, create support notes.
- Require approval: refunds above a money threshold, payouts, subscription cancellation at scale, or any action that moves funds.
- Block: export full card data, change payout bank details, or disable fraud controls.
A practical Stripe-style rule is “refunds over $200 need approval.” The number is less important than having a numeric condition outside the model. Soft limits the agent “promises to respect” are not controls.
4. Database: production writes are not development writes
- Allow: read-only queries in non-production with row limits.
- Require approval: insert, update, delete, and migrations in production.
- Block: drop, truncate, delete-without-where patterns, and schema destruction.
5. Email and messaging: stop bulk sends by default
- Allow: single-recipient support replies in staging or with a test inbox.
- Block: recipient counts above a small threshold, marketing lists, or arbitrary attachment exfiltration.
- Require approval: customer-facing messages in production when content is agent-authored.
6. External APIs and MCP tools: allowlist destinations
- Allow: named operations against approved hosts and methods.
- Block: unknown domains, raw SSRF-style URL fetchers, and tools that accept arbitrary shell.
- Require approval: new OAuth scopes, production credentials, or first use of a high-risk MCP server.
Treat every MCP server as executable integration code. MCP security risks for Claude Code users covers publisher review, scopes, launch commands, and local-host risk before you wire the connector into policy.
A starter policy matrix for coding agents
| Capability | Development | Staging | Production |
|---|---|---|---|
| Read application source | Allow | Allow | Allow |
| Write application source | Allow with pre-write scan | Allow with pre-write scan | Require approval or PR-only |
| Read .env / secrets files | Block | Block | Block |
| Install packages | Allow with registry checks | Require approval | Require approval |
| Shell / destructive filesystem | Allow in sandbox only | Require approval | Block |
| Database writes | Allow on local DB | Require approval | Require approval / block destructive |
| Payments / refunds | Block or mock only | Require approval | Require approval |
| Deploy / release | Allow to personal preview | Require approval | Require approval |
| Push to main | Block | Block | Block |
How to write policies teams will keep
- Name the business outcome: “protect main,” “gate refunds,” “no production drops”—not “rule 17.”
- Prefer allowlists for operations and destinations over endless blocklists of bad strings.
- Scope by environment so developers are not blocked on safe local work while production stays tight.
- Put numeric and path conditions in the policy engine, not in natural-language system prompts.
- Review policy changes like code: owner, version, diff, and rollback.
- Log allow, block, and approval outcomes with agent identity, tool, action, target, and redacted arguments.
- Re-test after prompt, model, tool, or MCP changes. Policies rot when the agent gains new tools silently.
Common failure modes
- One shared admin token for every agent, so least privilege is impossible.
- Tool-name allowlists without action, path, amount, or environment conditions.
- Approval fatigue from gating harmless work, which trains humans to auto-click approve.
- Silent auto-approve after timeout instead of fail-closed or explicit expiry.
- Policies that live only in a system prompt and cannot be unit-tested.
- No link between a blocked action and an incident runbook when something still slips through another path.
Prompt injection remains relevant because hostile content often tries to use existing tools rather than invent new ones. How to detect prompt injection in AI-generated code explains source-to-sink review; permissions decide whether a hijacked goal can still execute a dangerous tool. For the full code-and-agent picture, read Vibe Coding Security: The Complete Guide to Securing AI-Generated Code.
How VibeLint applies agent permission policies
In supported agent and automation workflows, the runtime sends a structured permission check before a sensitive tool call. VibeLint can score the action using context such as tool, action, environment, affected volume, and rollback availability, then apply policy effects. Templates cover common patterns: block direct pushes to main, approve production database writes, gate large Stripe refunds, limit bulk email, protect auth and billing file edits, allowlist external APIs, and require approval for production deploys.
The integration boundary is explicit: the agent or workflow must call the check and honor the result. A policy engine that is never invoked cannot protect a bypass path. Pair permission checks with pre-write code scanning so generated secrets, broken auth, and injection patterns are caught before files land, and keep action logs so you can reconstruct who requested what.
Frequently asked questions
What is an AI agent permission policy?
It is a machine-enforced rule that decides whether a specific agent may perform a specific action on a specific target in a specific environment. The usual outcomes are allow, block, or require human approval before execution.
Is a system prompt enough for agent permissions?
No. Prompts are advisory and can be overridden by injection, confusion, or tool output. Permission checks should run outside the model on structured fields and fail closed when the request is unknown or high risk.
What is the difference between blocking a tool and requiring approval?
Block means the action should never proceed through the agent path. Require approval means the action can be legitimate but needs a human decision with full context before it runs. Use block for irreversible or out-of-scope work; use approval for high-impact but sometimes-valid work.
How do I avoid approval fatigue?
Auto-allow low-risk reversible work, block actions that should never be agent-driven, and reserve approvals for money movement, production writes, secret-adjacent paths, deploys, and other high-impact operations. Show enough context on the approval screen that a human can decide quickly.
Should development and production share the same agent policy?
No. Share the same policy language and templates, but use different defaults. Development can allow more local experimentation inside a sandbox; production should be tighter on writes, credentials, payments, and deploys.
Does VibeLint automatically see every shell command?
No. The coding agent, MCP workflow, SDK integration, or automation must submit a structured permission check before execution and must honor allow, block, or require-approval responses.
Sources and further reading
- OWASP Top 10 for Agentic Applications — Covers tool misuse, excessive agency, identity and privilege abuse, and other agent action risks.
- OWASP LLM Top 10: Excessive Agency — Explains over-privileged agents and the need to limit permissions, tools, and autonomy.
- NIST AI 600-1: Generative AI Profile — Maps generative-AI risks to governance, measurement, and management practices teams can operationalize.
- Model Context Protocol security best practices — Official MCP guidance on authorization, scope minimization, and treating servers as security-sensitive integrations.