Give your AI agent the least access it needs: A permission model for tools, data, and actions

An AI agent should hold the smallest set of tools, data, and actions its job requires, and nothing more. Those are three separate grants: which systems it may call, which records it may read, and which changes it may make without a person signing off. Decide all three in writing before launch. Most agent incidents are permission failures, not model failures.

Essential insights

• Permission design is three decisions, not one. Tools, data, actions. Teams that treat it as a single switch end up with an agent that can email a customer because it needed to read a ticket.
• The model is never the control surface. Whatever decides what is allowed has to live outside the model, because the model can be talked into things.
• One identity per agent, with credentials that expire. A shared service account makes it impossible to say what your agent did, or to switch off only your agent.
• Approvals belong on the irreversible and the outward facing. Put a person in front of everything and your team will click through the prompts without reading them.
• The log is what turns all of this from a claim into evidence. Record the refusals as well as the approvals.

The default that gets shipped

An AI agent is software that takes a goal, plans a few steps, and uses other systems to finish the job. That last part is what makes it different from a chatbot, and it is the part that gets under-thought. Somebody wires the agent into the help desk, the CRM, and the shared drive using whatever credentials were nearest, usually a login that belongs to a manager or an integration account with the run of the building. It works on the first try. That’s the problem. It also works on the day someone sends your support address a message with instructions buried in it.

Almost everything written about agent security is written for companies with a security team. You probably don’t have one. What you do have is the ability to decide, in an afternoon, what your agent is allowed to touch. That decision is worth more than any tool you could buy, and OWASP, the nonprofit that publishes the widely used security guidance for software, agrees in blunt terms: its AI agent guidance says outright not to give agents unrestricted tool access or wildcard permissions, and not to rely on the model's own output for authorization decisions (OWASP AI Agent Security Cheat Sheet).

There is a specific reason least privilege matters more with agents than with ordinary software. It is called prompt injection: text the agent reads gets treated as instructions it should follow. The text can arrive anywhere the agent looks, in a customer email, a web page, a PDF, a ticket comment. OWASP ranks it the top risk in its Top 10 for large language model applications (OWASP). No filter catches all of it, because the agent has no reliable way to tell a genuine instruction from a planted one. So you stop trying to win that fight and you shrink the damage instead. An agent that can only read the reports folder cannot leak payroll, whatever it is told to do. That’s the same logic behind containing the blast radius rather than patching the flaw, applied to the three surfaces below.

Start with the job, written down in one line

Before you grant anything, write the agent's job in a single sentence that names the output. "Answer billing questions in the help desk and draft a reply for review." "Reconcile yesterday's card charges against invoices and flag the gaps." A sentence like that tells you what to grant, because everything not needed to produce that output is not needed.

Vague jobs are how over-permissioning happens. "Help the support team" justifies access to everything support touches. If you cannot write the sentence, you are not ready to grant access; you are still choosing the work, which is a different exercise and a good one to finish first.

Surface one: the tools it may call

A tool is any system the agent can reach: a help desk API, the email sender, a database query, a script. Grant them one at a time, and grant the operation, not the system. Read a ticket is a different grant from close a ticket. Search invoices is different from issue a refund.

Three rules that carry most of the weight:

• Allowlist, never blocklist. Name the tools the agent may use. Everything unnamed is denied. OWASP's example of the wrong pattern is a shell tool with allowed commands set to a wildcard; the right pattern is a file reader scoped to one directory, read only, with secrets excluded by pattern.
• Scope inside the tool. Read only where reading is the job. One folder, one table, one mailbox, one date range.
• Separate tool sets by trust level. The agent that reads inbound customer mail is exposed to hostile text all day. Don’t hand that agent the tools your internal, human-triggered agent uses.

If a vendor cannot tell you which tools their agent holds and at what scope, that’s your answer about the vendor.

Surface two: the data it may read, and what may happen next

Data permissions have two halves, and the second one gets skipped. The first half is what the agent may retrieve. Bind that to the task, not to the company: the reconciliation agent gets last month's transactions, not the general ledger back to 2019. Where your systems already enforce per-user or per-record access, make the agent inherit it rather than bypass it with an admin token. The check belongs in the retrieval layer, before the content ever reaches the model.

The second half is what may be done with what was retrieved. An agent can be allowed to read a contract and still be forbidden to paste it into a ticket, attach it to an outbound email, or repeat it to a different customer. Exfiltration usually is not exotic. It is a legitimate read followed by a legitimate send, chained by an agent that was told to be helpful.

Two practical habits. Treat everything the agent reads from outside as content and never as instruction, which is a design decision in the software and worth asking your builder or vendor about directly. And keep sensitive fields out of the agent's context in the first place: bank details, health information, full card numbers. Redaction before retrieval beats regret after.

Surface three: the actions it may take, and where a person stands

Actions are the writes: sending, deleting, paying, provisioning, publishing, changing who has access. Default every one of them to denied and open them deliberately.

Sort the ones you open into three buckets.

Free. Reversible, internal, low cost, invisible to customers. Drafting, tagging, summarizing, updating an internal field. The agent does these unsupervised or you have bought yourself an expensive way to type.

Approved. Outward facing or hard to walk back. Sending an external email, issuing a credit, closing a customer's account, publishing anything. A person sees the exact action and confirms it. OWASP's guidance on this is worth copying: the approval has to be bound to the specific action, including the target and the parameters, so an approved "send this reply to this customer" cannot become a different send later.

Never. Deleting records in bulk, moving money above a threshold you set, changing permissions, touching production infrastructure. Not an approval, an absence. The tool is not in the agent's list.

Two details separate a real gate from theatre. The agent proposes, something else authorizes; the component that checks the rules is not the component that wants to act. And when any of it breaks, when the check fails or the log is unavailable, the action fails closed rather than proceeding. If you want the version of this argument in the context of a support workflow specifically, the chatbot to agent transition is mostly a sequence of permission gates.

Set your approval line by consequence, not by comfort. Everything gated is the same as nothing gated, because humans learn to click.

Identity: not a person, not your service account

Give each agent its own login. Not a shared integration account, not a borrowed staff account, not the founder's credentials. A 2026 NIST concept paper on software and AI agent identity makes per agent identity the direction of travel for exactly the reasons you care about (NIST NCCoE): you can attribute what happened, constrain it, and revoke it without breaking anything else.

Then make the credentials short lived. A token that expires in an hour and covers one task is worth less to an attacker than a key that has sat in a config file since spring. Keep a list of which agents exist, who owns each one, and what each holds. Agents accumulate quietly; the ones nobody remembers are the ones with permissions nobody reviews.

The log is the deliverable

Log every tool call the agent makes: which agent, prompted by whom, when, which tool, with what parameters, allowed or denied, and what came back. Keep the denials, because a run of refusals is what a manipulation attempt looks like from the outside. Redact sensitive values before they land in the log, or the log becomes the leak.

This is also the only honest answer to "what has it been doing." Without it you are trusting a summary the agent wrote about itself. Agents work; people approve; the record is how anyone can tell the difference later. If you want the permission set to follow from the risk rather than from taste, score the workflow first with the risk assessment framework, then grant against the score.

Doing this in an afternoon

Write the job sentence. List the tools the agent needs, with the operation and the scope for each, and delete anything you cannot justify against the sentence. List the data it may read and one line on what it may do with it. Sort the writes into free, approved, and never. Issue a dedicated login with an expiry. Confirm tool calls are logged and that you can read the log without help. Then try to break it: send the agent a message with instructions hidden in it and see whether it reaches for something it should not have.

That’s the whole model. Not a product, not a project. An afternoon, revisited whenever the agent gets a new tool.

Frequently Asked Questions

How do I secure an AI agent's access?

Securing an AI agent's access means granting tools, data, and actions separately and minimally, then enforcing those grants outside the model. Allowlist specific tool operations, bind data retrieval to the task, deny write actions by default, require bound approvals for irreversible or customer facing actions, and log every call including refusals.

Should each AI agent have its own login?

Yes. Each agent should have a unique identity with short lived credentials rather than sharing a service account or a staff login. Per agent identity is what lets you attribute an action to a specific agent, restrict that agent alone, and revoke its access without disrupting other systems. NIST's 2026 identity work points the same way.

Can permissions stop prompt injection?

Permissions don’t stop prompt injection, they cap what it can achieve. Prompt injection is instruction text hidden in content an agent reads, and no filter catches all of it, which is why OWASP ranks it the top large language model risk. A narrowly permissioned agent that’s successfully manipulated still cannot reach data or actions it was never granted.

What should an AI agent never be allowed to do without a person?

An AI agent should never move money, delete records in bulk, change access permissions, or take irreversible customer facing actions without explicit human approval bound to that specific action. For the highest impact operations, the safer choice is not an approval prompt but omission: leave the tool out of the agent's list entirely.

How secure are AI agents in practice?

AI agents are as secure as their permissions, not as their models. The recurring failures documented across 2026 security guidance are over permissioned tools, over broad data retrieval, unsupervised high impact actions, shared credentials, and missing logs. Every one of those is a configuration decision a business owner controls, which is the encouraging part.