Emerging technology
Organizations are deploying agentic systems faster than they are securing them. We work on the gap, including the MCP layer almost nobody is testing yet.
AI systems break the assumptions most security programs are built on. The trust boundary between instructions and data collapses. Behavior is probabilistic rather than deterministic, so the same input does not reliably produce the same output. And an agent with tool access can take real actions in real systems on the basis of text it read somewhere.
None of that means AI should not be deployed. It means the controls around it have to account for how it actually fails, and most existing security programs have no coverage for any of it.
What we do
Design and review of systems where an AI model takes actions rather than only producing text: multi-agent orchestration, tool design, and process automation. The critical questions are what the agent can reach, what it can do without a human confirming, and what happens when it acts on instructions embedded in content it retrieved. That last one is the failure mode with the widest blast radius and the least existing tooling.
Model Context Protocol servers are becoming the standard way enterprises expose internal tools to AI systems, and they are a new trust boundary that most security programs have no coverage for. We design and review MCP deployments: which tools get exposed, what scopes they carry, how server responses are validated before an agent acts on them, and how a compromised or malicious server is contained.
Adversarial testing of deployed AI systems: prompt injection through both direct and indirect channels, jailbreaks that defeat safety training, extraction of system instructions and training data, and manipulation of tool-using agents into acting against their operator. Extends to MCP endpoints, where a single poisoned tool description can redirect an agent.
See also: Red teaming
Designing the boundaries around AI systems: where models sit relative to sensitive data, how retrieval sources are validated, where human approval is required, what an agent is permitted to reach, and how actions are logged well enough to reconstruct afterwards what a system did and why.
Testing the infrastructure and interfaces around models, not only their outputs: inference endpoints, model storage and loading paths, the training and fine-tuning pipeline, and the supply chain of weights and datasets pulled in from third parties.
The policy and process layer: inventory of where AI is used, risk classification, acceptable use, human oversight requirements, vendor assessment, auditability, and the documentation you will need when a customer questionnaire or a regulator asks how AI is governed. Increasingly the thing blocking enterprise deals.
Vendor evaluation, rollout risk, and the part most organizations discover late: how an AI deployment interacts with obligations you already carry. An agent with access to a CUI enclave is inside your assessment scope, and a tool that ships prompts to a third-party endpoint may have moved data somewhere your SSP does not describe.
See also: CMMC Readiness
Guidance for organizations building their own models or fine-tuning existing ones, with security engineering present in the pipeline from the start rather than reviewed at the end. Advisory rather than development. We work alongside your data science team, not in place of it.
Process
Establish where AI is actually in use. This is almost always broader than leadership believes, because adoption happens team by team.
Separate low-consequence uses from systems that touch sensitive data or take consequential action. Effort belongs in the second category.
Work out how each system fails adversarially, including the failure modes specific to AI that conventional threat models do not cover.
Adversarial testing against the deployed system rather than the model in isolation, because the vulnerabilities usually live in the integration.
Put policy, oversight, and documentation in place so AI use remains defensible as it scales beyond the pilot.
Deliverables
Every engagement produces documentation you can hand to an auditor, a customer, or your own board without translating it first.
FAQ
The Model Context Protocol is becoming the standard way enterprises expose internal tools and data to AI agents. That makes it a new trust boundary carrying real capability, and one that most security programmes have not assessed because it did not exist when they were designed.
An agent with tool access can take real actions in real systems on the basis of text it read somewhere. The MCP layer is where that access is granted.
No, and it is the common case. Adoption almost always happens team by team before anyone governs it, so the first useful step is establishing where AI is actually in use. That is nearly always broader than leadership believes.
It can produce documentation you can put in front of a CMMC assessor or a customer security review, which is usually what is being asked for. What it cannot do is substitute for the underlying controls.
If AI systems touch regulated data, the framework obligations that already apply to that data still apply.
Most organizations are. We can start with the one system that worries you most.