MCP Security Interview: Authorize at Execution Time

An approval can be valid when issued and unsafe when executed. The MCP security guidance covers consent, token handling, and scope minimization. Our interview exercise extends those concerns to a queued export whose permissions change before execution; it is a design exercise, not a claim that every MCP server has this workflow.

Map capability before adding controls

Inventory what the agent can read, write, execute, and send. Separate instructions from capabilities, and name the identity under which each action runs. This map tells you where least privilege and approval gates belong.

Treat prompt injection as an authority problem

A retrieved document can contain instructions, but it should not outrank the system policy or user approval. Explain how you label untrusted content, constrain tool arguments, and stop when the request crosses a permission boundary.

Make actions observable and reversible

Log the tool, actor, target, arguments, approval, and result. Keep destructive actions behind a bounded approval or a reversible transaction. A governance answer without a rollback story is incomplete.

Exercise: an approved export waits in a queue

A fictional agent asks to export a project report. The user approves one project and one destination. Before the worker executes, the user loses access to the project, or the agent changes the destination to another service. A stored “approved” flag does not explain whether the original permission still applies.

Separate three questions. Who is the caller? What is that identity allowed to do now? Did the user approve this concrete action? Authentication, authorization, and task approval overlap in a workflow but are not substitutes for one another.

Bind the decision to the actual action

An approval record should identify the operation, resource, destination, and relevant content or version. A material change requires another decision. Do not assume the model’s summary is an accurate representation of the tool arguments; the enforcement layer should compare the executed action with the approved action.

The worker also needs an authoritative permission check at the side-effect boundary. A check performed only when the task was queued leaves a gap. Where the storage service cannot make the check and write atomic, discuss that race explicitly, shorten the interval, and use the resource service’s supported authorization guarantees. Do not promise instantaneous revocation if credentials remain valid until expiry.

Five tests that make the design concrete

Test normal execution, access removed after approval, destination changed, approval expired, and replay of the same action. The expected outcome differs by case: a revoked action is denied; a changed action needs fresh approval; a repeated successful export should not silently create another disclosure.

Include the denial path in audit evidence. Record an actor identifier, the checked resource, a reason, and a correlation identifier. Keep tokens and exported document contents out of ordinary logs. If the audit sink is unavailable, decide which high-impact actions must wait and describe how operators see the backlog.

A useful spoken answer is: “Approval authorizes a specific proposed action. At execution I still check current access and that the destination matches. If either changed, I stop rather than reuse the old decision.” Then explain the limitation: once data reaches an external recipient, deleting the local export does not retrieve every copy.

This is where a rollback answer needs precision. Cancelling a queued job can prevent disclosure; deleting a file after delivery is a mitigation with limits. Naming that difference is stronger than promising that every agent action is reversible.

What the 2026 MCP changes mean for interview answers

The MCP 2026-07-28 release candidate highlights authorization hardening, Tasks, and a more operational protocol core. The practical interview lesson is simple: a protocol feature does not replace application-level authorization. You still need to bind the caller, tool, resource, destination, and time of execution.

Ask five questions before approving a tool:

Who is the caller at execution time?
Which resource and fields can the tool access?
What exact action did the user approve?
Has the approval expired or been revoked?
What evidence proves the decision and result?

This is more precise than saying an MCP server is “trusted” or “untrusted.”

Treat approval as a scoped fact, not a permanent flag

Store the approved action, target, actor, policy version, expiry, and a request identifier. At execution, re-check current authorization and compare the requested arguments with the approved ones. A changed destination, broader resource, or expired task needs a new decision.

Apply the same rule to retrieved instructions. A document can suggest an action, but it cannot elevate its own authority. Separate untrusted content from policy and enforce the boundary in the tool implementation and execution environment.

Practice the denial path

Build five cases: normal execution, access removed after approval, destination changed, approval expired, and a replay of a successful export. For each case, state the expected result and the audit receipt. A queued job can be cancelled before delivery; after an external transfer, local deletion is only a limited mitigation.

A concise answer is: “Approval authorizes one concrete action. I re-check current access and argument equality at execution. If either changed, I stop and request fresh approval.” Add what you log and what you intentionally keep out of logs.