FACT COPY · EN
Fact copy: MCP security and governance
Authentication, authorization, privacy and governance for MCP systems.
Canonical source: https://travel-mcp.com/en/security-governance/
Factual summary
Authentication, authorization, privacy and governance for MCP systems.
Precise scope and non-goals
MCP security and governance must be understood as defence in depth across identity, authorization, user control, data minimization, transport, downstream policy and operations. MCP does not supply inventory, commercial rules, traveller consent, settlement logic or the truth of a booking. Those responsibilities remain with the application and its systems of record.
A useful architecture therefore starts with the user task and authoritative data path, not with a list of SDK features. The protocol contract is valuable only when it preserves the domain contract behind it.
Protocol behaviour and responsibility
A connection starts with initialization, protocol-version negotiation and capability negotiation. Optional features must be detected at runtime and recorded in a compatibility matrix; clients and servers cannot assume that every peer implements the same capability set.
Tool and resource schemas validate structure, not business truth. The server still enforces authorization, object ownership, tenant boundaries, freshness and downstream preconditions. Results remain untrusted input to the host and model.
Travel architecture example
A concrete application is separating search, hold, booking, ticketing, payment, exchange and refund into distinct risk and authorization classes. Every result should preserve source, retrieval time, currency and material conditions; a time-limited offer must not be presented as confirmed inventory.
Binding operations require a fresh state check, explicit presentation of the material change, an approval bound to those exact parameters and idempotent execution. PNR, ticket, EMD, order and itinerary are not interchangeable records.
Failure modes and security boundary
The principal failure modes are prompt injection, tool poisoning, token theft, SSRF, session hijacking, excessive scopes and cross-booking access. These are architecture defects, not problems that can be delegated to prompt wording or model judgement.
Controls belong at independently enforceable boundaries: the host limits exposure and obtains approval, the MCP server validates the request and identity, and the downstream system rechecks domain rights and state. Each layer must fail closed for operations it cannot establish safely.
Evidence for production use
Production readiness requires threat models, negative authorization cases, audience validation, incident reconstruction, recovery drills and governance ownership. A successful demonstration proves only that one path worked once; it does not establish compatibility, security, recovery or domain correctness.
Evaluation should separate model-selection errors, client policy failures, MCP server failures and supplier-system conflicts. Measures include task correctness, inappropriate calls, user corrections, stale-state rejection, latency, cost per successful outcome and recovery time.
Authorization from token to travel object
A valid access token is not sufficient permission to read, modify or cancel a particular booking. The resource server validates signature, issuer, expiry and audience, then applies tenant, role, market, delegated relationship, object ownership and current domain state. Agency staff, end travellers, operators and suppliers require different delegation paths; a shared technical account must not erase the acting principal.
Scopes should follow domain impact. A broad booking.write scope can be too coarse when cancellation, exchange, name correction and ancillary purchase have different consequences and approval rules. The MCP server must not pass arbitrary downstream tokens through. It uses defined delegation or minimal service credentials and records the resulting decision without storing tokens or unnecessary personal content.
Control matrix for travel capabilities
Search capabilities require minimised inputs, provenance, freshness and bounded fan-out. Repricing requires an authoritative source, expiry and a machine-readable difference. Order creation adds exact-term approval, object authorization, idempotency and reconciliation. Payment and refund add stronger roles, amount and currency invariants, tokenised payment references, fraud controls and financial audit.
Controls must be independently enforceable. The host filters exposed capabilities and obtains informed user approval; the MCP server validates identity, schema and object rights; the supplier system rechecks commercial rules. A model instruction or annotation cannot override any of these boundaries. Tool and resource output remains untrusted content even when it came from a registered server.
Governance as measurable operation
Every capability has an owner, purpose, data classification, risk level, supported clients, service objective, negative tests, deprecation path and kill switch. Release review tests understandable descriptions, inappropriate model selection, cross-object access, stale state, result limits and recovery after dependency failure. Unused scopes and misleading capabilities are removed rather than retained indefinitely.
Incident evidence connects host choice, client request, server authorization and supplier outcome through a correlation identifier. Telemetry separates denied rights, malformed input, domain conflict and system fault. Retention and access differ for security events, booking history and model evaluation. Governance is effective only when a single dangerous capability can be suspended without disabling all read-only domain access.