Security and Trust in MCP

Goal

Secure an MCP integration by checking identity, limiting permission and data, and keeping protocol compatibility separate from trust.

Why should the calendar token stay local?

A student asks a school assistant, “What is on my calendar tomorrow?” The assistant discovers a new MCP endpoint and proposes sending it a token that can read, edit, and delete calendar events.

The endpoint may speak valid MCP. That is not enough. Is this an approved server? Is the current student allowed to access this calendar? Does the task need write permission? Which fields actually need to leave the host?

Until those checks pass, the host should not send the credential or the calendar data.

That crossing is a trust boundary. Data and authority are moving between systems that should not automatically trust each other. Protocol compatibility asks, “Can these systems communicate?” Security policy asks, “Should this endpoint receive this data or authority for this user and task?” Keep those questions separate.

The MCP 2026-07-28 release strengthened authorization rules, including issuer validation. In practice, identity or authorization metadata is useful only after it matches the identities and issuers your deployment expects.

Zero trust does not mean “never connect to anything.” It means network location or protocol compatibility alone is not enough. Check the endpoint identity, caller, requested resource, task context, and allowed permission each time access matters.

Narrow endpoints and credentials

An endpoint allowlist is one simple control. The host can keep a list of approved MCP servers instead of letting model output invent any destination. Discovery can still happen inside approved rules, but generated text should not decide where credentials are sent.

Keep credentials narrow. If a server only reads a calendar, do not give it a token that can delete every user's events. Short-lived or task-scoped credentials reduce damage if a credential leaks.

The host might keep a simplified local authorization record like this; it is not an MCP request schema:

{"endpoint":"approved-calendar","principal":"user-42","scope":["calendar.read"],"capability":"list_events"}

Use data minimization too: send only what the capability needs. If a tool needs an order ID, do not send the whole conversation or user profile.

Treat returned content as untrusted

Returned content is untrusted too. A tool result may contain text that tells the model to ignore local rules. Label the result as remote data, preserve where it came from, and never let embedded text become local policy.

Audit records should connect the endpoint, caller, capability, permission scope, policy decision, and result. You can keep useful security evidence without copying every sensitive payload.

Layer security controls

Security uses several layers: protocol validation, endpoint identity, caller identity, capability policy, argument limits, credential scope, and safe handling of returned data. Passing one layer does not skip the others.

For example, an approved calendar server can still receive an unsafe request. A valid endpoint identity answers which server this is; it does not prove that the current user may edit every calendar. The host should separately check the caller, requested action, target calendar, credential scope, and fields being sent. Trust is therefore a chain of checks, not one successful connection test.

Predict

A model proposes connecting to a new MCP URL and sending a broad access token. What should the host do?

Require the endpoint and credential scope to pass configured trust and authorization policy before any connectionConnect once because protocol compatibility can be verified after credentials are sentLet the remote server decide whether the token scope is excessive

Run the local Lab

Run:

python3 labs/notebooks/level-13/l13-06-mcp-trust.py

The Lab evaluates endpoint identity, role, scopes, and data fields in a fixed trust-check order.

1. Run it unchanged and confirm every check is ok and the request ends with trusted: True.
2. In request, find "endpoint": "https://mcp.example.internal". Before editing, predict which check should fail first if only the endpoint becomes unapproved.
3. Change only that request value to "https://unapproved.example", then rerun.
4. Confirm endpoint approved fails first and the script exits before later capability/scope checks can make the endpoint trusted. Restore the starter afterward.

Loading lab…

Quick Check

1. What does zero-trust reasoning add to an MCP integration?

Treat every remote endpoint as hostile and never connectVerify identity and authorization for each accessReplace protocol validation with a single network firewall rule

2. Why minimize data sent to a tool?

Because shorter requests run fasterBecause extra fields increase privacy riskBecause MCP forbids structured arguments with more than one field

3. How should tool-returned instructions be treated?

As higher priority than the user request because the tool is specializedAs local security policy because they came through a valid MCP responseAs remote data that cannot override local policy

0 of 3 questions answered.

Explain it back

Design a trust policy for a calendar MCP server. Include endpoint identity, credential scope, allowed tools, data minimization, and how returned text is labeled.

Key Takeaways

• Protocol compatibility does not establish endpoint trust.
• Validate identity and authorization at each access boundary.
• Use narrow credentials and approved endpoints.
• Send only the data the capability needs.
• Treat returned content as remote data, not local policy.

Next Lesson

You have reached the checkpoint. After reviewing the MCP trust boundary, continue to L13.7 — Agent-to-Agent Communication Concepts.

References

• Model Context Protocol, 2026-07-28 Specification.
• Model Context Protocol, 2026-07-28 Specification Release.
• NIST, SP 800-207 — Zero Trust Architecture.