Agentic AI and MCP security
An assistant that produces a wrong paragraph has produced a wrong paragraph. An agent that produces a wrong paragraph refunds an order, edits a record, sends an email, opens a ticket and closes another one. The security question changes with it, and most of the controls written for the first do not transfer to the second.
Start with an agent inventory
Very few organizations can list their agents. The inventory is per agent, and for each one it records: what it can reach, tool by tool and system by system; whose authority it acts under, and whether that is the requesting user, a service account, or a credential nobody has reviewed since it was created; what triggers it, and whether a trigger can come from outside; what it can do without a person in the path; and who owns it.
The last field is the one that changes behaviour. An agent with no owner accumulates permissions and loses none.
Tool permissions against least privilege
Agent permissions are granted the way integration permissions have always been granted — broadly, at setup, by someone trying to make it work. The review walks each tool and asks whether the scope granted matches the scope used; whether read and write are separated; whether destructive capabilities are reachable at all, and by which agent; whether credentials are per agent or shared; and whether anything is scoped per user rather than per deployment.
That last distinction is the one that carries most of the risk, and it has a name.
Confused deputies, and the boundary tests that find them
An agent is a confused deputy whenever its credentials exceed those of the person asking. The user cannot read the finance folder; the agent can; the user asks the agent a question that requires reading it. Nothing is exploited, no control fails, and the answer arrives anyway.
So the testing is behavioural and it is specific: can a low-privilege user reach high-privilege data through the agent; can the agent be induced to act outside its stated mandate; does an instruction that arrives inside retrieved content get treated differently from one typed by the user; and does a request the agent refuses directly succeed when it is decomposed across several turns. These exercise a running system, so they happen only with signed authorization, to a scope agreed in writing.
The categories in play are OWASP LLM06 Excessive Agency and LLM01 Prompt Injection. For the threat model behind them, OWASP’s GenAI Security Project published Agentic AI – Threats and Mitigations on 17 February 2025.
Indirect injection reaching the agent
For a chat assistant, indirect prompt injection produces a wrong answer. For an agent it produces an action. Every channel that brings content the organization does not control into the agent’s context is an instruction channel: retrieved documents, fetched web pages, email bodies, ticket comments, code comments, calendar invitations, and — most easily missed — the output of one tool becoming the input to the next.
The review enumerates those channels, checks whether untrusted content is delimited and marked as data when it enters the context, and then asks the question that decides the impact: if the agent obeys, what is it permitted to do? Retrieval-side hardening is covered in RAG and vector store security; the enforcement point for both is the environment design in secure AI environment establishment.
Memory and context poisoning
Agents that keep memory across turns, sessions or users carry an injection that persists. A single poisoned interaction writes a durable instruction into summaries, scratchpads, long-term memory stores or shared workspace state, and every later run reads it as established fact.
What we look at: what is written to memory and on whose say-so; whether memory is scoped per user or shared; whether anything written by the model is later read as instruction rather than as data; retention and expiry; and whether there is any way to inspect or clear what an agent currently believes. That last one is a support requirement as much as a security control.
MCP server trust and tool-description provenance
MCP is a protocol for connecting a model to tools and data through servers that describe what they offer. It changes the risk because the tool description is itself model-read content: adding a server extends what the agent can do, on the authority of whoever wrote that description. A tool description is not documentation in this setting. It is text the model reads in order to decide what to do, which makes whoever controls it a participant in your agent’s decisions.
So the questions are supply-chain questions: which servers are connected and who publishes each; whether a server can change its tool descriptions after approval, and whether anything notices; what the server can reach in your environment; whether a developer can add one without review; and whether the transport is authenticated and the server’s identity verified rather than assumed from a hostname.
Blast radius and where checkpoints belong
The destructive-action review is a list, built with you, of everything the agent can do that is hard to undo: money moved, records deleted, messages sent outside the organization, permissions granted, production configuration changed, customers contacted. For each, the review records what reverses it, how long that takes, and who finds out.
An agent can be made safe without a human in the loop for actions that are reversible, bounded and cheap to get wrong. Checkpoints are for the rest, and the design question is which category each action is in rather than how much oversight feels right. A checkpoint on every action trains people to approve without reading, which is worse than no checkpoint because it launders the decision. The design puts them where the action is irreversible, where it crosses an organizational boundary, where it exceeds a threshold, or where it is being taken on the authority of content the agent read rather than a person asked.
The coding agent in your pipeline belongs in exactly this model and is usually the most privileged member of it: see AI-generated code security review.
What you receive
- An agent inventory with reachable systems, borrowed authority, triggers and owner for each agent.
- A permission review against least privilege, with the specific grants to narrow and the credentials to split.
- Boundary test results, with reproduction steps for anything that crossed a boundary it should not have.
- Recommended checkpoints, placed against the destructive-action list rather than applied uniformly.
Both, and in that order: the permission model and the blast-radius review are advisory work on the design, while the boundary testing that follows exercises a running system and is performed only with signed authorization. Where an agent has already done something nobody can explain, the reconstruction depends on telemetry that had to exist beforehand — see AI incident readiness and LLM application penetration testing for the bounded adversarial engagement against the whole application.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
Testing and adversary simulation are carried out only with signed authorization, to a scope agreed in writing.
Investigation and forensic work is delivered with appropriately licensed partners where the law requires it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
What is MCP and why does it change the risk?
MCP is a protocol for connecting a model to tools and data through servers that describe what they offer. It changes the risk because the tool description is itself model-read content: adding a server extends what the agent can do, on the authority of whoever wrote that description.
Can an agent be made safe without a human in the loop?
An agent can be made safe without a human in the loop for actions that are reversible, bounded and cheap to get wrong. Checkpoints are for the rest, and the design question is which category each action is in rather than how much oversight feels right.
Do you test the agent or review its design?
Both, and in that order: the permission model and the blast-radius review are advisory work on the design, while the boundary testing that follows exercises a running system and is performed only with signed authorization.
We only use vendor-built agents — does this apply?
Vendor-built agents shift who writes the code, not who carries the risk. You still choose the connectors, grant the credentials and own the actions taken under them, and those are the parts this work examines.
List the agents, then narrow them
Describe what your agents can call, whose credentials they use and what they can do without approval. The reply says what a review would cover and which parts would need authorization to test.