AI Agent Access: What To Check Before You Grant It | Alyra

Before an AI agent gets write access, decide its blast radius, whether its actions reverse, and who finds out when it is wrong.

A chatbot that is wrong produces a bad sentence. An agent that is wrong produces a bad record. The useful work happens before anyone grants the first credential.

A chatbot that gets something wrong produces a bad sentence. An agent that gets something wrong produces a bad record, a sent email, a changed field, a cancelled order. The failure moves from embarrassing to operational, and it moves into systems where other people are already working.

That is the whole difference, and it is why the conversation about agents should start somewhere other than capability.

Ask what it can do wrong, not what it can do

Every demo answers the first question. Almost none answer the second. Before an agent touches a production system, three numbers matter more than any benchmark score.

Blast radius: how many records one bad decision can reach. An agent that updates a single record is a different risk from one that runs a nightly batch across a table.

Reversibility: whether you can undo it. A draft is reversible. A sent email is not. A deleted row is not, unless someone keeps backups and someone else knows how to restore them.

Detection time: how long a wrong action sits before a person notices. This is usually the number nobody has, and usually the one that decides whether a small error stays small.

An agent that can touch a thousand records, cannot undo any of them, and is checked once a month is not an automation project. It is an unfunded liability.

Read only is a real deployment

The instinct is to grant write access immediately, because read access feels like a half measure. In practice a large share of the value in the first year is retrieval: finding the clause, reconciling two systems, assembling the answer a person then acts on.

Read only also buys something you cannot get later, which is a record of how the agent behaves on your real data before it can change any of it. Run it that way long enough to find where it is confidently wrong. Every organisation has a shape of error that does not show up in testing, because it comes from how that particular business records things.

Scope the credential, not the agent

Instructions are not a permission system. Telling an agent not to touch finance records is a request. Giving it an account that cannot see them is a control. The second one survives a bad prompt, a model upgrade, and whoever inherits the project next year.

Give the agent its own identity rather than borrowing a person's. Grant the narrowest permissions the task needs. Log its actions separately, so you can tell at a glance what the agent did and what a person did. When something goes wrong, that separation is the difference between an afternoon and a week.

Decide who finds out

Someone has to own the agent's output the way a manager owns a junior colleague's. Not reviewing every action, but accountable for the pattern, and the first call when it drifts.

Name that person before launch. If you cannot name them, the pilot is not ready, and that is a much cheaper thing to learn now than in month four.

The page to write before you start

One page covers it. Which systems the agent can read. Which it can write. What a single mistake can reach. How an action is undone. How a wrong action surfaces, and how fast. Who answers for it. If a line is blank, that blank is the work left to do.

None of this slows a good project down. It is the reason the ones that work are still working after the people who built them have moved on to something else.

Start a conversation