MCP and AI Agent Tool Security

An MCP deployment has four reviewable components: the client that hosts the agent, the server that exposes capabilities, the transport between them, and the credentials the server uses to reach downstream systems. Each has distinct failure modes, and reviewing only the server is a common mistake that leaves token handling and transport unexamined.

Tools are the highest-risk primitive because they cause action. Each tool has a name, a description, a parameter schema and behaviour. All four can be abused: names can shadow legitimate tools, descriptions can carry instructions, schemas can accept more than intended, and behaviour can change after approval.

Resources and prompts are lower risk but not benign. Resources feed content into context, which is an injection channel, and prompts are reusable templates that can be poisoned to bias subsequent interactions. Both should be reviewed and, where possible, restricted to trusted servers.

Credentials define blast radius. An MCP server typically holds a token to a downstream system; if that token is service-wide, every user of the agent inherits its authority. The single most important architectural decision in MCP deployment is whether servers act with their own identity or with a delegated per-user token.

Transport matters for trust. Local stdio servers run with the privileges of the client process, which can be the developer machine; remote servers cross a network boundary and require authentication, TLS and request integrity. Mixing the two without understanding the difference is how local servers end up exposed.

Clients place tool descriptions into the model context so the model can choose tools. A malicious server can therefore write text that reads as instructions: telling the model to prefer this tool, to pass certain values, or to avoid mentioning the action. The model has no reliable way to distinguish descriptive metadata from guidance it should follow.

Tool shadowing exploits trust in names. A malicious server can register a tool with the same or similar name as a legitimate one, and if the client resolves names loosely, the agent may invoke the impostor. Defence requires fully qualified tool identifiers, collision detection at registration and explicit user-visible indication of which server a tool belongs to.

Rug pulls exploit approval fatigue. A server is reviewed and approved with benign behaviour, then an update changes a tool to do something else. Without version pinning and re-review on change, the approval becomes stale while appearing valid. Treat tool definitions as code: hash them, pin versions and require re-approval for changes.

Continuous verification is the practical answer. On every client start, compute a hash of the tool inventory and compare to the approved baseline; alert on additions, removals and description changes. This single control catches shadowing, rug pulls and accidental configuration drift in one mechanism.

Finally, do not display raw tool descriptions to end users as authoritative. Present a curated label and description maintained by your own team, so a hostile server cannot shape what the user believes the tool does.

Every tool call needs two identities: the agent that executed it and the human on whose behalf it ran. Without both, audit records say the assistant did something, which fails investigation and fails regulatory expectations for accountability. Implement on-behalf-of tokens that carry both identities and expire quickly.

Authorisation should be enforced per tool, not per server. A server exposing read and write tools should be mounted with only the read tool available in contexts that do not need write. Policy engines that evaluate tool name, arguments, principal and context give you this without rewriting servers.

Approval gates must sit in the client or an intermediary the model cannot bypass. The human sees the exact tool, arguments and destination, and approval is bound to that specific invocation, not to a general permission. One approval must never authorise a later, different action.

Sandboxing limits the consequence of a compromised server. Run untrusted servers in containers with restricted filesystem and network access, no ambient credentials and explicit egress rules. A server that can only reach its intended API cannot pivot to the wider network.

Audit records should capture principal, agent, server, tool, argument hash, decision, approval identity and result. Retain according to policy and make them queryable, because the first question in any incident will be what the agent did and for whom.

MCP and AI Agent Tool Security is best defended by understanding exactly how it fails. The attacks below are not theoretical constructs: each has been demonstrated against production systems, and each leaves a detection signal that a mature team can instrument. For every technique, the security question is not only "can it happen" but "what is the cheapest observable evidence that it is happening now".

Tool description injection. A malicious or compromised server embeds instructions in tool descriptions or parameter hints that the client passes into the model context. The observable signal is: Tool inventory hashes changed; descriptions containing imperative language or references to other tools. The primary countermeasure is: Treat metadata as untrusted, curate user-facing descriptions internally and diff the tool inventory against an approved baseline.

Tool shadowing and name collision. A server registers a tool with the same or similar name as a legitimate tool, so loose resolution invokes the impostor. The observable signal is: Duplicate or near-duplicate tool names across servers; calls routed to an unexpected server. The primary countermeasure is: Fully qualified identifiers, registration-time collision detection and server attribution in the UI.

Rug pull behaviour change. An approved server updates to perform a different action while keeping the same tool name, invalidating the original review. The observable signal is: Version change without re-approval; behavioural difference on a canary invocation. The primary countermeasure is: Version pinning, signature verification and mandatory re-approval with canary testing on update.

Confused deputy across users. A server holds a broad service credential, so an action requested by one user is executed with authority that extends to other users data. The observable signal is: Actions on records outside the requesting user scope; identical service identity across many users in audit logs. The primary countermeasure is: Delegated per-user tokens, per-tool scope evaluation and argument validation against the principal entitlements.

Output injection from tool results. A tool returns content that contains instructions, which the agent treats as guidance for its next action. The observable signal is: Unexpected subsequent tool calls after a specific tool result; instructions referenced in reasoning. The primary countermeasure is: Label tool output as data, summarise into typed structures and restrict available tools after untrusted results.

Credential and secret exposure. Tokens are passed in tool arguments, logged in traces or readable by the model, allowing theft through injection or misconfiguration. The observable signal is: Secrets appearing in prompts, logs or trace payloads; unusual authentication from unexpected sources. The primary countermeasure is: Broker credentials at execution time, never place them in prompts or logs, and rotate on suspicion.

Malicious server supply chain. An unvetted server package contains backdoor behaviour, excessive permissions or dependency compromise. The observable signal is: Unverified package signatures, excessive permission requests, unexpected network destinations. The primary countermeasure is: Approved catalogue, signature verification, sandboxing with egress allowlists and dependency review.

Because AI attacks rarely arrive one at a time, threat models must describe chains rather than isolated techniques. A reconnaissance step (enumerating endpoints and model behaviour) enables an initial access attempt (a crafted input or poisoned artefact), which enables privilege escalation through excessive agency, which enables impact such as data exfiltration or a fraudulent transaction. Teams that model the chain, and place a control at each link, degrade an adversary's success probability far more effectively than hardening a single step.

Detection design should assume partial failure. Every control in this course is evaluated on the assumption that some percentage of attempts bypass it, which is why least privilege, approval gates, egress restriction and immutable audit trails appear repeatedly. The goal of an AI security programme is not a system that cannot be attacked; it is a system where a successful attack is bounded, observed, attributed and recoverable.

A defensible mcp and ai agent tool security posture layers preventive, detective and corrective controls so that no single component carries the entire trust burden. In practice this means securing four planes: the model and artefact plane (weights, adapters, prompts, versions), the data plane (training data, retrieval corpora, logs), the control plane (identity, policy, configuration, secrets) and the action plane (tools, APIs, outbound integrations). Attacks cross planes, so controls must be designed at the crossing points.

Approved server catalogue. A curated list of vetted MCP servers with pinned versions, owners and documented capabilities; unapproved servers cannot be installed. This control maps to ISO/IEC 27001 A.8.19 · NIST AI RMF GOVERN 5 and should be evidenced rather than merely asserted: policy document, configuration export, test result and monitoring screenshot constitute the minimum acceptable evidence set during an audit.

Tool inventory hashing. Compute and compare a hash of all tool definitions at startup against an approved baseline, alerting on any change. This control maps to OWASP LLM01 · ISO/IEC 27001 A.8.32 and should be evidenced rather than merely asserted: policy document, configuration export, test result and monitoring screenshot constitute the minimum acceptable evidence set during an audit.

Delegated per-user tokens. Servers act with short-lived tokens representing both the agent and the end user, never with broad standing service credentials. This control maps to NIST AI RMF MAP 4 · OWASP LLM08 and should be evidenced rather than merely asserted: policy document, configuration export, test result and monitoring screenshot constitute the minimum acceptable evidence set during an audit.

Per-tool policy enforcement. A policy decision point evaluating tool name, arguments, principal and context before execution, independent of the model. This control maps to ISO/IEC 27001 A.5.15 · NIST AI 600-1 and should be evidenced rather than merely asserted: policy document, configuration export, test result and monitoring screenshot constitute the minimum acceptable evidence set during an audit.

Invocation-bound approval. Human confirmation tied to a specific tool call with exact arguments and destination, enforced outside the model. This control maps to EU AI Act Art.14 · ISO/IEC 42001 A.9 and should be evidenced rather than merely asserted: policy document, configuration export, test result and monitoring screenshot constitute the minimum acceptable evidence set during an audit.

Server sandboxing and egress control. Untrusted servers run in restricted containers with no ambient credentials and network access limited to allowlisted destinations. This control maps to ISO/IEC 27001 A.8.20 · NIST AI RMF MANAGE 2 and should be evidenced rather than merely asserted: policy document, configuration export, test result and monitoring screenshot constitute the minimum acceptable evidence set during an audit.

Dual-identity audit trail. Immutable logs recording principal, agent, server, tool, argument hash, approval identity and outcome for every action. This control maps to EU AI Act Art.12 · ISO/IEC 42001 A.8 and should be evidenced rather than merely asserted: policy document, configuration export, test result and monitoring screenshot constitute the minimum acceptable evidence set during an audit.

Reference architectures should make the secure path the default path. Wrap model access behind an internal gateway that enforces authentication, quota, policy evaluation and logging; make the raw provider endpoint unreachable from application subnets; issue short-lived scoped credentials from a secret manager rather than embedding keys; and separate the orchestrator's identity from the tool's identity so that authorisation can be evaluated per hop. When the platform enforces these properties, individual teams cannot accidentally ship an unprotected integration.

Standards anchor the architecture in language regulators and auditors accept. Model Context Protocol specification, OWASP LLM08 Excessive Agency and LLM01 Prompt Injection, ISO/IEC 27001 supplier and access control clauses, NIST AI RMF MANAGE and GOVERN provide the vocabulary of governance, risk and assurance. Map each control to at least one standard clause and to one internal policy. Where a standard is silent on an AI-specific issue, record that gap explicitly — auditors increasingly reward documented reasoning over false completeness.

Finally, defence in depth must survive component failure. Define what happens when the guardrail service is unavailable, when the policy engine times out, when the model provider degrades, and when an on-call engineer is the only responder at 03:00. Fail-closed on high-impact actions (payments, deletions, external communications, privilege changes) and fail-open only where the risk of blocking exceeds the risk of allowing, with an explicit record of that decision.

Security claims about mcp and ai agent tool security decay quickly. Models are retrained, prompts change, connectors are added and providers ship silent updates. Assurance therefore has to be continuous, measured and tied to thresholds that trigger action. A control without a metric is an intention; a metric without a threshold is a dashboard nobody acts on.

Servers outside the approved catalogue. Target: 0 in production. An unvetted server with filesystem or network access bypasses every other control. Instrument this metric at the platform layer so it is computed identically across teams, and review it on a fixed cadence with named owners rather than in ad hoc reviews.

Tool inventory drift events. Target: all investigated within 24 hours. Metadata changes are the primary shadowing and rug pull signal. Instrument this metric at the platform layer so it is computed identically across teams, and review it on a fixed cadence with named owners rather than in ad hoc reviews.

Actions with delegated identity. Target: 100% of user-initiated tool calls. Service-identity actions cannot be attributed and over-privilege the agent. Instrument this metric at the platform layer so it is computed identically across teams, and review it on a fixed cadence with named owners rather than in ad hoc reviews.

Irreversible actions without approval. Target: 0. The clearest measure of whether containment is real rather than documented. Instrument this metric at the platform layer so it is computed identically across teams, and review it on a fixed cadence with named owners rather than in ad hoc reviews.

Mean time to revoke a server. Target: < 15 minutes. Supply chain compromise requires fast removal of a live capability. Instrument this metric at the platform layer so it is computed identically across teams, and review it on a fixed cadence with named owners rather than in ad hoc reviews.

Testing should combine four modes. Static review validates configuration, model format, dependency provenance and policy definitions before deployment. Automated adversarial suites replay a maintained corpus of known attacks on every release to catch regressions. Manual red-team exercises explore reasoning failures, multi-turn escalation and cross-component chains that automation misses. Finally, production monitoring measures real behaviour — refusal rates, extraction attempt volumes, tool-call anomalies and cost per user — because production traffic is the only place where the true attack distribution is visible.

Lab — Inventory and hash a tool catalogue. Objective: Detect a shadowed tool automatically. Register two servers with similar tool names, compute the inventory hash and build a diff that flags the collision and description change. Each lab is assessed on evidence produced, not on the answer reached: test transcripts, metrics before and after, and a written residual-risk statement are the deliverables.

Lab — Exploit and fix a confused deputy. Objective: Demonstrate over-privileged service credentials, then delegate. Show a user retrieving records outside their scope through a service token, then implement per-user delegated tokens and re-test. Each lab is assessed on evidence produced, not on the answer reached: test transcripts, metrics before and after, and a written residual-risk statement are the deliverables.

Lab — Sandbox an untrusted server. Objective: Constrain a server to a single destination. Run the server in a restricted container with no ambient credentials and an egress allowlist, then verify blocked network access appears in logs. Each lab is assessed on evidence produced, not on the answer reached: test transcripts, metrics before and after, and a written residual-risk statement are the deliverables.

Reporting is part of assurance. A finding that cannot be understood by a risk committee will not be funded, and a control that cannot be explained to an auditor will not be trusted. Write findings in business language first — what an attacker gains, which data or operations are affected, how many users or records, what the detection time would be — and only then in technical detail. Attach reproduction steps, but never attach live credentials, personal data or restricted content to a report; use redacted transcripts.

Implementing mcp and ai agent tool security in a large organisation is an operating-model problem as much as a technical one. Three roles must be explicit: an accountable owner for the AI system (usually the business product owner), a control owner for each security capability (platform security, identity, data protection, SOC), and an assurance function that independently verifies claims. Where these roles are ambiguous, controls quietly rot after the launch milestone.

Start with an inventory. You cannot secure models, agents or datasets you have not catalogued, and most enterprises discover on their first red-team engagement that shadow AI usage exceeds sanctioned usage. Build an AI system register capturing purpose, data classification, model and provider, tools and integrations, human oversight model, risk tier and control status. Tie registration to procurement and to cloud project creation so new AI workloads cannot appear outside the register.

Define runbooks before incidents, not during them. At minimum: how to revoke a model or agent credential within minutes; how to disable a single tool or MCP server without taking the product down; how to roll back to a previous model and prompt bundle; how to isolate a poisoned index or dataset; and how to notify customers and regulators. Rehearse each runbook at least twice a year — including one exercise without the engineer who wrote it.

Tooling should reduce toil rather than add dashboards. MCP reference clients and SDKs, Policy engines (OPA, Cedar, gateway ext_authz), Container sandboxing (gVisor, Firecracker, rootless containers), Package signing and SBOM tooling, Agent observability and trace platforms each solve part of the problem, but integration matters more than breadth: policy decisions must reach the gateway, telemetry must reach the SIEM, and findings must reach the backlog engineers actually work from. A single well-integrated pipeline with clear ownership outperforms five disconnected best-of-breed tools.

Governance closes the loop. Report control coverage, open findings by severity, mean time to remediate, adversarial test pass rates and incidents to the AI risk committee quarterly, and to the board annually in business language. Where a residual risk is accepted — for example a model that cannot yet meet a robustness threshold — record the acceptance, the compensating controls, the owner and the expiry date. Time-bound acceptance is the difference between governance and wishful thinking.

Finally, embed security in delivery. Threat model each new AI feature at design time, add adversarial regression tests to the definition of done, require provenance checks in the deployment pipeline, and give engineers a paved road — approved model gateways, SDKs with guardrails built in, and pre-cleared tool integrations — so the secure path is also the fastest path.

Enterprise agent platform (Financial services). The problem: An agent connecting to CRM through MCP used a service account, so users could retrieve records outside their entitlements. The response: Replaced the service credential with delegated per-user tokens and enforced per-tool policy on record identifiers. The outcome: Actions became attributable and scoped to user entitlements, closing a confused deputy exposure The transferable lesson: The confused deputy is the default outcome of service credentials in agent platforms For teams working on mcp and ai agent tool security, the pattern to copy is the sequence — measure the exposure first, fix the highest-leverage control, then prove the improvement with the same measurement.

SaaS vendor with published MCP endpoint (Technology). The problem: Tool descriptions were passed verbatim to clients, allowing a compromised description to influence assistant behaviour across customers. The response: Sanitised metadata, published a stable tool schema contract and added signing so clients could verify definitions. The outcome: Customers could pin and verify tool definitions, making silent behaviour change detectable The transferable lesson: Vendors that expose tools take on responsibility for metadata integrity, not just API correctness For teams working on mcp and ai agent tool security, the pattern to copy is the sequence — measure the exposure first, fix the highest-leverage control, then prove the improvement with the same measurement.