What Can This Agent Actually Touch? Decide Before You Ship, Not After

The pilot works. Somebody demos it, the room is impressed, and there is real appetite to put it in front of customers or staff. Then it goes to whoever owns the CRM, or the billing system, or the patient records, and it stops. Not because anyone said no, but because nobody can answer a simple question: what exactly is this thing allowed to touch?

We have watched this happen enough times to be confident about the pattern. The blocker is almost never the model. It is that agent access was treated as a deployment detail instead of an architectural decision, and now it has to be answered retroactively by people who were not in the room when it was built.

With conventional software, "what does this system access?" is a static question. You wrote the integration, it calls three endpoints, you documented it once, and the answer stays true until someone changes the code. Your security review is a point-in-time exercise and that is fine, because the software does not get creative.

An agent decides at runtime. Given a goal and a set of available tools, it chooses which ones to call and in what order, and that choice varies with the input. The honest answer to "what does it access?" becomes "it depends what you ask it." That is a perfectly reasonable engineering answer and a completely unacceptable governance one.

This is why a one-off access document does not survive contact with an agent. You do not need a description of what it did last Tuesday. You need a model that constrains what it can ever do, which stays true regardless of what someone types into it.

The useful move is to stop thinking about "access to the CRM" as one thing. In practice we tend to end up with four tiers, and getting a client to sort their systems into them is usually the most valuable hour of the engagement.

Reference data is the safe tier: published pricing, documentation, public product information. The agent can read it freely and nothing bad happens if it reads the wrong bit. Scoped reads are next: real business records, but filtered to a defined slice — this customer, this account, this date range — and never the whole table. Scoped writes are where it gets serious: the agent can create or update specific record types under specific conditions, and every write is attributable. Then there is the tier that requires a human: anything that moves money, changes entitlements, contacts a customer, or cannot be undone.

The point of the tiers is not the tiers. It is that once your systems are sorted into them, "what can the agent touch?" has a written answer that does not change when the prompt changes.

When a risk or compliance function asks what the agent can access, they are usually asking two other things underneath it. Who decided this, and on what basis? And if it does something unexpected, what will you be able to show us?

Both are answerable, and both are much cheaper to answer at design time. Deciding the permission model up front means the decision has an owner and a date attached to it. Building the record of agent actions while the agent is acting means you have something to produce later. Neither can be reconstructed convincingly after the fact, and the attempt to do so is where most of the retrofit cost lives.

The counterintuitive part is that this work is cheap early and expensive late. Sorting your systems into access tiers before anyone writes agent code takes a couple of workshops. Doing it after a pilot has been running against production data for six months means unpicking assumptions that are now baked into prompts, tool definitions and user expectations — and usually rebuilding the integration layer underneath.

If you are somewhere between a working pilot and a production decision right now, the most useful thing you can do this week is write down, for each system the agent might reach, which tier it belongs in and who signed off. If that document is hard to write, you have found the real blocker, and it is not the model.

This is the work we do. If you want a second opinion on an agent architecture before it goes in front of a review board, we are happy to look at it.