AI Security Projects: Securing MCP Servers and Agentic AI in Regulated Sectors

Most security teams have mapped their model risk. Few have mapped the privileged broker sitting between their AI agents and their systems, and that gap is where the real exposure lives. As organisations move from chatbots to agents that take actions, the attack surface shifts from the model to the runtime around it: the Model Context Protocol servers, the tool integrations and the long-running processes that act on an agent’s behalf.

This is the discipline we call AI Security Projects. It covers scoped technical engagements that deploy and evidence controls rather than advise on them: MCP server security, prompt injection and LLM penetration testing, guardrail validation and agent runtime security. The distinction matters most in regulated sectors, where a board or auditor wants dated proof that a control resists adversarial input, not a slide deck explaining that it should.

This pillar sets out what each part of the work involves, why agentic systems create a new privileged-broker problem and how project work produces ISO 42001 and EU AI Act evidence.

Why AI Security Projects is a distinct discipline

AI Security Projects is hands-on technical delivery: we scope an engagement, deploy controls into your environment and produce evidence that they hold. It sits apart from advisory work, which recommends controls and from certification, which checks whether a management system exists on paper.

The difference is the deliverable. Advisory produces a recommendation. Certification produces a certificate against a standard. A project produces a configured, tested control and the record proving it works.

This matters because most public guidance stops at advice. The OWASP LLM Top 10 names the risks. Vendor documentation describes secure configuration in the abstract. Neither tests your MCP server, crafts a prompt injection against your deployed agent or confirms that your guardrails reject the input. That last mile, from generic guidance to verified control in your environment, is the work.

For a regulated organisation the gap is expensive. An NHS trust or local authority deploying an AI agent cannot satisfy an auditor with a policy that references good practice. It needs to show that the control was deployed, tested on a known date and found effective. Project work produces exactly that artefact, and it does so for the systems you actually run rather than a reference architecture. We deliver this as our own service, built to produce audit-ready evidence for organisations that answer to a regulator.

MCP server security: the privileged broker your CISO has not mapped

You secure a Model Context Protocol server by treating it as a privileged broker between AI agents and your systems. Scope its tool access to least privilege, authenticate and authorise every caller, isolate it from production credentials, log its activity and test it for tool poisoning and prompt injection before and after deployment.

The reason this needs its own discipline is that an MCP server occupies a position most threat models miss. It sits between an agent and the tools that agent can call: databases, ticketing systems, file stores, internal APIs. To be useful it holds the credentials and permissions to reach those systems. One over-permissioned server gives an agent a path across your whole estate.

That is the privileged-broker problem. A CISO who has mapped network segments, identity flows and data stores may not have a single box on the diagram for the MCP layer, because it is new and it does not look like traditional infrastructure. It is software that exposes tools to a non-human caller that can be manipulated through its inputs.

Securing it follows a recognisable shape, applied to an unfamiliar component:

• Least-privilege tool scoping. Each tool the server exposes gets only the access it needs. A read tool does not hold write credentials.
• Caller authentication and authorisation. Every request to the server is authenticated and checked against policy. The server does not trust an agent simply because it connected.
• Credential isolation. The server does not hold production credentials in a form an injected instruction can exfiltrate. Secrets are brokered, short-lived and scoped.
• Logging and monitoring. Tool calls are logged with enough context to reconstruct what an agent did and why. Anomalous call patterns are surfaced.
• Tool-poisoning and injection testing. Before and after deployment, the server is tested against inputs designed to make it call tools it should not or return data it should not.

The relationship to the OWASP LLM Top 10 is direct: prompt injection, insecure plugin or tool design and excessive agency all converge on the MCP layer. Naming the risks is the easy part. Configuring the server so the risks are closed, then proving it, is the project. For the deployment-side controls in detail, see our field checklist for securing agent data access.

Prompt injection and LLM penetration testing: evidencing that guardrails hold

Prompt injection testing crafts inputs that try to override an AI system’s instructions, exfiltrate data or trigger unintended tool calls, then records whether the guardrails hold. It maps to the OWASP LLM Top 10 and produces dated evidence that a control resists adversarial input.

This is where AI penetration testing diverges from the traditional kind. A conventional penetration test probes code, configuration and infrastructure for exploitable flaws. An LLM penetration test probes the model’s behaviour: it treats natural-language input as an attack vector and tries to make the system act against its own instructions.

The techniques are specific to the medium. A tester might embed a hidden instruction in a document the agent is asked to summarise, hoping the agent follows the instruction rather than summarising it. They might craft input that persuades the system to reveal its system prompt, ignore a content filter or call a tool with attacker-chosen parameters. Each attempt is recorded with the input used, the system’s response and a verdict on whether the guardrail held.

That record is the deliverable. A guardrail is only as good as the evidence that it resists attack, and ‘we configured a filter’ is not evidence. ‘On this date, we ran these forty injection attempts against the deployed system and recorded the outcome of each’ is.

The work maps cleanly onto the OWASP LLM Top 10, which gives regulated organisations a recognised frame. Prompt injection, sensitive information disclosure and excessive agency are named categories; testing against them produces evidence an auditor can place against a known taxonomy.

Some of this can be automated. Known injection patterns can be replayed at scale, and regression suites can re-run them after every change to confirm a fix has not regressed. The novel ones, the inputs specific to how your agent is wired to your tools, still need a tester who understands both the model and the system behind it.

Securing long-running and agentic AI: runtime, persistence and privilege

Agentic AI introduces risks beyond a single model. An agent that chains tool calls and acts on its own outputs can move laterally across systems, escalate privilege through inherited credentials, persist beyond a session and exfiltrate data through legitimate channels. Securing it means controlling the whole runtime and verifying behaviour continuously.

A single model call is bounded: input goes in, output comes out, the interaction ends. An agent is not bounded in the same way. It plans, calls a tool, reads the result, decides what to do next and calls another tool. That loop is the source of the new risk, because each step can compound the last.

Three runtime properties deserve specific attention.

Lateral movement. An agent with access to several tools can chain them. A read here, a write there and an action that neither tool’s owner anticipated becomes possible through the combination. The agent does not exploit a vulnerability in the traditional sense; it uses legitimate access in an unintended sequence.

Privilege escalation through inherited credentials. Agents often run with the permissions of the service account or the user who launched them. If those permissions are broad, the agent inherits them and an injected instruction can direct that inherited privilege at a target the human never intended to reach.

Persistence. A long-running agent does not necessarily reset between tasks. State, memory and context can carry forward, which means a manipulation introduced once can influence behaviour long after the input that caused it. Data exfiltrated through a legitimate channel can leave no obvious trace, because the channel was meant to be used.

Controlling this requires moving the security boundary out from the model to the runtime. Tool access is scoped per agent and per task. Credentials are short-lived and least-privilege. The agent’s actions are logged and monitored so anomalous sequences are caught, and behaviour is verified continuously rather than signed off once at launch.

How project work produces ISO 42001 and EU AI Act evidence

An AI Security Project produces audit-ready evidence as a primary output, not a by-product. Each engagement generates dated records of what was tested, how and with what result, mapped to the controls a regulated organisation must demonstrate.

ISO 42001 expects an organisation to manage AI risk through a defined system of controls and to show those controls operate. The EU AI Act, for higher-risk systems, expects risk management, logging and human oversight that can be evidenced. Both frameworks reward demonstrable control operation over documented intent.

Project work feeds this directly. An MCP server security engagement produces a record of least-privilege scoping, the authentication model and the injection test results. A prompt injection test produces a dated log of attempts and outcomes against the OWASP LLM Top 10. An agent runtime engagement produces evidence of credential scoping, monitoring and continuous verification. Each maps onto a control the frameworks expect to see.

As an ISO 42001 Lead Auditor practice, we structure engagements so the evidence lands in the form an assessment needs. The technical work and the audit trail are produced together, which means the organisation is not reconstructing evidence after the fact.

What clients ask us about AI Security Projects

Do we still need MCP server security if we use a managed AI platform?

Yes. A managed platform secures its own infrastructure, but the MCP servers and tool integrations that connect agents to your systems are usually yours to configure. The platform does not know which of your databases a tool should reach or what least privilege means for your estate. The privileged-broker risk lives in that configuration, and it remains your responsibility to scope, test and evidence.

How is AI penetration testing different from traditional penetration testing?

Traditional penetration testing probes code, configuration and infrastructure for exploitable flaws. AI penetration testing treats natural-language input as an attack vector and probes the model’s behaviour, crafting inputs that try to override instructions, exfiltrate data or trigger unintended tool calls. It maps to the OWASP LLM Top 10 rather than conventional vulnerability classes and produces evidence that guardrails resist adversarial input.

What deliverables does an AI Security Project produce?

A project produces configured controls and the evidence they work: least-privilege tool scoping, an authentication and credential model, dated prompt injection test results mapped to the OWASP LLM Top 10, runtime monitoring and continuous verification records. The evidence is structured to support ISO 42001 and EU AI Act assessment, so technical assurance and audit readiness arrive together rather than as separate efforts.

Map your attack surface, then deploy the controls

If your organisation is moving from AI pilots to agents that act on your systems, the privileged-broker layer needs mapping before something exploits it. Book an AI Security Projects scoping call to map your MCP, agent and LLM attack surface and deploy the controls, with audit-ready evidence produced alongside the work.