Stop Asking the Agent Every Five Minutes
Permission dialogs look like control. Mature deployments constrain the blast radius, then reserve human judgment for real boundary crossings.
Anthropic looked at how people respond to Claude’s permission dialogs and found they approved roughly 93 percent of them.
At that rate, the dialog is not a control. It is a reflex with a button.
The first version of enterprise agent safety often puts a human confirmation in front of every consequential action. Read this file? Run this command? Reach this domain? Install this package? The design feels cautious because nothing happens without consent.
Then the prompts arrive all day. People stop reading. The agent learns to ask in smaller increments. The least technical employees face the hardest-to-interpret commands. “Human in the loop” becomes “human clicking through.”
Mature agent deployments are moving toward a different rule: make routine work frictionless inside a hard boundary, and interrupt only when the agent wants to cross it.
Approval fatigue is a security bug
Anthropic’s May containment report describes an OS-level sandbox for Claude Code. Reads are broadly available, writes stay inside the workspace, and network access is denied by default. On macOS the system uses Seatbelt; on Linux it uses bubblewrap. Anthropic says the change cut permission prompts by 84 percent.
Fewer prompts can be safer when the remaining prompts mean more.
The sandbox does not ask a person to understand every shell command. It enforces a policy whether the person is attentive or tired. A compromised dependency cannot quietly write across the home directory. A prompt injection cannot call an arbitrary server merely because the user approved a previous tool.
Anthropic still treats sandboxing as one layer. Sandboxes can have escapes. Model defenses are probabilistic. External attackers, ordinary software exploits, user misuse, and model misbehavior need different controls.
The point is not to eliminate review. It is to stop spending review on actions the system should decide mechanically.
Put the boundary around the workflow
Do not grant authority based on the model’s brand or benchmark score. Define the maximum blast radius of the workflow.
| Action | Default | Control |
|---|---|---|
| Read approved workspace data | Allow and log | Read-only mount or scoped connector |
| Write reversible artifacts | Allow and log | Workspace-only write plus version control |
| Reach known business services | Allow narrowly | Domain allowlist and scoped account |
| Fetch unfamiliar code | Isolate or review | Disposable sandbox and egress gate |
| Access secrets or production data | Deny by default | Brokered credentials and least privilege |
| Publish, pay, delete, or change privilege | Explicit review | Target preview and auditable intent |
The boundary belongs to the job. A research agent may read public websites and write a draft, but not publish it. A support agent may query one customer’s ticket and propose a credit, but not issue an unlimited refund. A coding agent may change a branch and run tests, but not push to production.
Inside that boundary, let the agent work. At the edge, ask one useful question: what will happen, to which target, and how can it be reversed?
Credentials should not live where the agent writes code
OpenAI describes a similar pattern in its internal Codex deployment. The company combines sandboxing with an approval policy, controls outbound network destinations, keeps CLI and MCP OAuth credentials in the operating system keyring, pins login to the enterprise workspace, and manages configuration centrally.
That separation prevents generated code from casually reading the token that gives it authority. The agent receives a narrow capability through a brokered tool or short-lived identity instead of inheriting the user’s ambient credentials.
Subagents should narrow again. A worker spawned to inspect documentation does not need the parent’s production database role. A test runner does not need outbound email. Fresh identities make the delegation boundary visible and revocable.
This is ordinary least privilege applied to a system that can invent its next action.
Log the request, not only the process
Endpoint logs can tell you that a shell ran curl. They may not tell you why.
OpenAI exports agent-native OpenTelemetry events for user prompts, approval decisions, tool results, MCP use, and network allow or deny events. A useful trace connects five things:
- User intent.
- Agent proposal.
- Policy decision or human approval.
- Tool result.
- Final artifact or side effect.
That chain is what an investigator needs after a bad action. It is also how a security team improves policy without blindly broadening access. Repeated denials may reveal a missing safe path. Repeated approvals may reveal a boundary that should be encoded. Interrupted actions may reveal a confusing preview.
Logging full prompts can create privacy and retention problems, so decide on redaction, access, and retention before turning everything on. Observability is also authority.
Measure the prompts you removed
Track prompts per successful task, auto-approval rate, denied egress, interrupted actions, and the maximum set of assets each workflow can reach. Review whether the remaining prompts correspond to money, external communication, irreversible data loss, or privilege changes.
If people approve 93 percent of prompts, do not train them to click more carefully. Move the common safe path inside containment. Make writes reversible. Remove ambient credentials. Narrow network access. Show a meaningful preview at the boundary.
The human should supply judgment the policy cannot encode. Everything else is a job for the sandbox.
Anthropic and OpenAI figures describe their own products and deployments. They are field evidence, not universal baselines. Containment reduces risk; it does not eliminate sandbox escapes, software vulnerabilities, or malicious use.
Tim CheungEditor · platform and adoption
Tim edits Supasifu and has spent his career deploying AI inside enterprises. He writes about the platform engineering underneath it — the pipelines, evals, and guardrails that decide whether a system survives contact with production — and about onboarding: how you get a whole organisation using AI without breaking how it already works.
