Your Agent Is Only As Good As What It Is Allowed To Touch

Ask a team why their agent underperforms and the answer is usually about the model. The prompt is not sharp enough, the context window is too small, a newer model would fix it. Occasionally that is true. Far more often the agent is being asked to do serious work with the wrong view of the world — one system it can read, two it cannot, and a permission set nobody scoped on purpose.

Intelligence is the part you buy. Access is the part you build, and it decides almost everything about how well the finished thing behaves.

The demo runs on credentials nobody would approve

Prototypes are built against a sandbox or, worse, a personal API key with full scope. Every endpoint works, every record is reachable, and the integration feels trivial. Then the pilot moves toward production and someone asks the ordinary security question — what exactly should this thing be able to reach? — and the project loses a month.

The gap is not technical difficulty. Nobody made the access decision while the design was still flexible, so the agent’s behaviour has been shaped around permissions it will not have.

Read first, write later

The single most useful split in agent design is between reading and writing. Reading is low-risk and reversible: fetch the ticket, list the open invoices, look up the customer’s plan. Writing is neither: send the email, issue the refund, update the record, close the deal.

Most agents should start read-only, with writes queued to a human. A read-only agent is useful immediately — summarising, drafting, triaging, flagging — and it lets you measure the quality of its judgement before that judgement can change anything. The failures you see in read-only mode are the ones that would have been expensive.

Promote to write access per action, not per agent. An agent that can draft replies does not need the ability to send them, and the day you decide it can send is a day you should be able to point at evidence. This is the same reasoning that applies to placing the human in the loop, which we covered in where to put the human — access level and review step are two dials on the same decision.

Scope permissions to the task, not the person

The convenient thing is to give the agent a service account with the permissions of whoever requested the project. It works on day one, and it is why so many deployments fail an audit.

Scope instead to what the task requires — ordinary least privilege, applied to a component unusually good at doing something plausible with whatever it is handed:

• Per-tool, not per-system. An agent that needs order status should not inherit an integration that also exposes customer addresses.
• Per-tenant, where tenants exist. A single-agent, all-customers design cannot be sold as multi-tenant later without rebuilding the retrieval layer.
• Read from a view, not a table. Expose a curated read model rather than raw tables. It is the cheapest way to keep the agent away from fields it has no business seeing, and it doubles as documentation of what the agent is expected to understand.
• Time-boxed credentials. Anything long-lived should be rotatable without a redeploy, because the first rotation is always the one nobody planned for.

Humans had context the agent will not

There is a quieter access problem that costs more than permissions: the agent cannot see what a person sees on the screen.

A support agent looking at a ticket sees the customer’s plan, the last three conversations, a red banner saying the account is in collections, and a colleague’s note saying this person has called twice. A model with API access sees the ticket body and maybe the customer record. The missing pieces are not in any single field — they are the relationships between records, and the conventions of the interface.

The consequence is that the agent confidently answers the surface question and misses the reason it was asked. The fix is unglamorous: list what a competent human looks at before acting, then check which of those signals the agent can reach. Whatever is missing either gets retrieved deliberately — a small assembled context block, not a bigger prompt — or the task gets narrowed until the gap does not matter.

Do this before tuning the prompt: it separates an agent that is wrong because it was not told from one that is not smart enough, and only the second is worth spending model budget on.

The integrations are the real work

Every production agent we have seen runs on integrations that took longer than the model work. Not because the APIs are exotic, but because real systems are unhelpful in predictable ways:

• Pagination and truncation. The list endpoint returns fifty of four thousand rows and says nothing about the rest. An agent that assumes it saw everything will report confidently on a fraction of the data.
• Rate limits that arrive mid-task. A workflow that batches its reads to stay under a limit behaves differently under load than in a single test run.
• Stale and partial records. Fields updated by three systems, some of them nightly. The agent has to tolerate a record that is half-populated, and say so rather than guess.
• Non-idempotent writes. Retry logic is table stakes for the model calls and often missing for the actions. Refunding twice is a finance incident.

Each of these needs a decision written down, not just a code path. The useful artefact is a short document per integration: what it exposes, what it does not, what happens when it is slow or down, and who is paged.

Design the refusal

The behaviour that separates a system from a demo is what the agent does when it cannot see what it needs.

The bad default is to proceed. A model handed an empty search result and a clear task will usually produce something reasonable-sounding from general knowledge, which is indistinguishable from a correct answer at the point where it matters. Permission failures that look like thin results are the most dangerous kind, and invisible unless you make them visible.

So make refusal a first-class outcome: no access produces an explicit escalation with the reason attached, not a best-effort answer. Count those escalations, because a sudden rise usually means a credential expired or an integration changed shape — a silent failure that looks exactly like a quiet week, and the same signal the four numbers are built to catch.

Start with the inventory

Before any prompt work on an agent that is underperforming, write down three lists: what it can read, what it can write, and what a competent human would look at before doing the same task. The gap between the second and third list is usually the explanation.

Access scoping is the part of agent design that looks least like AI and decides the most about whether the thing works — which is why we treat it as part of the first design conversation, not an implementation detail left to the end. If you want the shape of that engagement, it is on our services page.