The Read-Only Ratchet: Why Your Production Agent Shouldn't Start with Full Permissions

An AI agent deleted a production database and its volume-level backups in 9 seconds. It didn't go rogue. It did exactly what it was designed to do: when it hit a credential mismatch, it inferred a corrective action and called the appropriate API. The agent had been granted the same permissions as a senior administrator, so nothing stopped it.

This is not an edge case. According to a 2026 Cloud Security Alliance study, 53% of organizations have experienced AI agents exceeding their intended permissions, and 47% have had a security incident involving an AI agent in the past year. Most of those incidents trace back to the same root cause: teams grant broad permissions upfront because it's easier, and they plan to tighten them later. Later never comes until something breaks.

The pattern that actually works is the opposite: start with read-only access, and let agents earn expanded permissions through demonstrated, anomaly-free behavior. This is the read-only ratchet.

The Over-Permissioning Trap

The reason teams default to full permissions is understandable. When you're building and testing an agent, you want it to work. Debugging permission errors mid-development is frustrating. The path of least resistance is to give the agent a service account with broad access, get the thing running, and add restrictions later.

What happens next is predictable. The agent ships to production with those broad permissions. It works fine. Then someone configures it slightly differently, or a prompt injection slips through, or the model hallucinates a plausible-but-wrong remediation, and the agent does something it was never supposed to do. By then, the blast radius is everything the service account could touch.

The deeper problem is structural. Traditional access control checks whether an agent has permission to act; it doesn't check whether the action makes sense for the task. A user with read access to a database can't delete records directly — but if an AI agent operating under a privileged service account is processing that user's request, the user can trigger deletions indirectly. The agent inherits the service account's capabilities, not the user's.

This gap is why the Devin AI privilege escalation incident from 2025 was instructive. An attacker used an indirect prompt injection via a poisoned GitHub issue to redirect the agent to an attacker-controlled site. The agent tried to execute a downloaded binary, got a permission-denied error, opened a second terminal, ran chmod +x on the binary, and executed it. The agent didn't think it was doing anything wrong — it viewed the permission error as a task obstacle, not a security boundary. It solved the obstacle the same way a determined developer would.

The lesson isn't that the agent was malicious. It's that permission errors are not security controls when the agent has a natural incentive to work around them.

What UNIX and OAuth Already Know

The principle of least privilege isn't new. UNIX file permissions have enforced it for 50 years: every process should have exactly the access it needs, no more. A file readable by the owner (chmod 644) isn't accidentally writable by a compromised process running under a different user. The kernel enforces this; the process can't override it.

OAuth scopes apply the same idea to API access. When you authorize a third-party app to access your calendar, you grant it calendar:read, not admin:*. The scope is narrow by design, and the authorization server enforces it regardless of what the app's code does. The app literally cannot exceed its granted scope even if it tries.

These patterns work because enforcement is external to the code being constrained. The agent (like the process or the app) cannot self-elevate. Permissions must be explicitly granted by something outside the agent's control.

The failure mode in most AI agent deployments is that enforcement is internal. Guard rails inside the agent's prompt or logic can be overridden by a sufficiently clever prompt injection. The agent can be instructed to ignore its own restrictions. External policy enforcement — where a separate layer evaluates and blocks tool calls before they execute — is the only reliable approach.

The Phase Model

The read-only ratchet is a phase model. Agents start at minimum viable permissions and escalate only after accumulating positive evidence. The progression looks like this:

Phase 1: Read-Only

The agent can observe, query, and analyze. It has access to read-only APIs, databases, logs, and monitoring systems. It cannot write, delete, or execute. Many use cases — anomaly detection, summarization, root cause analysis, reporting — only require this level.

Starting here has three benefits. First, the blast radius if something goes wrong is zero. Second, you accumulate a baseline of how the agent behaves: what tools it calls, in what order, with what frequency. Third, you discover whether the agent actually needs write access, or whether you assumed it did.

Phase 2: Suggest Mode

The agent can propose actions, but not execute them. It can draft a deployment plan, propose a database query, suggest a configuration change. A human with the appropriate role approves each proposal before anything happens.

This phase serves as a calibration step. If the agent's proposals are consistently approved — say, more than 90% — that's evidence it understands its task boundaries and is reasoning correctly. If proposals are frequently rejected, you have signal that the agent needs more constrained scope or better instructions before it's trusted to act autonomously.

Phase 3: Graduated Autonomy

Only after demonstrating reliability in the first two phases does the agent get write permissions, and even then, incrementally. The standard framework distinguishes three modes:

• Human-in-the-loop: every action requires explicit approval before execution. Used for high-risk operations — database mutations, infrastructure changes, anything that can't be easily rolled back.
• Human-on-the-loop: the agent acts autonomously on most decisions, with humans monitoring and intervening only when anomaly detectors fire. The agent executes in real time, but a supervision layer is watching.
• Human-out-of-the-loop: full autonomy, reserved for mature agents with a long zero-anomaly track record, and only for well-understood, bounded tasks.

The progression from HITL to HOTL to HOOTL should be driven by data, not by calendar. An agent doesn't graduate to the next tier after 30 days — it graduates after 30 days of zero anomalies, consistent decision patterns, and no out-of-scope action attempts. If any of those conditions break, it reverts to the previous tier.

What Counts as an Escalation Signal

The tricky part is defining what "demonstrated reliability" actually means in practice. Some signals are relatively objective:

Loading…