TL;DR: An MCP integration adds input, executable behavior and authority. Review which definitions reach the model, what the server process can access, and which identity authorizes each resource operation. Authentication and a reviewed tool list do not replace authorization of the requested action.
How to approach it
Ask whether the server runs locally or remotely, who operates it, and what the task actually needs. Identify private data and consequential operations before listing controls. For a protected HTTP service, draw the host-to-server and server-to-upstream credential hops; for a local server, draw its filesystem and network access.
A strong answer
Consider a hypothetical support assistant with a remote ticket server and a local documentation reader. The user wants a private ticket summary. It needs no message sending, ticket updates or arbitrary shell tool.
Host catalog
Before metadata reaches planning
- Expose only needed tools
- Hold unapproved definition revisions
Local launcher
Before the process starts
- Mount only required documentation
- Remove ambient credentials and sockets
Ticket service
Before data is returned
- Validate the caller and token recipient
- Check customer, ticket and operation
The ticket operator or an intruder in its service can supply misleading definitions and results. The host should inspect the metadata it exposes and hold changed revisions before use, including changes during a connection. The service holding the data must still enforce customer and ticket permissions. A digest proves that checked metadata matches a snapshot, not that remote behavior is unchanged.
The local documentation server is a program. Stdio provides messaging, not confinement. Run it with only the needed documentation mounted, no developer credentials or control sockets, and no network if the task does not require it. A read-only tool annotation is not a process restriction. Remote hosting moves the trust decision to another operator; it is not inherently the safer choice.
For the remote integration, accept a token intended for the MCP server and use a separately authorized credential for the ticket API. Preserve user and tenant restrictions on that second hop; a broad service account is not automatically least privilege. The MCP authorization specification, checked November 2026, makes authorization optional overall and defines its HTTP flow when supported. Do not claim that every remote server implements OAuth.
Check discovery at the network requester: metadata URLs and redirects must satisfy destination policy, including resolved addresses. Check resource access at the resource service: a valid audience or scope does not authorize another customer's ticket. If an MCP proxy obtains user grants for upstream services, review its per-client consent handling too. The protocol security guidance covers these separate boundaries.
In an authorized fixture, demonstrate rejection of a wrong-customer ticket read and confinement of the local reader. Record server identity, definition revision, policy decision and outcome, with sensitive evidence restricted. Do not log bearer tokens or full ticket bodies by default.
What interviewers probe next
- "The user already consented to the ticket API. Is that enough?" Establish which client and operations the consent covers; a previous grant to one client is not approval of another.
- "The server advertises read-only tools. Can it send data?" The executable may still make network requests, and the host can disclose data in read-request arguments.
- "All tool names are unique. Is shadowing prevented?" Names identify providers; they do not isolate influence in shared model context.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
The support assistant uses a vendor ticket server and a local documentation server. Your release review must identify where an unauthorized request is refused.
Start here
What if the ticket token is valid but the requested customer is wrong?
Does authentication prove object ownership?
Reject the read at the ticket boundary. Derive the caller's customer access from verified context and compare it with the requested object. A model-supplied customer field cannot grant access, even when the token is otherwise valid.
Carry it forwardValidate the resource relationship as well as the credential.
Weak answerTreating a valid token as permission for every ticket.
Constraint changes
What if the vendor forwards an upstream API token as MCP authentication?
Which service was that token issued for?
Require an MCP-server audience at the incoming boundary and a separately authorized upstream credential. Review the user's limits on both hops. Token passthrough loses that separation; replacing it with an unrestricted service token would create a different authorization problem.
Carry it forwardSeparate credential recipients without expanding authority.
Weak answerChecking only that two tokens have different values.
Constraint changes
What if approved metadata changes without a reconnect?
When does new text become available to the model?
Hold the new revision before exposure or use and suspend affected actions pending review. The check must cover list updates as well as initial discovery. If unapproved material already entered the session, reconstruct the task from reviewed inputs before consequential actions resume.
Carry it forwardEnforce approval throughout the definition lifecycle.
Weak answerComparing hashes only when opening a connection.
Now defend it
What evidence would justify permitting the integration?
A scoped capability inventory, verified credential recipients, refusal of cross-customer fixture reads, tested local confinement and enforcement of unapproved metadata changes. State which operations were checked and which remain outside the review; passing one path is not approval of every future tool.
How it's scored
This is our learning rubric, not an employer's hiring scorecard.
Weak: Lists incidents or says to use OAuth without identifying a resource or enforcement point.
Hire: Separates metadata influence, process access and authorization, with a concrete check for each.
Strong Hire: Preserves user constraints across credential hops, handles changes during a session, and gives evidence that could disprove the design.
Common mistakes
- Equating stdio with a sandbox or a remote deployment with safety.
- Treating namespacing or a definition hash as proof against cross-tool influence.
- Applying a token's audience check as a substitute for tenant authorization.
- Checking destination policy only after a discovery request has been sent.