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
Approval targets and execution-time authorization
Implement permission checks at the tool execution boundary, bind approval to immutable parameters and resource versions, and reject prompt injection to expand authorization.
Knowledge content check2026-10-03 · Check the source of the original question2026-10-02
It is recommended to understand first:
Tool calls: structure, authorization, and business contracts →Idempotency, unknown outcomes, and task recovery →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.
Realize again
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 →Will troubleshoot
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 →Able to choose
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 · Approval targets and execution-time authorization
Understand the core principles first
Preparatory concepts:Business authorization, immutable version, Parameter normalization
Approval must point to certain action semantics and content, and execution must satisfy current permissions. Authentication, model recommendations, and historical approvals do not automatically prove that the action can be performed on the resource at this moment.
Approve a specific immutable proposal
Authorization binds a subject, resource, and action; agents also generate parameters. “Agree to execute” loses meaning if recipients or amounts later change. Validate syntax and business meaning first. Show and approve the same immutable proposal, including tool version, normalized parameters, target, and resource version.
A hash does not grant authority
A digest detects changes without proving approver authority or continued authorization. The gateway checks identity, approved scope, expiry, and resource state. Changed content requires renewed review. Cross-service races need version conditions or capability constraints at the final business service; one earlier check is not permanently sufficient.
Define business meaning before canonicalization
Use integer minor currency units or explicit decimal strings, resolve defaults before hashing, and use consistent normalization across clients. JCS can support serialization but does not define rounding or default policies. The proposal is engineering guidance, not a tested complete approval system.
Check understanding with a question
Agent can call the writing tool. How to prevent parameters from being modified after exceeding authority and approval?
Models propose actions; trusted executors decide whether they may run. Validate session identity, tenant, resources, and parameters. High-risk writes require an immutable proposal approved by digest, resource version, expiry, and approver. Recheck before execution and review changed proposals again. Tool text, OAuth, prompts, and model judgments cannot replace business authorization.
Realization and trade-offs
Check permissions on executor
The tool schema only constrains the parameter structure. When actually executing the write, the actor_id and tenant_id are obtained from the trusted login session, and the model does not accept the tenant specified by itself. The executor verifies permissions by action, resource, and field, then reads the target using a tenant-limited query; searches and retrievals must also apply the same scope. Low-risk reads can be executed directly, and publishing, deletion, and funding actions are subject to approval according to business policies. Authorization failure should clearly return a handleable error and cannot be bypassed by automatically changing tools. The list of tools can be narrowed down by identity, but the actuators still need to be checked again.
Bind approval to a specific proposal
First persist the action_id, normalized parameters, parameter summary, resource version, proposer and validity period, and then the approval page displays the actual changes that will occur. The approval record binds this proposal and the executor reads the original approved parameters and does not use the values later regenerated by the model. Before execution, re-check the current permissions, proposal status and resource version, and use transaction or conditional update protection version judgment; if the parameters or goals change, a new proposal will be generated. Manual approval does not provide idempotency for external writes, but also requires stable business idempotency keys and queryable results.
Protocol authorization is not equal to business authorization
MCP's Authorization requires the server to verify whether the token is issued to itself. Its Security Best Practices explains the risk of token passthrough; tokens sent to other resources cannot be received as they are and then transferred to the downstream. Even if OAuth passes, the server still needs to determine whether the user can edit this article or this account. Third-party web pages, documents, and tool responses can contain malicious instructions, which are only data to be processed and do not obtain new permissions.
Use recovery and attack scenario acceptance
When using LangGraph, interrupt can pause and save the state, and the node will be re-executed when resumed. Therefore, the pre-approval logic is designed to have no side effects and cannot be written first and then wait for approval. Acceptance covers cross-tenant resource numbers, forged administrator parameters, expired approval, modified parameters after approval, and repeated click execution. Add an additional search text that requires uploading the key and check that the executor can reject it. The audit saves the judgment basis, proposal summary and execution results to avoid writing the key ontology into the audit. The safety trade-off is to keep ordinary reads smooth while giving verifiable proposals for actions with real consequences.
Engineering deduction
- scene
- Assume an engineering scenario: Content Agent generates an article and requests publication, and the reviewer modifies the target article while waiting.
- design decisions
- Publish approval binds the article content summary with the current version, and uses version condition checking before execution.
- Verify target
- The expected behavior is that the old approval cannot cover the new article and will be re-examined; this is a design acceptance condition and does not claim to have been launched for online experiments.
- applicable boundary
- Approval can only prove that specific actions are authorized, but cannot guarantee that the article is factually accurate, and content quality still needs to be verified.
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 1If resource permissions are revoked after approval, how should the executor handle it?
There is time between approval and execution, so current permissions may change.
Reference answer
Stop execution and log the reason for revocation. Approval does not replace current authorization; re-verify subjects, targets and actions, and re-apply for permissions and approval if necessary. If permission checking is separated from target writing, target conditional updates or short-term restricted credentials should also be used to constrain the race condition and clarify the acceptable propagation window.
Level 1How are floating point numbers, key ordering and default values handled when parameter normalization?
Summary comparisons rely on unique representations of parameters and must account for business normalization.
Reference answer
Ambiguous input is parsed and rejected first, and then the business representation is fixed: amounts avoid floating point rounding, default values are expanded when proposals are generated, and unknown fields are rejected according to rules. The object keys are consistent and standardized, the array order is maintained according to the business, and the algorithm and tool versions are saved; the same specification proposal is used for approval, display and execution.
Follow this answer further
Level 2The default recipient was changed by tool upgrade. The original parameter does not have this field. Can the old approval continue to be used?
The parent fixed specification means that the child allows unexplicit fields to change after version upgrades.
Reference answer
Cannot continue directly. The default value belongs to the actual action semantics, which should be explicitly expanded and bound to the tool version in the old proposal; if the old semantics cannot be restored, re-propose and approve it. Comparing only explicit user input misses changes in default behavior.
Follow this answer further
Level 3The canonical digest is the same, but the execution target is swapped out by DNS or a redirect, will the approval still be valid?
The parent question examines the default semantics and continues to examine the actual execution target beyond the parameters.
Reference answer
A digest only binds the object it contains. The gateway also needs to verify the actual target identity, allowed addresses and redirection policies, and use controlled connections and target service authorization for sensitive actions. The same URL string cannot be used as the same server; refuse to send when the target cannot be confirmed and record the reason.
Level 1When the external service does not support idempotency keys, how to decide whether to retry after timeout?
Secure writing also involves unknown execution consequences after approval.
Reference answer
First save the business ID and query the target receipt. If it is executed, fill in the local status. If it is not executed, we will discuss retrying. If duplicates cannot be removed and cannot be verified, the request remains unknown and transferred to manual processing. New requests cannot be made due to timeout. Whether to allow repeated effects must be decided by the business, not guessed by the model.
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.
Change from sending a draft letter to sending a formal letter
Changing conditions:Actions change from local mutable artifacts to external propagation.
Extended question:Can the original "approval report" cover the issuance of the letter?
Derivation and reference solutions
Cannot be overwritten automatically. New proposals need to list the recipients, content version, attachments, and purpose of sending. The scope of approval must clearly include sending the letter, and then perform verification of current permissions and goals. Draft approval only indicates that the content stage is approved; outsourcing is an independent action.
The principles that remain unchanged:The approval scope must be consistent with the real action semantics.
Waiting for several days for approval
Changing conditions:Permissions, order status, and tool versions may have changed.
Extended question:Is it enough to just check that the approval has not expired?
Derivation and reference solutions
Not enough. Check the resource version and business conditions, check the current permissions of the approver and executor, and regenerate and approve if necessary. Task recovery cannot bypass the final gateway; the longer the waiting time, the higher the probability of the old state becoming invalid, and the validity period and re-confirmation rules need to be clarified.
The principles that remain unchanged:The approval objects are fixed and the execution conditions are subject to the current facts.
Easy to make mistakes
- Just write "Don't exceed your authority" as permission control.
- The approval record only saves "agreement" and does not bind actual parameters and resources.
- Tenant and resource-level authorization will be skipped after OAuth verification is passed.
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
- Permissions are independently verified before execution, and dangerous actions require approval.
- Intermediate and advanced signals
- Approve the binding identity, action summary, version and validity period.
- Senior Signal
- Covers parameter changes, undo, replay, race conditions and actual side effect verification.
Hands-on verificationComplete on demand · Suggestions15 minutes
Deducing how the execution gateway should handle changes to recipients after approval.
Expand acceptance requirements and checkpoints
- Old approvals cannot cover new recipients
- Server-side verification and trustworthy approval
- Repeated callbacks are not executed repeatedly
Key inspections
- User identity, tenant scope and resource permissions can be placed on the server side instead of relying on model parameters.
- Can handle parameter changes and resource changes between approval and execution.
- Understand the different boundaries of MCP authorization, business authorization and manual approval.