What access should an AI agent have when nobody owns security

Short answer. Most of the danger sits in the permissions that came bundled with the connection. OWASP calls this excessive agency: the integration granted delete alongside read because that was the easy way to wire it. Three questions per connection cover most of it, and a founder can answer them in an evening.

You connected an agent to the CRM. It worked. Now it wants the mailbox, and you notice you have no rule for saying yes or no.

So you search, and every result is written for somebody else.

What is the risk, in plain words?

The agent ends up holding the permissions that came in the box rather than the ones the job needed. After that, one misread request is enough.

OWASP publishes a list of the ten things that go wrong with applications built on language models, and this one has its own entry: excessive agency. The description is refreshingly concrete for a security document, and worth reading in its own words rather than mine.

Two of its examples cover most of what actually happens.

In the first, a developer needs the agent to read documents from a repository. The third-party extension chosen for the job also happens to modify and delete them. Nobody decided to grant deletion. It arrived with read access.

In the second, an extension was tried during a build, dropped in favour of something better, and never disconnected. The agent still has it.

Notice what neither example involves: a clever attack, or a model behaving strangely. In both, the system does exactly what it was permitted to do. The difference between "the agent made a mistake" and "the agent had the means to make that mistake" is the whole subject, and only the second one is under your control.

The risk therefore grows with connections rather than with model quality. A better model connected to everything is a larger problem than a worse model connected to one thing.

Why does the published advice not fit you?

Because it is written for people who have somebody to carry it out. That does not make it wrong. It makes it unusable at your size.

Read the results for this question and the authors are identity and network security vendors writing for enterprise access teams. Their vocabulary tells you the intended reader: microsegmentation, attribute-based access control layered over role-based access control, ephemeral credentials issued at task initiation and revoked at completion, continuous behavioural monitoring, agents as first- class identities with verifiable credentials.

All of that is real and all of it is correct. It also assumes a person whose job is access review, a platform that issues short-lived tokens, and a budget line for both. In a company of twenty, the founder grants permissions through a web interface on a Tuesday afternoon.

Two ideas from that world do survive the trip, and they are the ones worth keeping. Give a connection only what its task needs. And be able to find out afterwards what it did.

Everything else in those articles is scaffolding for organisations that need to enforce those two ideas across thousands of identities. You need to enforce them across six.

The three questions to ask of every connection

Ask what it reads, what it changes, and what it can do that cannot be undone. The third question matters more than the other two combined.

Sort every connection into those three columns before you approve it, and the approval becomes obvious.

Reading is the cheap one. An agent that can read the calendar and nothing else can waste your time and cannot cost you money. Most useful work sits here, which is worth knowing before you grant anything heavier.

Changing is where care starts, and it splits by reversibility. An agent that updates a CRM field is doing something you can undo in a minute. An agent that sends a message to a customer is doing something you cannot.

Irreversible is the short list that deserves the long conversation: money leaving the company, anything sent to a person outside it, deletion, and changes to who can reach what.

OWASP's own mitigation is the one to copy here, and it is a design instruction rather than a security product: avoid open-ended extensions. An extension that runs a shell command or fetches an arbitrary URL can do anything those can do, which is everything. A narrow function that writes one kind of file to one place can only do that. When a vendor offers you the general tool and the specific one, the specific one is the answer, even when it is more work to wire up.

The rightmost column is the one that needs a person, and the row that has nothing safe in the middle is the row where the agent should be read-only.

What stays with a person?

Everything in that last column. The confirmation is a step in the flow, not a setting on the model.

This distinction matters more than it sounds. Telling a model to ask before doing something irreversible makes the safety a property of the instructions, and instructions are advice. Building the confirmation into the connection makes it a property of the system, and the system does not have an off day.

In practice that means the agent prepares the action and something else commits it: a person clicking approve, a second service checking a rule, a limit that blocks anything over a threshold. Our AI integration work is built this way round, with role-based permissions, approvals, limits and a full record of what was done. None of that certifies anything. It means the irreversible steps have a gate in front of them rather than a sentence in a prompt.

One caution is worth stating here. This article describes practice, not compliance. If your business handles regulated data, the questions above are a starting point and your obligations are a separate conversation with somebody qualified to advise you.

How do you check what is already connected?

Make a list of the connections and find out what each one can actually do, which is rarely what you had in mind when you approved it.

This takes about an hour, and it is the highest-value hour in this article, because everything above applies to the next connection while this applies to the ones already live.

1. List every integration the agent can reach. Not the ones you use. The ones it can call. Those are different lists and the gap between them is usually the finding.
2. Open each one and read the scope it was granted. Look for the pattern from the OWASP example: full access where read-only would have done, granted because full access was the default option in the dialog.
3. Disconnect what is no longer used. The dropped extension that stayed connected is the second example OWASP gives.
4. Check that something records what was done. If an action happens and nobody can reconstruct it afterwards, an incident becomes an argument. This is the part small companies skip and the part they need first, because without it the answer to "what happened" is a guess.

That is the whole method. It is unglamorous, it needs no platform, and it addresses the two ideas from the enterprise literature that were worth keeping.