Least-Privilege Isn't Enough to Govern AI Agent Writes

Reference · Updated 26 August 2026

Least-privilege is the right first move, and this page is not an argument against it — scope every agent tightly, hand it no privileged service account, and you'll thank yourself. But access control answers one question — may this agent write here? — and there is a second one it structurally cannot answer: is this write correct? Inside any non-empty write grant, a hallucinated value or an injected instruction still produces SQL the permission allows, and it commits. Least-privilege bounds the blast radius; it never judges the value. OWASP's own guidance on Excessive Agency says as much — it pairs least-privilege with a human gate for high-impact actions. The two are halves of one answer, not competitors.

Two different questions

It's worth being precise about what each control decides, because the whole confusion comes from collapsing them:

• Access control (RBAC, least-privilege, scoped tokens) decides whether a principal may perform an operation on a resource. Output: allowed / denied. It reasons about identity and permission.
• A write-gate decides whether a specific proposed change should commit. Output: approve / reject, on a concrete before → after. It reasons about the value.

These aren't the same question wearing different clothes. "This agent is allowed to update customers.mrr" and "setting customers.mrr to 188,000,000 is correct" are independent facts, and least-privilege only ever establishes the first.

What least-privilege does well — credit where it's due

Give least-privilege its full due, because you need it regardless of what else you add. It shrinks the blast radius of anything that goes wrong: an over-broad token, a compromised prompt, a buggy tool. OWASP's LLM06 (Excessive Agency) makes it a headline mitigation — limit an extension's permissions to the minimum necessary, run on least-privilege identities tied to each user's context, never use a privileged service account for general model operations, and remove unused tools and functionality. That directly counters two of the three root causes OWASP names — excessive functionality and excessive permissions. Skipping least-privilege isn't an option this page endorses. It's the floor.

Where it stops: the granted scope is still non-zero

Here's the gap. Least-privilege reduces what the agent can touch — but for the agent to do its job, that set can't be empty. And within whatever remains, every write the permission allows is a write the permission will wave through, regardless of whether the value is right.

Grant an agent exactly one capability — UPDATE customers.mrr WHERE id = ?, nothing else — and you've done least-privilege well. The agent is still free to set mrr = 188,000,000 when it meant 1,880,000. No permission was exceeded; the token wasn't over-scoped; RBAC has nothing to object to. The write is authorized and wrong. Access control saw a permitted operation and did precisely its job — which is why it can't be the thing that catches this. You cannot tighten a permission until it means "only the correct value," because the permission doesn't know what the correct value is. Only a human (or a policy) looking at the specific change does.

Prompt injection turns a scoped, privileged path into a confused deputy

The gap gets actively exploited. A confused deputy is a program with legitimate authority tricked into misusing it on someone else's behalf — and a prompt-injected agent is the textbook case. The agent holds exactly the narrow write permission you granted; hostile text (in a support ticket it reads, a web page it browses, a row it queries) supplies the intent; and the agent dutifully issues a write that sits squarely inside its allowed scope. Least-privilege did its job — the write was within the grant — which is exactly why it didn't help. And you can't close the hole by sanitizing the input: national cyber-security guidance is explicit that prompt injection is not SQL injection and can't be fully filtered the way you parametrize a query. A boundary that assumes clean intent inside a valid permission is a boundary with a hole in it.

OWASP itself pairs least-privilege with a human gate

This isn't a contrarian take on the standard — it's what the standard says. OWASP LLM06 breaks Excessive Agency into three root causes: excessive functionality, excessive permissions, and excessive autonomy. Least-privilege attacks the first two. The third — autonomy — is a different lever: OWASP's remedy is human-in-the-loop, requiring approval for high-impact actions, with the model drafting the action and final execution depending on human confirmation. Updating records, publishing content, sending messages: draft by the agent, commit by a human. Least-privilege and a human gate are listed side by side because they cover different root causes. Doing one and calling it done leaves the third cause — autonomy over the actual write — unaddressed.

What each control actually decides

Laid out by the question each one answers:

least-privilege     gates the PERMISSION
                    "may agent write customers.mrr?"  ─▶ allowed
                                                            │
                                    agent writes mrr = 188,000,000  (authorized · wrong · committed)

write-gate          gates the VALUE
                    proposed:  mrr  1,240,000 → 188,000,000  ─▶ [ PENDING ]
                                                   human: "that's 100× off" ─▶ reject
                    proposed:  mrr  1,240,000 → 1,880,000     ─▶ approve ─▶ commit

Do both — they're different layers

The takeaway isn't "replace least-privilege." It's "least-privilege plus a control that judges the write." Least-privilege sets the outer bound — the smallest set of tables and operations the agent could ever touch. A write-gate sits inside that bound and judges each specific change: the proposed write lands PENDING, a human (often a non-engineer who owns the data) approves the concrete before → after, it commits fail-closed against live state, and every step is recorded in a tamper-evident log. One caps the blast radius; the other stops the wrong-but-authorized write. Use both, and the "excessive autonomy" root cause OWASP names is finally covered. For where this sits relative to auditing a write after it lands, see Preventive vs Reactive AI Agent Governance; for the database specifics, human approval for AI agent database writes.

FAQ