There is a gap between the permission that gets reviewed and the permission that exists, and in agent deployments it is unusually wide.
Someone requests access for an agent. The request is specific: read this mailbox, so it can triage support requests. It gets reviewed on those terms and approved on those terms.
What the running agent holds is different.
The session default
Most agent frameworks give the agent access to every connected tool, for the full duration of the session.
This is not a bug and it is worth understanding why, because the reason is what makes it hard to change. An agent decides which tool to use while it is working. It cannot declare its needs up front the way a traditional integration does, because the plan depends on what it finds. So the framework hands it everything and lets it choose.
That design is what makes an agent useful, and what makes a demonstration impressive. It is also what makes the grant unreviewable in the form it was reviewed.
So the practical scope is not "read one mailbox". It is the union of every tool connected to that agent at that moment: the calendar connector somebody added last month, the repository tool, whatever writes to the ticketing system, the outbound mail tool.
Why this changes how injection should be rated
Prompt injection is often scored as a model-layer issue and rated accordingly. The session default is what turns it into an access problem.
An injection grants no new privileges. It cannot. What it does is redirect privileges that were already loaded into the session, held by something that will act on them at machine speed.
Which means the severity of an injection against a given agent is a function of the tools connected to it, not of the injection technique. The same payload against an agent with one read-only connector is a nuisance. Against an agent with an outbound mail tool and a repository write, it is an incident.
That reframing is useful in a review because it makes the question answerable. You cannot score the likelihood of a successful injection. You can enumerate the tools.
Three things that change it
1. Scope per task, not per session
The unit of authorisation should be the task, not the conversation.
An agent triaging a support ticket needs the ticketing system and the knowledge base while it does that. It does not need the outbound mail tool, and it does not need repository write access, and it does not need them for the following forty minutes either.
Frameworks vary in how well they support this. Where the framework does not, the fallback is decomposition: several narrow agents with distinct identities and small tool sets, rather than one agent with everything connected. That is more work to build and considerably easier to reason about.
2. Behavioural baselines before the incident
An agent's normal behaviour is more regular than a person's. It calls a predictable set of tools, at a rate that reflects its workload, against a stable set of targets.
That regularity is worth capturing while things are normal, because it is what makes an anomaly legible later. Without a baseline, the first unusual pattern you look at is also your first data point, and you have nothing to compare it against.
This is cheap to do and almost always skipped, because it produces nothing on the day it is set up.
3. Segmentation
If an agent is compromised — by injection, by a poisoned tool description, by a dependency in its own stack — the question that decides the size of the incident is how far it can reach from where it runs.
This is the same control that decides whether an intrusion stays local in any other context, and it fails here for the same reason it fails elsewhere: it blocks nothing visible until the day it does, and it makes day-to-day work slightly harder in the meantime.
The inventory question
Ask for a list of every tool the agent can reach right now.
Not the one it was approved for. Not the ones in the design document. The connectors that are enabled on the running configuration today.
Two things usually come out of that exercise. The list is longer than the person who owns the agent expects, and at least one item on it was added for a task that finished months ago and was never removed.
Both are ordinary. Neither is visible without asking.
Want help putting this into practice?
We work alongside your team to design, build, and operate the controls described above.