Agentic AI Security
Security architecture and adversarial testing for AI agents with real access to real systems.
An agent that can only answer questions is a chatbot. An agent that can call your CRM, move money, open a ticket, or run a query against production is something else entirely, and most of the security thinking around it has not caught up.
The uncomfortable part is that the model does not need to be compromised for things to go wrong. It just needs to be convinced. An instruction buried in a document it reads, a support ticket it processes, a webpage it browses, and suddenly the agent is doing something on the attacker's behalf using credentials you gave it.
Direct injection is a user typing something adversarial. That is the easy case. Indirect injection is the one that catches teams: instructions hidden in content the agent consumes. A resume with white text telling the screening agent to recommend the candidate. A support email with a line addressed to the agent rather than the human. There is no reliable way to make a model ignore this, so the defense has to sit around the model, not inside it.
Almost every agent we review has more access than its job requires. It was easier to hand over a broad API key during the prototype and nobody went back. The blast radius of a successful injection is exactly the set of tools the agent can reach, so this is usually the highest-value thing to fix first.
Reading data and changing data deserve different treatment. Teams often wire both through the same path because the framework made it easy. If an agent can issue a refund, delete a record, or send an external email without a human in the loop, that needs to be a decision someone made deliberately, not an accident of implementation.
When one agent hands work to another, does the second one treat that input as trusted? Usually yes, and usually nobody decided that. Injection that lands in a low-privilege agent can propagate to a higher-privilege one through the handoff.
After something goes wrong, the question is always: what did it do, why, and with whose permission. If your logs capture the final output but not the reasoning steps and tool calls, you cannot answer that. Build this before you need it.
Engagements usually run three to five weeks and follow the same shape.
We start by mapping the actual architecture: every agent, every tool it can reach, every data source it consumes, and every trust boundary between them. This step alone surfaces problems in most environments, because the diagram in someone's head is rarely the diagram in production.
Then we test it adversarially. Direct and indirect injection, tool misuse, attempts to escalate through agent handoffs, and data exfiltration through outputs. We are not running a scanner against it; we are trying to make it do things it should not.
From there we design the controls: least-privilege tool scoping, human-in-the-loop gates on the actions that warrant them, input and output validation, sandboxed execution where code runs, rate and spend limits, and logging that captures the decision path rather than just the result.
Where you use Model Context Protocol, we review the server configuration and permission model specifically. MCP makes tool integration easy, which also makes over-permissioning easy.
Finally we hand over documentation your security team, your auditors, and your customers' security reviewers can actually use, and we map it to the governance framework in our AI governance practice so it holds up under formal review.
Companies putting agents into production where they touch real systems or real customers. If your agent only summarizes documents in a sandbox, you probably do not need us yet. If it can act on your behalf, or if a customer or auditor has started asking how you secure it, that is the moment.
Get in touch and we will tell you honestly whether this is worth doing at your stage.
Outcomes
Every agent, tool, data source, and trust boundary documented. Most teams find something they did not know was connected.
Tool permissions scoped to the job, with gates on consequential actions, so a successful injection does not become an incident.
Documentation that answers the security questionnaire, the auditor, and the board without a scramble.
Questions
It overlaps but is not the same. A traditional pen test targets infrastructure and application flaws. This targets the agent layer: how it can be manipulated through the content it reads, what it can reach when manipulated, and whether anything stops it. We often run both.
No, and be skeptical of anyone who says otherwise. There is no reliable way to make a model perfectly distinguish instructions from data. The practical approach is to assume injection will sometimes succeed and limit what an agent can do when it does.
The model provider secures the model. You are responsible for what you connect it to, what permissions you grant, and what happens when it is manipulated. That layer is where nearly every real incident occurs.
Three to five weeks for most environments, depending on how many agents and integrations are in scope. We can scope a narrower review of a single agent in about two weeks.
Both. Some clients want findings and take remediation in-house. Others want us to design and implement the controls. We are happy either way and will say plainly which parts you can handle yourself.
An architecture map, a findings report with severity and reproduction steps, a prioritized remediation plan, and control designs you can implement. If you need it for a customer security review or audit, we write it so it holds up.
Ready when you are
Book a no-obligation consultation and we'll map the fastest path forward.