AI Security Projects: MCP, Prompt Injection and Agentic AI - Practitioner Q&A

This FAQ answers the technical questions UK security and GRC teams ask before commissioning an AI Security Project: how to secure a Model Context Protocol server, what prompt injection testing actually involves, where the new risks in agentic AI sit and what audit-ready evidence a project produces. It is written for CISOs, security architects and compliance leads in regulated sectors who already know they have an AI attack surface and want to know how the controls get deployed and evidenced.

How do you secure an MCP server?

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 and monitor its activity and test it for tool poisoning and prompt injection before and after deployment. One over-permissioned server can give an agent a path across your whole estate.

Most teams underestimate the broker problem. An MCP server sits between the language model and the tools it can call: databases, ticketing systems, file stores, internal APIs. If that server holds broad credentials and trusts whatever the agent asks it to do, a single manipulated instruction can reach far beyond the conversation that triggered it. MCP server security work maps every tool the server exposes, removes the access it does not need, puts an authorisation check on each call and instruments the whole thing so you can see what the agent did and why. We deliver this as a scoped engagement that ends with the controls in place and the evidence to show they hold.

What is prompt injection testing?

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, which auditors and boards increasingly expect for deployed AI systems.

The difference between a guardrail you hope works and one you can prove works is a test record. Prompt injection sits at the top of the OWASP LLM risk list because it is the most direct way to make a model act against its operator. A tester builds inputs that hide instructions inside documents, exploit the boundary between system and user prompts or chain through retrieved content to reach a tool the model should not have called. Each attempt is logged with the input, the system response and a pass or fail against the expected behaviour. That record is what turns a vague assurance into something an AI penetration testing report can stand behind, and what gives a board a dated, repeatable measure rather than a vendor’s promise.

What are the security risks of agentic AI?

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, not only at launch.

A chatbot answers and stops. An agent decides, acts, reads the result and decides again. That loop is the source of the new risk. Because the agent operates with whatever credentials its runtime grants it, a manipulated step can use those credentials to reach systems the original task never needed. The agent can also write to memory or external stores, which means an attack can persist across sessions rather than ending when the conversation closes. And because the data leaves through channels the system is meant to use, classic exfiltration alerts often miss it. Securing long-running and agentic AI means treating the runtime, the credentials, the memory and the tool access as one system and verifying its behaviour after deployment, not only signing it off at launch.

What is an AI Security Project and what does it deliver?

An AI Security Project is a scoped technical engagement that deploys and evidences controls on a specific AI system, rather than advising on what you should do. The output is a configured control set, a test record and audit-ready evidence, not a slide deck of recommendations.

The distinction matters because most AI security guidance stops at advice. OWASP tells you the risks. Vendors tell you their product helps. Neither configures your MCP server, runs the injection tests against your guardrails or hardens your agent runtime. An AI Security Project does the hands-on work: we scope the system, deploy the controls, test them and hand back the evidence. A typical engagement produces a control inventory, a least-privilege configuration, a dated test report mapped to the OWASP LLM Top 10 and a record that feeds straight into your ISO 42001 and EU AI Act obligations. We deliver this in regulated sectors where the evidence has to survive an auditor, which shapes how we document every step.

How does MCP server security relate to the OWASP LLM Top 10?

MCP server security addresses several entries in the OWASP LLM Top 10 at once, because the server is where many of those risks converge. Prompt injection, insecure tool use, excessive agency and sensitive information disclosure all land on the broker that connects the model to your systems.

The OWASP list is organised by risk category; an MCP server is a single component that touches most of them. When an injected instruction reaches a tool, that is prompt injection meeting insecure tool use. When the server holds more access than the task needs, that is excessive agency. When it can return data the caller should not see, that is sensitive information disclosure. Securing the server is therefore an efficient way to reduce exposure across multiple OWASP categories in one engagement. We map each control we deploy back to the relevant OWASP entries so the AI penetration testing record shows which risks the work addresses and to what standard, which is exactly what an auditor wants to trace.

Can prompt injection testing be automated?

Parts of prompt injection testing can be automated, but the highest-value findings come from manual, system-specific work. Automated suites run known injection patterns quickly and catch regressions; they do not understand your tool chain, your data flows or the specific ways an attacker would chain through your particular agent.

Automation is good for breadth and repeatability. A library of known payloads run on every deploy will catch the obvious failures and flag when a previously closed gap reopens. What it misses is the attack that depends on how your system is wired: the retrieved document that reaches a specific internal tool, the prompt boundary that only fails when a particular sequence of calls precedes it. Those need a tester who has read your architecture. We combine both. Automated runs give you continuous coverage and regression detection; targeted manual testing finds the chained, context-specific failures that matter most for a deployed system in a regulated environment. Both feed the same evidence record.

What controls stop an AI agent escalating privilege?

The controls that stop privilege escalation are least-privilege credentials per task, a brokered authorisation layer that checks every tool call against policy, isolation of the agent runtime from production secrets and continuous behaviour verification that flags actions outside the expected pattern.

Privilege escalation in agentic systems usually happens through inheritance: the agent acts with credentials broad enough to reach systems the current task does not require, and a manipulated step uses that headroom. The fix starts with scoping credentials to the task rather than the agent, so each action carries only the access it needs. A brokered authorisation layer then checks every tool call against an explicit policy, so even a credential the agent holds cannot be used for an action policy forbids. Isolating the runtime keeps production secrets out of reach of an agent that has been turned. And continuous AI behaviour verification watches what the agent actually does after launch, so an escalation attempt that slips past the static controls is caught in operation. We deploy and test all four as part of securing long-running and agentic AI.

How do you secure agent access to databases?

You secure agent access to databases by putting the agent behind a brokered, least-privilege interface rather than handing it direct credentials. Define the queries the agent may run, scope its access to the rows and tables the task needs, log every query and test the boundary against injection that tries to reach data outside scope.

The failure mode to avoid is the agent holding a database connection with broad read or write rights. A manipulated instruction can then read records the task never required or write data it should not. A brokered interface inverts this: the agent asks for an operation, the broker checks whether policy allows it and only approved, scoped queries reach the database. Logging every query gives you the record an auditor needs and the signal a monitor uses to spot anomalies. Testing the boundary with injection inputs that try to widen the agent’s reach proves the scope holds. This is part of the MCP server security pattern, where the server is the broker between the agent and your data stores.

Does AI penetration testing produce ISO 42001 evidence?

Yes. AI penetration testing produces dated, traceable evidence that supports several ISO 42001 controls, because the standard expects you to identify AI risks, deploy controls and demonstrate they work. A test report mapped to the OWASP LLM Top 10 is exactly the kind of operational evidence an ISO 42001 audit looks for.

ISO 42001 is a management system standard: it wants to see that you have identified the risks your AI systems carry and that the controls you claim are actually in place and effective. A penetration testing record satisfies the operational side of that. It shows which adversarial inputs were tried, whether the guardrails held and when the test was run, which evidences the control rather than asserting it. The same record supports EU AI Act obligations around robustness and risk management for higher-risk systems. We run our AI penetration testing with the audit in mind, documenting each finding so it slots into your management system rather than sitting in a separate report no auditor will read. Lead Auditor framing shapes how we structure that evidence.