Five checks every organisation should run on MCP-enabled agents, and how to prove they pass

The Model Context Protocol (MCP) has become the standard way to connect AI models to tools, data sources and other systems. It is what turns a chatbot into an agent that can read your files, query your databases, send messages and take actions in production systems. Adoption is fast because it is easy. That is also the problem.
An MCP agent behaves like a new employee with system access, except that it works at machine speed, follows instructions found in whatever content it reads, and is usually deployed without the onboarding, permissions review and supervision a human would receive. The Cloud Security Alliance (CSA) is currently drafting a framework, the Six Pillars of MCP Security, that describes what good practice looks like. It is a useful document. It does not tell any organisation whether its own agents pass.
This paper translates the emerging standard into five plain-language checks that a business leader can ask of their technology team, sets out what a good answer looks like for each, and explains how T3 tests them against a live deployment so the answer is evidence rather than assurance.
The question is not whether your agents are secure in principle. It is whether you can show a regulator, a board or a customer that they are secure in practice.

THE FIVE CHECKS

1. Do you know who is responsible?
2. Does the agent know who it is working for, and how far it can go?
3. Can it be tricked?
4. Can you trust the tools it uses?
5. Can you see what it is doing, and stop it fast?

Why this matters now

Three things have changed in the last twelve months.

• Agents are cheap to build. MCP servers for common enterprise systems (email, file storage, CRM, ticketing, code repositories, payment platforms) are freely available and take minutes to install. Many are written by individuals and published to open registries with no review.
• The blast radius has grown. The CSA draft describes the shift from “model risk” to “executable influence”. A prompt no longer produces text for a human to read; it produces actions in systems of record.
• Regulators expect evidence. The EU AI Act obligations for high-risk systems, ISO/IEC 42001 certification and sector supervisors all expect documented controls and evidence of testing. “We use a reputable model provider” is not a control.

The practical consequence is that the first serious agent incidents in regulated firms will not be caused by novel attacks. They will be caused by ordinary weaknesses: an agent with broader permissions than anyone intended, a tool that was never vetted, or a document containing hidden instructions that the agent obediently followed.

The five checks

Each check is written so that a non-technical leader can ask it, and a technical team can answer it with specifics. “What good looks like” draws directly on the CSA draft. “How T3 tests it” describes the evidence we produce.

Check 01: Do you know who is responsible?

Think of an MCP agent as a new member of staff who can use your systems on their own. Someone must own it, it must be on a register, and it must sit inside the security and risk programme you already run.

WHY IT MATTERS

Most organisations cannot list the MCP servers in use. Staff install them on laptops from public registries in minutes, and there is currently no reliable detection tooling for this. An agent nobody owns is a risk nobody manages.

WHAT GOOD LOOKS LIKE

• A complete inventory of MCP servers and clients, including ones installed by individuals
• A named business owner and a named technical owner for every agent
• Agents included in the scope of ISO 27001, SOC 2 or the CSA Cloud Controls Matrix, with the AI Control Matrix (AICM) extension applied
• A risk register entry covering the three harms the CSA identifies: attacks on outside systems, leakage of confidential content, and abuse of paid resources such as LLM token subscriptions
• Regulatory classification completed where the agent acts in a high-risk domain under the EU AI Act

HOW T3 TESTS IT

Discovery scan of endpoints, repositories and developer tooling for MCP configurations; reconciliation against the declared inventory; gap assessment against AICM and ISO/IEC 42001.

Check 02: Does the agent know who it is working for, and how far it can go?

Every session should be tied to a real identity, and permissions should say exactly what the agent may do, for how long and how much. When one agent hands work to another, each step must be checked, so a tool never ends up with more power than the person who started the chain.

WHY IT MATTERS

The most common MCP failures the CSA draft describes are overbroad scopes, missing object-level controls and the “confused deputy”, where a downstream tool runs with authority it was never meant to have. These are not exotic attacks. They are the default state of a quickly assembled agent.

WHAT GOOD LOOKS LIKE

• No anonymous or shared-credential MCP connections; every session is bound to a human or a registered non-human identity
• Permissions scoped per operation (read or write), with bounded parameters and time and volume limits
• Delegation between agents is explicitly authorised, attributable and logged at each hop
• Standing privileges removed for high-impact actions; access is granted just in time and expires automatically
• Autonomy tiers mapped to privilege tiers, with a defined process for promoting an agent and a deterministic way to revoke it

HOW T3 TESTS IT

Privilege escalation and confused-deputy testing across the delegation chain; token scope review; attempted actions outside declared scope, with results mapped to the client’s access control policy.

Check 03: Can it be tricked?

Agents read whatever comes back from documents, websites and tools, and can mistake that content for instructions. The question is whether your setup keeps untrusted content apart from commands, and whether a person has to approve anything destructive.

WHY IT MATTERS

The CSA threat list for MCP is long and specific: indirect prompt injection, tool poisoning, “rug-pull” schema changes after a tool has been approved, cross-server context contamination, session smuggling, sampling manipulation and gradual integrity drift. All of them exploit the same weakness: the agent cannot tell data from instructions unless the architecture forces the distinction.

WHAT GOOD LOOKS LIKE

• Untrusted content is isolated from instruction-bearing regions of the prompt, and resource links are never fetched automatically without a policy decision
• Tool definitions are allowlisted and schema-validated, and any change after discovery is detected and blocked
• Everything entering the context window is logged with its source, classification and any transformations applied
• A human must approve destructive or high-impact actions such as deletions, payments or transfers
• Monitoring distinguishes accidental drift from deliberate manipulation

HOW T3 TESTS IT

Adversarial red teaming of the live deployment against the full CSA threat list, using T3’s OWASP-aligned methodology; measured success rates per attack class; prioritised remediation register.

Check 04: Can you trust the tools it uses?

Third-party MCP servers are software from outside your company, often written by individuals and published to open registries. They should be treated with the same suspicion as any unvetted dependency, and checked to confirm they do what their description says.

WHY IT MATTERS

MCP extends your trust boundary to every server the agent talks to. The CSA draft calls for the same discipline used in software supply chain security (SLSA, NIST SSDF, SBOM) plus one extra dimension unique to agents: semantic trust, meaning the tool description the model reads must match the tool’s real behaviour.

WHAT GOOD LOOKS LIKE

• Third-party servers run in sandboxes (containers or WebAssembly) with restricted filesystem and network access
• An AI-BOM or SBOM exists for every MCP server, and only signed, verified versions are deployed
• Build pipelines use ephemeral runners, short-lived credentials, tamper-evident logs and approval gates
• Each tool is assessed on three dimensions: the artefact (code and dependencies), its execution behaviour, and its semantic honesty

HOW T3 TESTS IT

Dependency and artefact review; behavioural testing of each server in isolation; comparison of declared tool descriptions against observed behaviour.

Check 05: Can you see what it is doing, and stop it fast?

If something goes wrong, you need to know within minutes, reconstruct what happened, and switch the agent off in one action.

WHY IT MATTERS

Agent incidents are unlike traditional breaches. The damage is done by a legitimate identity using legitimate tools, so network and API logs alone will not show it. Visibility has to sit at the context layer, and revocation has to remove permissions and reachability at the same time.

WHAT GOOD LOOKS LIKE

• An MCP gateway in front of agent traffic providing inline visibility, PII redaction and dynamic policy enforcement on every call
• Audit-grade logs that allow a full reconstruction of any session
• A tested kill switch that collapses tool authorisation and network reachability together
• Incident response playbooks that name the agent owner and the decision rights for shutdown

HOW T3 TESTS IT

Tabletop and live incident simulation; measurement of time to detect and time to revoke; review of log completeness against the reconstruction standard.

A simple readiness scorecard

Ask your team to rate each check honestly. Anything at “Partial” or below for checks 02 and 03 means the agent should not yet hold write access to systems of record.

What the CSA draft does, and what it leaves to you

The Six Pillars draft is a well-structured description of the control environment an organisation should build around MCP. It maps to existing frameworks (ISO 27001, SOC 2, NIST CSF, CSA CCM and AICM), names the threat classes clearly, and sets out sensible architecture patterns including gateways, sandboxing and identity-bound sessions.

What it does not do, and what no standard can do, is tell you whether your deployment meets it. That gap is closed in only one way: by testing the real system against the real threats and recording the results in a form a regulator or auditor can read.

This is where policy meets engineering, and it is the work T3 exists to do.

How T3 helps

T3 is an award-winning AI assurance and governance partner for high-risk industries, trusted by two of the three largest technology companies in the world. We contribute to the standards this paper references, including the EU AI Act, ISO/IEC 42001, NIST AI RMF and the OWASP GenAI security guidance.

MCP AGENT ASSURANCE ENGAGEMENT

Where off-the-shelf GRC platforms stop, we build the custom controls, integrations and assurance that fit your stack, your models and your regulator.

Next step

If your organisation is deploying agents, or discovering that staff already have, a 45-minute structured conversation with T3 will establish where you sit on the scorecard above and what evidence you would need to produce if asked tomorrow. No obligation and no sales pitch.