← AI Agent Security Engineering: Prompt Injection, Identity, MCP, and Tool ControlsSkip to lesson ↓

Module 2: Bind Identity, Tools, and Data

Secure MCP and Other Tool Connections End to End

Review the full connection from tool discovery and authorization to argument validation, target policy, evidence, and server trust.

Approx. 4 min reading · Includes diagrams; allow extra time for reflection and linked resources.

Start reading ↓
About this learning content and editorial review
About this learning content: Courses, lessons, assessments, explanations and illustrations may be created with the help of artificial intelligence. We review and check the material and do our best to avoid incorrect or outdated information, but mistakes, omissions or ambiguous questions may remain. Please verify information before relying on it for professional, security, legal or operational decisions. Read the full notice or report an issue.

Your focus

What you’ll learn

  • Review an MCP connection as a chain of independently trusted components and decisions.
  • Explain why token, schema, argument, destination, and target-side validation remain necessary.

Applies the course’s authority model to Model Context Protocol and comparable integrations without assuming that protocol compliance makes a tool safe.

A protocol connection introduces another trust relationship

The team places the refund and messaging capabilities behind an MCP server. MCP standardizes how an AI application discovers and invokes tools and accesses resources. It does not certify that a server is trustworthy, that a tool is necessary, or that an operation matches the user’s task. Those remain application and organizational decisions.

Inventory the host, client, server, authorization server, tool implementation, dependencies, and downstream services. Verify ownership, distribution, version, update path, declared capabilities, and data destinations. A server can change its tool descriptions or implementation after approval; pin or govern versions where the environment requires stability and review material changes before expanding production access.

Tool descriptions are both interface metadata and model-visible content. Treat them as untrusted when they come from an external server. A description that tells the model to ignore policy or request unrelated data is not granted authority because it arrived through a protocol. Keep trusted policy outside server-controlled text.

Host, client, authorization service, MCP server, tool, and target each own a different verification decision.
Security decisions exist at every MCP hop — Host, client, authorization service, MCP server, tool, and target each own a different verification decision.

Authorization must bind the token to the intended service

Protect sensitive tools with authorization enforced at the transport boundary. Validate the issuer, audience, expiry, scopes, client, and subject according to the applicable profile. Do not accept a token merely because its signature is valid; a valid token issued for another resource can still be the wrong credential. The 2026 MCP specification continues to harden authorization, including defenses against authorization-server mix-up, so implementations should follow the current specification rather than copied early examples.

Keep the confused-deputy problem visible. An MCP server may possess authority to a downstream service that the caller does not. It must not turn any authenticated request into use of that broader authority. Evaluate the caller, delegated task, requested tool, target object, and tenant. Avoid token passthrough patterns that blur which service is responsible for authorization.

Separate public and protected capabilities deliberately. A harmless catalog tool and a refund tool do not need identical access. Per-tool authorization can reduce exposure, but it also increases the importance of correctly classifying each operation and preventing a supposedly public tool from reaching protected data through its arguments.

Issuer, audience, subject, scope, task, and target must converge before the protected tool accepts the call.
A valid token still needs the right binding — Issuer, audience, subject, scope, task, and target must converge before the protected tool accepts the call.

Validate the operation all the way to the target

Tool schemas improve structure, not trust. Validate required fields, types, ranges, encodings, destinations, resource ownership, and cross-field relationships. Normalize before comparing. A destination allowlist can fail if alternate URL forms, redirects, aliases, or downstream forwarding are ignored. Never pass model output directly into shell commands, queries, templates, or file paths without the ordinary defenses those sinks require.

Log the requested tool and safe argument representation, authorization result, confirmation state, server and tool version, downstream target, and outcome. Use the site’s AI Tool-Call and MCP Telemetry Requirements as the deeper evidence reference. The MCP server should return bounded results and avoid placing secrets or unnecessary personal data back into model context.

At this point the support agent’s tools are identifiable, authorized, constrained, and observable. The remaining exposure is the material those tools retrieve and remember.

Resources