Keep your AI agent on a short leash

The risk isn't the robot uprising

When people worry about giving an AI agent access to their email, files, home automation or a shell, they usually picture the model deciding to do something malicious. That is the wrong thing to be afraid of. The realistic failure is far more boring: the agent does exactly what it was told, but it was told the wrong thing — by a confusing instruction, an ambiguous request, or text on a web page it read that was written to manipulate it — and it happened to have enough authority to make that mistake expensive. Industry security guidance names this failure mode directly. The OWASP Gen AI Security Project defines "Excessive Agency" as "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction." Notice the last clause: it does not matter *why* the model got it wrong. What decides whether a wrong answer becomes damage is how much power you handed it.

Three separate dials, not one

The useful move is to stop thinking of "how much do I trust this agent?" as a single slider and start thinking of it as three dials you can turn independently. OWASP splits the root cause of excessive agency into exactly three: "excessive functionality; excessive permissions; excessive autonomy." They are worth pulling apart because each has a different, concrete fix.

Damage requires all three to line up: a capable tool, broad rights, and no gate. Turn down any one dial and the worst case shrinks.

• **Functionality** — how many tools the agent can reach at all. An agent wired to send email, edit files, call APIs and run shell commands can cause harm in all four ways, even if it only needed one.
• **Permissions** — how much each tool is allowed to do on the systems behind it. A tool that reads your calendar is a very different risk from the same tool holding write-and-delete rights.
• **Autonomy** — how much it can do without a human check. An agent that drafts an action and waits is categorically safer than one that drafts and executes.

Give it the least it needs to do the job

The first two dials are the security principle of least privilege applied to software that talks. NIST's definition is a good yardstick: restrict access "to the minimum necessary to accomplish assigned tasks." For an agent, that means starting from the specific job and adding capability only when the job actually blocks without it — the opposite of the common pattern of connecting everything up front "so it's flexible."

In practice:

• **Fewer tools.** OWASP's own advice is to "limit the extensions that LLM agents are allowed to call to only the minimum necessary." If a task is summarising documents, the agent does not need a send-email tool in the same session.
• **Narrower rights.** Again from OWASP: "limit the permissions that LLM extensions are granted to other systems to the minimum necessary." Prefer read-only credentials, scoped tokens and per-purpose accounts over one high-privilege identity the agent borrows for everything.
• **Enforce it outside the model.** The most important and most missed point: do not let the prompt be the security boundary. OWASP is blunt here — "implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not." A read-only token that the API enforces cannot be talked out of being read-only; an instruction in the system prompt can.

Put a gate in front of the actions you can't take back

The third dial — autonomy — is where an approval gate earns its keep. The rule that scales is not "approve everything" (you will stop reading the prompts within a day) but "approve the actions that are high-impact or hard to reverse." OWASP frames the control as human-in-the-loop: "require a human to approve high-impact actions before they are taken." Their worked example is deliberately mundane — an email assistant made safe by "requiring the user to manually review and hit 'send' on every mail drafted by the LLM extension." The agent still does the work; a person still owns the irreversible step.

A workable line for a home or small-business setup:

• **Auto-run the reversible and low-blast-radius** — reading, searching, drafting, proposing.
• **Gate the irreversible or outward-facing** — sending a message, deleting data, spending money, changing a credential or permission, touching production or anything a real person receives.
• **Make the gate specific.** "Approve action?" trains you to click yes. "Send this exact email to this exact recipient?" gives you something real to check.

What a short leash does and doesn't buy you

Be honest about the limits. A short leash reduces blast radius; it does not make an agent trustworthy in the abstract, and it does not by itself stop a manipulated input from being *tried*. Prompt injection and ambiguous instructions are still real; scoping and gating just mean that when one lands, the agent can propose a bad action but not complete a damaging one unsupervised. Two failure modes to watch: approval fatigue, where too many prompts turn the human check into a rubber stamp — the cure is gating fewer, higher-stakes actions, not more; and privilege creep, where scopes granted for one task quietly outlive it. The recovery path is the point of using scoped, revocable credentials in the first place: when something looks wrong, you can pull one token without dismantling the whole setup.

What we would do next

Look at whatever agent you already run and find its single most dangerous capability — the one action that is outward-facing, irreversible, or costly. Do one thing to it this week: put it behind an explicit approval, or swap its credential for a read-only or scoped one. You do not have to solve all three dials at once. Turning down the most dangerous one first is what converts an agent from something you have to trust completely into something you can let work while you keep the one decision that actually matters.

Sources and limits

This article synthesises the sources below into a practical explanation. It is not a security standard, legal advice, or a guarantee that guidance current at review time still applies — check the review date above against your own situation.

1. LLM06:2025 Excessive Agency — OWASP Gen AI Security Project. Defines Excessive Agency as the vulnerability that enables damaging actions from unexpected, ambiguous or manipulated LLM output; names its three root causes as excessive functionality, permissions and autonomy; and recommends minimising extensions and permissions, requiring human approval of high-impact actions, and enforcing authorization in downstream systems.
2. Least privilege — Computer Security Resource Center glossary — National Institute of Standards and Technology. Defines least privilege as the principle that a system should restrict the access privileges of users, or processes acting on their behalf, to the minimum necessary to accomplish assigned tasks.