The Agentic Attack Surface: Why Your Permission Model Wasn't Built for This
A user is patient, slow, and forgetful. An agent is none of those things. When you wire an LLM into your stack — through Model Context Protocol, an internal API, a CRM connector — you are handing a workload that does not sleep, does not forget, and does not respect the implicit boundaries your permission model was designed around.
Most permission systems were built on a quiet assumption: the human at the keyboard would only ever try a few things. Agents try everything. Within seconds. In parallel. With perfect recall of every prior call.
That is the agentic attack surface. It is not new vulnerabilities — it is old vulnerabilities at machine scale.
The three mistakes we keep finding
In the last six months we have audited agent rollouts at five mid-market firms across SaaS, healthcare, and analytics. The same three mistakes show up every time.
One: tool surface that scales linearly with agent count. Each new agent gets the same broad MCP server. Each agent inherits every connector, every data source, every callable. Nobody scoped per-role. Nobody asked which tools this specific agent actually needs. Result: an internal-ops agent that can read salary records it has no business touching.
Two: response shapes that leak. An agent answers in natural language — which means whatever your tools return becomes prompt context, becomes output. We have seen agents helpfully include un-redacted SSNs in answers because the tool that surfaced them returned the full record and the agent saw no reason to filter.
Three: no replay, no audit. When asked “what did the agent do at 14:32 last Tuesday?” the firm cannot answer. They have logs of the LLM call. They do not have the typed trajectory of every tool invocation, every parameter, every returned shape. Without that, post-incident analysis is guesswork.
An agent’s permission model is not what your IAM policy says. It is the union of every tool the agent can reach, every parameter those tools accept, and every prompt that can talk it into using them.
What we’d do
A real audit of an agent system, the way we run it:
- Enumerate the tool surface. Not the tools you intend the agent to use — the tools an unbounded prompt could talk it into using. MCP servers expose more than most teams realize.
- Type-check every response shape. A type-safe agent framework is the right primitive here: validated I/O at the boundary means the agent cannot accidentally surface a field that a downstream user is not entitled to see.
- Make the trajectory replayable. Every tool call, every parameter, every return shape — logged with a request ID that ties back to a user and a session. If you cannot replay it, you cannot audit it.
- Adversarial prompt injection. Treat the agent the way an attacker would: malicious tool responses, prompt-injection in user input, role-swap attempts. We test these with the same playbook we use against web apps.
The pattern that lasts: agents you can audit, agents that cannot escape. Everything else is theater.
If you are deploying agents into production and you have not yet had this conversation with anyone outside your AI team — that is the conversation we run on a discovery call. Book one →