Understand first
New to this knowledge point
Complete the prerequisite concepts, read the principles and counterexamples, and then explain why in your own words.
Start with core principles →Knowledge catalogChoose core direction and segmented content
Understand → Implement → Debug → Design
Protocol and trust boundaries in MCP integration
Distinguish between protocol interoperability, OAuth authorization, business permissions, and tool risk tips.
Knowledge content check2026-10-03 · Check the source of the original question2026-10-02
It is recommended to understand first:
Context and generation budgets →Which step do you want to learn from this knowledge point?
Select the starting point based on the current basis, or you can go deeper one by one. When you encounter an unfamiliar concept, go back to the core principles first; use the knowledge exercises to check your understanding when you are finished.
Implement next
Prepare to write the principles into code
Understand implementation steps and boundaries, complete small tasks, and check results against acceptance requirements.
Reading implementation and trade-offs →Debug failures
Need to handle failures and changes in conditions
Follow the continuous questioning to locate the failure premise, and then compare the migration cases to explain how the plan should be adjusted.
Continue to delve deeper into the problem →Compare designs
Need to design or review plans
Combine engineering deductions and senior self-evaluation standards to explain the applicable conditions, costs and alternatives of the plan.
Analyze engineering scenarios →Knowledge unit directory
LEARN · PRACTICE · REFLECT
Knowledge learning and personal records
First read along the principles, Q&A and migration cases. When you need to check your understanding, switch to reinforcement exercises or start personal recording.
Answers and personal notes
Can be practiced directly. After logging in, answers, favorites, and notes will be saved to your account.
Log in and saveEach modified commit will be kept as an independent history. Your level of mastery is up to you to evaluate yourself against the standards.
Core concept · Protocol and trust boundaries in MCP integration
Understand the core principles first
Preparatory concepts:OAuth resource server, tool gateway, least privilege
Protocol interoperability proves that the message can be understood, but does not prove that the server is trustworthy or that the action is approved. Tool metadata, input identities, and return text all require their own sources of trust; tokens must be used by the correct resources and cannot rely on proxy forwarding to diffuse permissions downstream.
Discovery is only the first step
A discovered tool is a server’s capability claim. The host checks server identity, user scope, tool contracts, and risk; execution checks actual resources. Exposing tools and expecting model compliance cannot replace backend authorization.
Annotations are hints
readOnlyHint describes behavior without proving it. Reviewed trusted-server annotations may inform policy; untrusted read-only claims still require checks. Reads can disclose sensitive data. “Approved” in a tool result is data and cannot change a trusted approval record.
Bind HTTP tokens to their audience
If service A accepts a token issued for B, credentials cross service boundaries. Under the pinned MCP 2025-11-25 revision, clients include resource identifiers and resource servers validate tokens intended for themselves. Downstream APIs need their own audience-bound tokens. Match protocol revisions to deployments; stdio credential handling does not define HTTP authorization.
Check understanding with a question
Does connecting to MCP complete production-grade tool integration? Where are the boundaries of trust?
MCP standardizes discovery and calls while applications retain business authorization, idempotency, rate limits, and audits. Hosts control available servers and tools; executors validate parameters and resources. Untrusted read-only or idempotency annotations cannot authorize actions. HTTP tokens must target and be validated by the resource server. Downstream calls use separate audience-bound credentials rather than forwarding inbound tokens.
Implementation and trade-offs
Separate protocol and application responsibilities
MCP defines discovery, calls, inputs, results, and errors. Applications still need server allowlists, version management, timeouts, concurrency quotas, redacted logs, and resource authorization. Narrow tools by identity and task, then validate execution server-side. A tool hidden from the model remains reachable outside that context.
Treat untrusted annotations as claims
Read-only, destructive, and idempotency hints are not proofs. Hosts use policy, reviewed server identity, and risk to decide approval. Unfamiliar servers cannot gain production access by asserting readOnlyHint. Descriptions and results remain data. Validate structured outputs, bound size, authorize links, and keep credentials outside model context.
Prevent confused-deputy HTTP authorization
Under the pinned MCP 2025-11-25 specification, clients use resource parameters and servers verify tokens intended for themselves. Signature validation without audience checks can accept another service’s token. Use separate downstream credentials rather than passing inbound tokens through. Map OAuth scopes to actual actions and resources; successful login does not authorize every document.
Validate integration boundaries
Test wrong audiences, expired tokens, unauthorized resources, forged read-only hints, oversized results, and timeouts, expecting controlled rejection with redacted audits. Add duplicate write requests and unknown outcomes. Pin the revision actually deployed; this example does not assert one revision applies universally. Successful connection begins integration, while counterexamples establish its limits.
Engineering deduction
- scene
- Hypothetical engineering scenario: The enterprise provides document query and work order modification as two MCP tools to the R&D Agent.
- design decisions
- Only necessary tools are exposed according to tasks; query and modification use different action permissions; the server verifies the audience, tenant and work order ownership.
- Verify target
- Expected behavior: Read-only tasks cannot modify tickets; tokens issued by another service are rejected; downstream credentials do not enter the model.
- applicable boundary
- The MCP specification does not replace the enterprise permissions model; security configuration for stdio local deployment and HTTP authorization cannot be confused.
Continuous questions and answers
Continue reading along with the premises and constraints of the problem. Understand the reference answers first, then try to put away the answers and explain the cause and effect and trade-offs in your own words.
Level 1Can read-only tool annotations be used as a basis for exemption from approval?
Protocol metadata requires trust and cannot replace specific action judgments.
Reference answer
Can be used as a policy input from a trusted, audited server and cannot be independently determined to be exempt from approval. The host determines based on actual side effects, data sensitivity and user authorization; annotations from untrusted sources are processed as untrusted data. Although the salary query is read-only, there is still a risk of leakage. If the tool marked as read-only actually sends a message, it needs to be rejected or re-examined.
Follow this answer further
Level 2The server was originally trusted, but after the upgrade, the tool is still marked as read-only but has a new export function. What should I do?
Trust changes from version to version, and static whitelisting cannot prove that new behaviors are still safe.
Reference answer
Tool description, Schema and implementation version are included in release review, and changes trigger contract regression and strategy recalculation. Execute gateway restrictions on allowed operations and destinations, and monitor for unusual side effects; upgrades cannot automatically inherit old approvals. The directory display is a reminder, and the release basis is stored in the controlled policy.
Follow this answer further
Level 3Schema has not changed, but the server implementation has been secretly changed. Can the client completely prevent it?
Contract inspection has observation boundaries, and permission restrictions need to be used to reduce the risk of unobservability.
Reference answer
Internal behavior cannot be verified by protocols alone. Reduce server permissions, use restricted credentials and isolated environments, require trusted publishing channels and auditing; clients can inspect visible results and request scopes, but cannot prove that there are no hidden side effects on the remote end. Servers that cannot be trusted are not granted high-impact capabilities, illustrating this practical limitation.
Level 1Why might a valid OAuth token still be rejected?
The authenticity of the credentials and the scope of application of the credentials are different judgments.
Reference answer
Valid may simply mean that the format and signature are correct. Also check whether it has expired, whether the target audience is this service, whether the scope allows the action, and whether the user has specific resource permissions. Resource access is still denied when the token is authenticated but does not have order reading rights; a wrong audience is an authentication boundary failure and cannot be ignored for the convenience of integration.
Level 1How do MCP services handle credentials when accessing downstream APIs?
Cross-service proxies must avoid mistaking upstream permissions for downstream authorizations.
Reference answer
The MCP service acts as a downstream API client, using restricted credentials specifically issued to the downstream and mapping permissions to the current principal and purpose. The inbound token is not transparently transmitted as it is and is not put into the model context; necessary delegation is implemented through a controlled authorization mechanism. Save the redacted calling identity and resource scope, and the OAuth scope cannot be automatically expanded to downstream administrator rights.
Draw inferences from one example: If the conditions change, how to deduce it?
First find out the conditions for change, and then determine which premises in the original plan still hold true. The following cases are teaching deductions to facilitate the transfer of principles to new problems.
local stdio service
Changing conditions:HTTP network authorization becomes the host startup process
Extended question:Is there no security perimeter without OAuth?
Derivation and reference solutions
Executable program sources, environmental credentials, file scopes, and tool actions still need to be restricted. stdio can obtain credentials from the environment but should not inherit unnecessary administrator keys; the host starts controlled processes and distinguishes logs from protocol channels. The HTTP token specification does not apply directly, least privilege and input authorization still apply.
The principles that remain unchanged:If the transmission method changes identity access, business permissions and credential scope still need to be controlled.
Public read-only data service
Changing conditions:Private writing tool becomes public query
Extended question:Is it possible to skip all production checks?
Derivation and reference solutions
You can not require private resource authorization, but still check parameters, resource consumption, result size, server identity and untrusted content. The public data may be contaminated, and the tool text still cannot give new instructions to the Agent; rate limiting and timeout protect the host. What is relaxed is the public data access rules, not all enforcement boundaries.
The principles that remain unchanged:Interoperability and readability do not equal arbitrary input, unlimited resources, or trusted instructions.
Easy to make mistakes
- It is considered that the successful MCP connection means the completion of business authorization
- Only the token signature is verified, not its target audience
- Treat the content returned by the tool as a new system command or approval certificate
References
It is designed based on public technical information; the reference materials support the technical mechanism, and the scenarios and scoring standards are designed by this website and do not represent the original interview questions of a certain company. New Q&A and migration cases are added for principle explanation, and source verification and case operation verification are recorded separately.
Check how far you understand
After reading, you can explain the principles, boundaries, and trade-offs against these standards. It is up to you to evaluate your mastery; if further verification is needed, complete the small tasks below.
- Basic standards met
- Know that MCP resolves protocol interoperability and does not directly provide full business control.
- Intermediate and advanced signals
- Distinguish the responsibilities and identities, authorization and receipt of Host, Client and Server.
- Senior criteria
- Covers external tool declarations as untrustworthy, protocol version and supply chain change verification.
Continue to do advanced research experiments
Push the read-only tool boundary to the approval boundary
First observe whether business effects have been generated while waiting for approval, and then press README to check action binding and recovery.
Read full text and fault analysis → · Download Reliability Experiment v3 ↓
python3 approval_cli.py submit
python3 approval_cli.py run
python3 approval_cli.py inspect
# 审查 draft 和 action_json 后，按 README 使用对应 binding_hash 批准并恢复Keep evidence and check item by item
- Status waiting_approval, no reports service has written yet.
- Review actions, targets, scopes, inputs, and content summaries before approving the corresponding binding_hash.
- Run tests to reject, cancel and modify content respectively to explain why old approvals cannot be reused.
Local approval fixture; --actor is not a login or production authentication. No network by default.
Hands-on verificationComplete on demand · Suggestions15 minutes
Draw the trust boundaries of the model for querying and modifying work orders through MCP.
Expand acceptance requirements and checkpoints
- Separate agreements and business permissions
- Writers have policy controls
- Server-side errors can be traced
Key inspections
- Explain the responsibilities of the host, client, and server
- Ability to identify differences between tool annotations and mandatory policies
- Explain the reasons for audience verification and disabling token passthrough