Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D19 Cross-Service Agent Integration: Minting a User-Level JWT, JWKS Signature Verification, the inject/memory/usage Interfaces, Idempotent externalId

• For service-to-service calls, would you use a service token or a user token? When does each apply?两个服务之间调用，你会用服务级令牌还是用户级令牌？分别适用于什么场景？

  Common in ChinaCommon overseasIntermediate#auth#security#api-design

  How to reason about it · think before answering

  1. The hinge is each. Answering user tokens are safer turns a design question into a slogan — the interviewer wants the conditions under which each one is correct, and the concrete cost of choosing wrong.
  2. Give the deciding question first: is there a specific user behind this call? If yes, it must be a user token. If not — fetching config, reporting metrics, running a reconciliation batch — a service token is the right answer, and stuffing in a user id would fabricate audit history.
  3. Then state the three reasons as costs, not virtues. A leaked service token means every user's data at once; a leaked user token means one user, and it expires in fifteen minutes. Audit logs with a service token only show that some service called, never on whose behalf. And a downstream service doing per-user authorization is forced to trust a userId in the request body, which the caller writes freely.
  4. Add the production view: it is rarely either-or. Real systems use the service credential to obtain user tokens — the caller proves who it is once, then mints a short-lived token representing one user. The service credential then appears only at the minting step, never on every business call.
  5. Expect: what if a token leaks? Answer in two layers — a short lifetime (fifteen minutes here) does most of the containment, and a jti denylist is the supplement. Do not lead with a denylist: it puts a database lookup in front of every verification and gives away the whole point of stateless verification.
  6. Expect: how fine-grained should scopes be? Offer a usable rule — split along asymmetric risk. A bad read leaks information; a bad write poisons data that keeps influencing every later turn. So read and write always split; finer than that only if a real caller genuinely needs just one half.

  分析过程 · 先想清楚再作答

  1. 题眼在「分别」。答「用户级更安全」就把一道设计题做成了口号题——面试官想看你能不能说出两者各自成立的条件，以及选错的具体代价。
  2. 先给判断依据，一句话就能拆开：这次调用**有没有一个具体的用户在背后**。有，就必须是用户级；没有（拉配置、上报指标、跑对账批处理），服务级才是对的，硬塞一个用户 id 进去反而是伪造审计记录。
  3. 然后把用户级的三条理由说成代价而不是优点：服务级令牌泄露一次等于全量用户数据泄露，用户级泄露一张只丢一个用户且十五分钟自动作废；服务级在审计日志里只能查到「某服务调了一次」，查不到替谁操作；下游做用户级权限判断时，服务级令牌逼着它去信请求体里的 userId，而那是调用方可以随便写的。
  4. 补一句生产视角：两者不是二选一，真实系统里常常是「服务级令牌用来换用户级令牌」——调用方先用自己的服务凭证证明自己是谁，再申请一张代表某个用户的短期令牌。这样服务凭证只出现在铸造这一步，不出现在每一次业务调用里。
  5. 可以预期的追问一：令牌泄露了怎么办？答案要分两层——短有效期（本课 15 分钟）是止损的主力，撤销列表按 jti 拉黑是补充；不要上来就说「用黑名单」，那等于给每次验签加一次数据库查询，把无状态验签的好处全赔进去了。
  6. 可以预期的追问二：那 scope 该切多细？给一条可操作的判据——按「读写不对称的风险」切，读错了泄露信息、写错了污染数据且会持续影响后续每一轮对话，所以 read 和 write 必须分开；再细就要看有没有真实的调用方只需要其中一半。

  Key points

  • The deciding question is whether a specific user stands behind the call: yes means user token, no (config, metrics, reconciliation) means service token
  • A leaked service token exposes every user; a leaked user token exposes one and expires on its own
  • Auditing has to reach a person — only the sub claim answers who the call was made on behalf of
  • With a service token the downstream must trust a userId in the request body, which the caller can forge
  • Common production shape: the service credential only buys short-lived per-user tokens and never appears on business calls
  • After a leak, short lifetimes do the containment and a jti denylist supplements it — do not trade away stateless verification by default

  答题要点

  • 判断依据是「这次调用背后有没有一个具体用户」：有就用用户级，没有（配置、指标、对账批处理）才用服务级
  • 服务级令牌泄露的爆炸半径是全量用户，用户级只影响一个用户且短期自动失效
  • 审计要能落到人：只有 sub 字段能回答「当时是替谁操作的」
  • 下游要做用户级权限判断时，服务级令牌逼着它去信请求体里的 userId，而那是调用方可以伪造的
  • 生产里常见组合：服务凭证只用来换取代表某个用户的短期令牌，不出现在每次业务调用里
  • 泄露后的止损顺序是短有效期优先、jti 撤销列表补充，别一上来就上黑名单换掉无状态验签

D22 Security: Prompt Injection, Least Privilege for Tools, Sandboxing Approaches, Secret Management

• When an agent has to run untrusted code or commands, what sandboxing options do you have? Which tier would you pick and why?Agent 要执行不受信任的代码或命令时，有哪些沙箱隔离思路？你们选了哪一档，为什么？

  Common in ChinaCommon overseasIntermediate#sandboxing#security#tool-execution

  How to reason about it · think before answering

  1. The spread here is not how many isolation techniques you can name, it is whether you can say what each tier stops and what it lets through. 'We use a sandbox' says nothing, and the next question will be 'does it stop data exfiltration?'
  2. First explain why these tools are special: an allowlist governs whether a tool may be called, but for a tool whose whole job is 'run this thing I hand you', the allowlist degrades into a hall pass, because the danger lives in the arguments rather than the name. So you switch technique — instead of judging whether the code is bad, you shrink what it can reach. Same idea as permission enforcement, applied to a process instead of a tool.
  3. Then give three tiers by cost. Process level: a separate child process, a hard timeout, an environment-variable allowlist, a read-only working directory; stops crash propagation, hung loops and secret theft; does not stop network exfiltration or reads elsewhere on the host. Container level: no network, read-only rootfs, non-root user, CPU/memory/pid limits, disposable per run; adds exfiltration and out-of-bounds access; does not stop a kernel escape. MicroVM: a lightweight VM with its own kernel, stops most escapes, at the price of cold start and cost.
  4. Give the selection rule, which is what the interviewer actually wants: if you wrote the code and only the arguments are untrusted, process level is enough; if the code itself comes from the model or a user, container level is the floor; if you run arbitrary third-party code as a service, go to microVM.
  5. Call out the classic implementation bug: people spawn a child process and assume they are isolated, then hand it the parent's entire environment. The process is separate but the secrets went with it, and one line reading an environment variable prints your API key. The child's environment must be a fresh object copied from an allowlist, never inherited.
  6. Expect the follow-up: what happens on timeout? Use a signal that actually kills the process, and report 'killed by timeout' as its own failure class rather than folding it into generic errors — it usually means somebody is probing for resource exhaustion, not that the code has a bug.

  分析过程 · 先想清楚再作答

  1. 这题的区分度不在于能背出几种隔离手段，而在于你说不说得出每一档挡住了什么、放过了什么。只说「我们用了沙箱」等于没说，面试官下一句一定是「那它挡得住外发数据吗」。
  2. 先说清这类工具为什么特殊：白名单管的是「能不能调」，但「执行一段你给的东西」这类工具一旦进了工具表，白名单就退化成一张通行证，因为危险面在参数里不在工具名里。所以要换一种手段——不判断这段代码坏不坏，而是收窄它能触碰的东西。这和权限侧强制是同一个思路，只是对象从工具换成了进程。
  3. 然后按代价从低到高给三档。进程级：独立子进程、超时必杀、环境变量白名单、只读工作目录；挡住崩溃传染、死循环挂住主进程、密钥被读走；挡不住网络外发和读系统里的其他文件。容器级：无网络、只读 rootfs、非 root、CPU 与内存限额、进程数限额、用完即弃；把外发和越界读写也挡掉；挡不住内核漏洞逃逸。microVM：独立内核的轻量虚拟机，挡住多数逃逸，代价是冷启动和成本。
  4. 给选型判据，这是面试官真正想听的：代码是你写的、只是参数不可信，进程级够用；代码本身来自模型或用户，最低容器级；要跑第三方任意代码还对外提供服务，上 microVM。
  5. 点一个高频实现坑：很多人起了子进程就以为隔离了，却把父进程的环境变量整个传过去——进程是独立了，密钥跟着过去了，子进程一句读环境变量就把 API key 打印出来。子进程的环境必须是白名单拷出来的新对象，而不是继承。
  6. 可以预期的追问：超时之后怎么办？要用能真正杀死进程的信号，并且把「被超时杀掉」当成一个独立的失败类型上报，而不是混进普通报错——它通常意味着有人在试资源耗尽，而不是代码写错了。

  Key points

  • For execute-style tools the danger is in the arguments, so an allowlist cannot help; isolate instead — shrink what the code can reach rather than judging it
  • Process level: child process, hard timeout, environment allowlist, read-only workdir; stops crashes, hangs and secret theft, not exfiltration
  • Container level: no network, read-only rootfs, non-root, CPU/memory/pid limits, disposable; stops exfiltration and out-of-bounds access, not kernel escapes
  • MicroVM: own kernel, stops most escapes, costs cold start and money; choose by who wrote the code and whether you serve it publicly
  • The classic bug is handing the child process the whole parent environment — isolated process, leaked secrets

  答题要点

  • 执行类工具的危险面在参数里，白名单管不住，要靠隔离：不判断代码坏不坏，而是收窄它能触碰的东西
  • 进程级：子进程 + 超时必杀 + 环境变量白名单 + 只读工作目录；挡崩溃、死循环、密钥泄漏，挡不住外发
  • 容器级：无网络、只读 rootfs、非 root、CPU 内存与进程数限额、用完即弃；挡外发与越界读写，挡不住内核逃逸
  • microVM：独立内核，挡多数逃逸，代价是冷启动与成本；判据是代码来自谁、要不要对外提供服务
  • 最常见的实现坑是把 process.env 整个传给子进程——进程隔离了，密钥跟着过去了
• How should secrets be managed in an agent system? Where must they never appear, and how do you rotate them without downtime?Agent 系统里的密钥应该怎么管理？它绝对不能出现在哪些地方，轮换要怎么做才能不停机？

  Common in ChinaCommon overseasIntermediate#secrets-management#security#observability

  How to reason about it · think before answering

  1. It reads like a giveaway, but there is one answer point specific to agents, and missing it makes you sound like a generic backend engineer: secrets must never enter the LLM context. The interviewer asked about an agent system, and that is the line he is waiting for.
  2. Give the four 'nevers', one line each. Never in code — hardcoding hands the secret to everyone with read access, and deleting the line does not remove it from git history. Never in logs — the highest-frequency leak channel; nobody prints a secret on purpose, but 'log the whole request header so we can debug' is universal. Never in the LLM context. Never in error messages — responses to the frontend and exceptions thrown upstream are both outbound channels.
  3. Expand the third one, since it is what differentiates the answer: once a secret is in the context it will be sent to the model vendor, stored in conversation history, written into traces, and eventually read out loud by some prompt injection. What the agent needs is the capability to call an API, not the key itself — the key stays inside the tool implementation, and the model only ever sees the tool name and its arguments.
  4. Then the mechanics: redact at a single logging exit rather than trusting callers. Relying on everyone to mask by hand guarantees a miss. Do it in the one place logs leave the process, with two passes — replace known secret values from the environment, then catch the rest with generic shape patterns. Route the exception path through the same exit, because stack traces routinely carry connection strings with credentials.
  5. Storage and rotation: dotenv plus gitignore locally; in production a secret manager the process reads at startup under its own workload identity, never values baked into an image or a deployment manifest. Rotate dual-key: accept old and new simultaneously, shift traffic to the new one, confirm the old one has no remaining callers, then revoke. A single-shot swap always leaves a failure window on some replica.
  6. Expect the follow-up: how often do you rotate? The interval is secondary — what you should actually rehearse is whether you can revoke and replace a suspected-leaked key within five minutes. Saying that shows you are thinking about incident response rather than a compliance checkbox.

  分析过程 · 先想清楚再作答

  1. 这题看着是送分题，但有一个专属于 Agent 的答案点，答不出来就只是通用后端水平：密钥不能进 LLM 上下文。面试官问的是 Agent 系统，这一条就是他在等的。
  2. 先给四不入，一条一句：不入代码（写死在源码里等于给了所有有仓库读权限的人，而且删掉那一行 git 历史里还在）；不入日志（最高频的泄漏渠道，没人故意打印密钥，但「把请求头整个打出来方便排查」每个团队都干过）；不入 LLM 上下文；不入错误信息（返回给前端的报错和抛给上游的异常都是对外出口）。
  3. 把第三条展开，这是本题的差异点：密钥一旦进了上下文，就意味着它会被送到模型厂商、被存进会话历史、被写进 trace，然后在某一次提示词注入里被完整地念出来。正确的形态是 Agent 需要的是「能调用某个 API」这个能力，而不是那把钥匙本身——密钥留在工具的实现里，模型只看得到工具名和参数。
  4. 再给落地手段：日志出口统一脱敏，不靠调用方自觉。靠每个人写日志时记得手动打码，一定会漏。做法是在唯一的日志出口做替换，两条路一起用——进程里已知的密钥值整段替换，再用通用形状兜底那些不是从环境变量来的密钥。异常处理那一支也要走同一个出口，堆栈里经常夹着带密钥的连接串。
  5. 存储与轮换：本地开发用 .env 加 gitignore；线上走密钥管理服务，进程启动时按自己的身份去取，不要把值烤进镜像或写进部署清单。轮换要双活——同时允许新旧两把 key，流量切到新 key、观察到没有旧 key 的调用了再吊销，一次性替换必然在某个副本上留下失败窗口。
  6. 可以预期的追问：轮换周期定多久？周期是次要的，真正要演练的是「能不能在 5 分钟内换掉一把疑似泄漏的 key」。答得出这一句，说明你想的是事故响应而不是合规打卡。

  Key points

  • Four nevers: never in code, never in logs, never in the LLM context, never in error messages
  • The agent-specific one is the context — anything there reaches the vendor, the history and the traces, and can be read out by an injection
  • The agent needs the capability to call an API, not the key; the key stays inside the tool implementation
  • Redact at one logging exit instead of trusting callers, and route the exception path through it too
  • Use a secret manager with workload identity in production, and rotate dual-key: accept both, shift traffic, verify no old callers, then revoke

  答题要点

  • 四不入：不入代码、不入日志、不入 LLM 上下文、不入错误信息
  • Agent 特有的一条是不入上下文——进了上下文就会被送到厂商、存进历史、写进 trace，并可能被注入念出来
  • Agent 需要的是「能调用某个 API」的能力而不是钥匙本身，密钥留在工具实现里
  • 日志出口统一 redact，不靠调用方自觉；异常路径走同一个出口，堆栈里常夹着连接串
  • 线上走密钥管理服务按身份拉取；轮换用双活，新旧同时有效、切流量、确认无旧调用再吊销

Mastering Codex and the OpenAI Agents SDK in 5 Days

D1 Getting Started With the Codex CLI: Install, AGENTS.md, Approval Modes and the Sandbox, Common Commands

• Codex splits 'when to ask the user' and 'what can be touched' into two independent settings, approval_policy and sandbox_mode. Why separate them, and what does each solve?Codex 把「什么时候问用户」和「能碰到什么」拆成 approval_policy 和 sandbox_mode 两组独立开关。为什么要拆？各自解决什么问题？

  Common in ChinaCommon overseasIntermediate#coding-agent#security#sandbox

  How to reason about it · think before answering

  1. The discriminating part is 'why separate'; reciting the values without explaining orthogonality earns little.
  2. Define both: approval policy is process control, whether a human must nod before an action; sandbox is permission control, whether the OS allows the action at all.
  3. Then justify orthogonality with combinations a single slider cannot express: 'do not interrupt me but never leave the workspace' versus 'ask every time but read-only'.
  4. Ground it in implementation: the sandbox uses OS mechanisms (Seatbelt on macOS, bubblewrap on Linux) rather than model goodwill, so it is a hard limit, while approval is the one human checkpoint.
  5. Expect the follow-up: why is network off by default? Because network is the channel for code leaving or entering the machine, a different risk class from local edits.

  分析过程 · 先想清楚再作答

  1. 题眼是「为什么拆」。只背出每组的取值等于没答，面试官要听的是两者正交带来的好处。
  2. 先给定义：审批策略是流程控制，决定动作执行前要不要人点头；沙箱是权限控制，决定即使模型想做、操作系统允不允许。
  3. 再说为什么正交：你可能想要「不打扰我，但绝不许出工作区」（on-request 加 workspace-write），也可能想要「每步都问，但只让它读」（untrusted 加 read-only）；合成一个滑杆就表达不了这两种组合。
  4. 落到实现：沙箱靠操作系统机制（macOS Seatbelt、Linux bubblewrap），不是靠模型自觉，所以它是硬约束；审批则是唯一由人把关的环节。
  5. 可预期的追问：为什么网络默认关？因为联网是把内部代码送出去或把外部代码拉进来的通道，风险等级和改本地文件不同，需要单独授权。

  Key points

  • approval_policy governs process: untrusted / on-request / on-failure / never decide whether a human confirms first
  • sandbox_mode governs permission: read-only / workspace-write / danger-full-access decide what the OS allows
  • Orthogonality lets you express 'no interruptions but stay in the workspace' and 'ask each step but read-only'
  • The sandbox is an OS-level hard limit, approval is the human checkpoint, and network is off by default

  答题要点

  • approval_policy 管流程：untrusted / on-request / on-failure / never 决定动作前是否要人确认
  • sandbox_mode 管权限：read-only / workspace-write / danger-full-access 决定操作系统放行什么
  • 两者正交才能表达「不打扰但不越界」和「步步问但只读」这类组合
  • 沙箱是操作系统级硬约束，审批是唯一的人工把关点；网络默认关闭需单独放开
• You want to introduce a coding agent that runs commands locally. How do you explain its risk boundary to skeptical teammates?你要在团队里引入一个能在本地执行命令的 coding agent，怎么向不放心的同事解释它的风险边界？

  Common in ChinaCommon overseasIntermediate#coding-agent#security#communication

  How to reason about it · think before answering

  1. This tests communication as much as engineering: state the technical boundary in terms the listener can verify, not just 'it is safe'.
  2. Present three layers of defense: written rules (AGENTS.md) shape habits; the sandbox limits capability to read-only or workspace-only writes with network off; approvals gate every exception.
  3. Offer verifiable guarantees: every change lands in the git working tree, visible via diff and revertable via checkout; unattended runs stay on throwaway branches or containers.
  4. Name the residual risk yourself: the model can misread a requirement and produce wrong but passing code, so review and tests remain mandatory, and secrets stay out of readable files.
  5. Expect the follow-up: can network be fully blocked? Yes, the sandbox is offline by default; approve installs case by case or configure an allow-list of domains.

  分析过程 · 先想清楚再作答

  1. 这题考的是沟通加工程两层：既要说清技术上的边界，又要用对方能验证的方式说，不能只说「它很安全」。
  2. 拆成三层防线来讲：第一层文字规则（AGENTS.md）管习惯；第二层沙箱管能力，只读或只能写工作区、网络默认关；第三层审批管例外，越界的每一步都要人批。
  3. 给出可验证的承诺：所有改动都在 git 工作区里，`git diff` 能看、`git checkout` 能撤；脱手运行只跑在一次性分支或容器里。
  4. 主动说出剩余风险：模型可能误读需求写出错误但能通过的代码，所以审查和测试不能省；密钥不要放在它能读到的文件里。
  5. 可预期的追问：能不能完全禁止它联网？可以，沙箱默认就不通网，需要装依赖时逐次批准，或在配置里给一个允许的域名清单。

  Key points

  • Three layers: written rules for habits, the sandbox for capability, approvals for exceptions
  • All edits live in the git working tree and are diffable and revertable; unattended runs use throwaway branches or containers
  • State residual risks yourself: wrong-but-passing code and secret exposure, hence mandatory review and tests
  • Network is off by default; approve per request or configure an allow-list

  答题要点

  • 三层防线：文字规则管习惯、沙箱管能力、审批管例外
  • 改动全在 git 工作区，可 diff 可撤销；脱手运行只在一次性分支或容器
  • 主动说明剩余风险：错误但能通过的代码、密钥暴露，所以审查与测试不能省
  • 网络默认关闭，联网按次批准或配置允许域名清单

D3 The Responses API and Built-in Tools: Function Calling, Web Search / File Search / Computer Use, Structured Output

• When do you use platform built-in tools (web search, file search, computer use) versus your own function tools, and why does computer use deserve special treatment?平台内置的工具（web search、file search、computer use）和自己写的函数工具，各适合什么场景？为什么 computer use 要单独对待？

  Common in ChinaCommon overseasIntermediate#tools#responses-api#security

  How to reason about it · think before answering

  1. Two cruxes: who executes the tool, and how large its side effects are; comparing features alone signals no production experience.
  2. Executor test: built-in tools run server-side, you declare but never fill results and cannot steer the search; function tools run in your code, more work but full control.
  3. Map to scenarios: external, generic data (the web, your uploaded documents) fits built-ins; data inside your systems (databases, internal services, business logic) needs functions; production mixes both.
  4. Order by side effects: web search reads the public web, file search reads your files, function calls have whatever side effects your code allows, computer use lets the model act directly; more capability demands heavier isolation.
  5. Computer use is special because it can click anything, type anything and be steered by on-screen content, so the starting point is an isolated environment, a restricted account and an allow-list, not code.
  6. Expect the follow-up: built-in file search versus your own RAG? The built-in is a managed pipeline that skips chunking, embedding and retrieval work at the cost of control and observability; build your own when you need custom chunking or reranking.

  分析过程 · 先想清楚再作答

  1. 题眼有两个：一是「谁来执行」，二是「副作用有多大」。只答功能对比不谈执行方与风险，就是没做过工程。
  2. 先给执行方的判据：内置工具由平台在服务端执行，你只声明、不回填、也控制不了它怎么搜；函数工具由你执行，样样自己写，但每一步都在你手里。
  3. 落到场景：数据在外面且通用（公网、你上传的文档）用内置工具；数据在你系统里（数据库、内部服务、业务逻辑）写函数；生产系统几乎总是混用。
  4. 再按副作用排一条光谱：web search 只读公网，file search 只读你给的文件，函数调用的副作用由你的代码决定，computer use 由模型直接产生副作用——越往右能力越强，需要的隔离越重。
  5. computer use 单独对待的原因：它能点任何按钮、输任何文字，还可能被页面内容诱导，所以正确起点是隔离环境、受限账号和站点与动作白名单，不是代码。
  6. 可预期的追问：内置的 file search 和自己搭 RAG 怎么选？前者是托管版，省掉切分、向量化、检索三步，代价是可控性与可观测性弱，需要自定义切分或重排时才自己搭。

  Key points

  • Built-ins run on the platform with no result filling and no steering; functions run in your code with full control
  • External generic data suits built-ins, in-system data and business logic need functions, production mixes both
  • Rank by side effects: web search, file search, function calls, computer use; more power needs more isolation
  • Computer use starts with an isolated environment and an allow-list, not with code

  答题要点

  • 内置工具由平台执行、不用回填、不可干预；函数工具由你执行、全部可控
  • 外部通用数据用内置工具，系统内数据与业务逻辑写函数，生产混用
  • 按副作用排序：web search、file search、函数调用、computer use，能力越强隔离越重
  • computer use 的起点是隔离环境与白名单，不是代码

MCP in 7 Days: Wire Tools Into Any Agent

D1 Why a Protocol: the Host/Client/Server Triangle, JSON-RPC Messages, and Three Primitives

• Why does the MCP spec require one client per server instead of multiplexing many servers over one connection?MCP 规范为什么规定一个客户端只连一个服务端？多路复用不是更省资源吗？

  Common in ChinaCommon overseasIntermediate#architecture#security

  How to reason about it · think before answering

  1. It reads like a performance question but is really about security boundaries. Answering only in terms of connection count signals you never read the design principles.
  2. Ask who can see whom once a channel is shared. The spec fixes two principles: servers should not read the whole conversation, and should not see into other servers. One-to-one is the most direct way to enforce both.
  3. Concrete consequence: with isolation, a third-party weather server sees only the city you passed. On a shared channel it could observe traffic between you and an internal database server — a data leak.
  4. Conclusion: full history stays with the host, each server receives only the arguments this call needs, and the host is the single place where boundaries are enforced and cross-server orchestration happens.
  5. State the cost yourself: N servers means N connections and N lifecycles, and that is where most client complexity lives, not in sending messages.
  6. Likely follow-up: how do you handle tool name collisions across servers? Aggregation and disambiguation belong to the host; the spec suggests prefixing with a server identifier and explicitly warns against relying on the server's self-reported name, which is neither unique nor verified.

  分析过程 · 先想清楚再作答

  1. 这题看着在问性能，其实在问安全边界。只从连接数和资源占用切入的回答会被判为没读过设计原则那一节。
  2. 拆法：先问「共享一条通道之后，谁能看见谁」。规范写死了两条原则——服务端不应该读到整段对话，也不应该看得见别的服务端；一对一是实现这两条最直接的手段。
  3. 举一个具体后果：接一个第三方天气服务端时，一对一隔离让它只能看到你传的城市名；共享通道则可能让它读到你和内部数据库服务端之间的往来，那就是一次数据泄露。
  4. 结论：完整对话历史留在宿主，服务端只拿到这次真正需要的参数；宿主是唯一的安全边界执行者，也是唯一做跨服务端编排的地方。
  5. 代价要主动说：接 N 个服务端就有 N 条连接、N 套生命周期要管，客户端实现的复杂度大头正是在这里，而不是在发报文上。
  6. 可预期的追问：那多个服务端的工具重名怎么办？答案是聚合与消歧是宿主侧的职责，规范建议加服务端标识前缀，并且明确说不要依赖服务端自报的名字，因为它不保证唯一也未经验证。

  Key points

  • One-to-one is a security decision, not a performance one: servers cannot read the conversation or see peers
  • Full history stays in the host; a server receives only the arguments for the current call
  • Aggregation, disambiguation, and authorization all happen in the host, so there is a single boundary to harden
  • The cost is connection and lifecycle management, which dominates client implementation complexity

  答题要点

  • 一对一是安全设计而非性能设计：服务端读不到整段对话，也看不见别的服务端
  • 完整历史留在宿主，服务端只收到本次调用真正需要的参数
  • 跨服务端的聚合、消歧、授权都由宿主统一做，边界只有一处需要加固
  • 代价是连接与生命周期管理，这是客户端实现复杂度的主要来源

D4 Remote MCP: the Streamable HTTP Binding, the Stateless Model and Request Metadata, OAuth 2.1 Authorization, Container Deployment

• Streamable HTTP requires the Mcp-Method header to match the method in the request body. Why mirror it at all, and what breaks if the server does not validate the match?Streamable HTTP 要求 Mcp-Method 头必须和请求体里的 method 一致。为什么要抄一遍？不校验会有什么风险？

  Common in ChinaCommon overseasIntermediate#transport#security

  How to reason about it · think before answering

  1. The real question is the second half. 'It helps gateways route' is half an answer; the interviewer is waiting for a concrete attack, which separates having read the spec from having understood it.
  2. Why mirror: intermediaries should not parse the body to make decisions. A load balancer routing by method, a rate limiter capping tools/call, an observability probe tagging spans — all can read a header instead of deserializing tens of kilobytes. The same applies to Mcp-Name (from params.name or params.uri) and MCP-Protocol-Version.
  3. Then derive the risk: if intermediaries decide on the header and the server executes on the body, there are two sources of truth. Concretely, a gateway configured as 'tools/list is unauthenticated, tools/call is authenticated' is bypassed by sending the header as tools/list and the body as tools/call. The same trick evades rate limits, audit tagging, and per-parameter regional isolation.
  4. Conclusion: the spec therefore requires any server that processes the body to validate the match and reject with 400 plus -32020 (HeaderMismatch). It is not pedantry — it collapses two sources of truth back into one.
  5. Volunteer the implementation trap: header values are visible ASCII only, so non-ASCII tool names or resource URIs use the =?base64?...?= sentinel, and the server must decode before comparing or its own check will reject valid requests. Integer values should be compared numerically, not as strings.
  6. Likely follow-up: should intermediaries validate too? The spec advises that any intermediary enforcing policy from mirrored headers first confirm MCP-Protocol-Version names a revision that mandates header-body validation, and otherwise reject rather than trust unvalidated headers.

  分析过程 · 先想清楚再作答

  1. 这题的题眼在后半句。只答「方便网关路由」是答了一半，面试官等的是「不一致会怎样」——能不能自己举出攻击场景，是区分「读过规范」和「理解规范」的地方。
  2. 先说为什么镜像：中间层不该为了做决策去解析请求体。负载均衡想按方法分流、限流器想给 tools/call 单独设阈值、可观测探针想打标签，只看头就够了，不用把几十 KB 的 body 反序列化一遍。同理还有 Mcp-Name（取自 params.name 或 params.uri）和 MCP-Protocol-Version。
  3. 再推风险：既然中间层按头决策、服务端按体执行，两个事实来源就分叉了。举个具体的：网关配了「tools/list 免鉴权、tools/call 要鉴权」，攻击者把头写成 tools/list、体写成 tools/call，鉴权就被绕过去了。同样的套路可以绕限流、绕审计、绕按参数值做的地域隔离。
  4. 结论：所以规范规定处理请求体的服务端必须校验头体一致，不一致必须回 400 加 -32020（HeaderMismatch）。这不是格式洁癖，是把「两个事实来源」重新合并成一个。
  5. 实现上有个坑值得主动说：头值只能是可见 ASCII，非 ASCII 的工具名或资源 URI 要用 =?base64?...?= 哨兵格式编码，服务端必须先解码再比对，否则自己的校验会把正常请求判成不一致。整数值应当按数值比较而不是按字符串比较。
  6. 可预期的追问：中间层自己要不要校验？规范建议按头做策略的中间层先确认 MCP-Protocol-Version 指向的是一个要求头体校验的版本，版本更老或头缺失时应当直接拒绝，而不是信任未经校验的头值。

  Key points

  • Mirroring lets gateways, rate limiters, and probes route and tag without parsing the body
  • Skipping validation creates two sources of truth: header tools/list with body tools/call bypasses per-method auth and limits
  • The spec requires any body-processing server to validate the match and return 400 with -32020 on mismatch
  • Non-ASCII values use the base64 sentinel, so decode before comparing; compare integers numerically

  答题要点

  • 镜像是为了让网关、限流器、探针不用解析请求体就能路由和打标签
  • 不校验就有两个事实来源：头写 tools/list、体写 tools/call 可以绕过按方法配置的鉴权与限流
  • 规范要求处理请求体的服务端必须校验一致性，不一致回 400 与 -32020
  • 非 ASCII 值用 base64 哨兵格式，服务端必须先解码再比对；整数按数值比较

D6 Security and Governance: Prompt Injection in Tool Descriptions, the Confused Deputy, Least Privilege, Audit Logs, and a Tool Allowlist

• Since the protocol is stateless, a server that needs state mints a handle for the client to carry back. What attack surface does that create, and how do you close it?2026-07-28 之后协议是无状态的，服务端要保存状态就得铸一个句柄让客户端带回来。这会带来什么新的攻击面？怎么防？

  Common in ChinaCommon overseasIntermediate#statelessness#security

  How to reason about it · think before answering

  1. This checks whether you re-derived the threat model after the mechanism changed. Everyone knows session hijacking from the previous revision; sessions are gone now, so many assume the problem left with them. It only got renamed to state handle hijacking.
  2. Describe the attack in four steps: the server mints a handle for an authenticated user and returns it in a tool result; the attacker obtains or guesses it; the attacker sends it back as an ordinary tool argument; the server never checks whether the handle belongs to the caller and operates on the original user's state.
  3. Unpack 'obtains or guesses', because it decides where the defense goes. Guessing means the handle is predictable, such as a sequential id, a timestamp, or too little entropy. Obtaining has many paths: the handle appears in a tool result, so it enters the model context, the logs, possibly another server's view, and it can be coaxed out by a prompt injection. The assumption that handles stay secret is not available to you.
  4. Answer the defenses in the spec's tiers. Mandatory: servers implementing authorization MUST verify all inbound requests and MUST NOT treat possession of a handle as authentication. That is the crux, a handle is a name, not a credential. Recommended: generate handles from a secure random source, avoid predictable or sequential identifiers, and expire them. The most effective recommendation is binding: key server-side storage as user id plus handle, with the user id derived from the verified token rather than supplied by the client, and reject a handle presented by any other principal, so guessing it still buys nothing.
  5. Volunteer that requestState belongs to the same family: a server-signed opaque blob carried back through the client in multi round-trip requests, which the spec requires you to treat as attacker-controlled input, protect with HMAC or AEAD, verify with a constant-time comparison, and bind to the authenticated principal, an originating-request identifier, and a short expiry, covering cross-user, cross-request, and timeout replay.
  6. One-line conclusion: statelessness did not remove state, it moved it into the client's hands, so 'who can present it' and 'who is allowed to use it' must be judged separately.
  7. Likely follow-ups: does signing guarantee single use? No, it only bounds the replay window; true one-time consumption needs a server-side redemption record. And what about replicas? The data behind a handle already lives in shared storage, and requestState only needs a shared signing key, which is still stateless because nothing per client sits in a replica's memory.

  分析过程 · 先想清楚再作答

  1. 这题在考「换了机制之后有没有重新想过威胁模型」。上一版的会话劫持大家都熟，这一版会话没了，很多人就默认问题跟着消失了——其实只是换了个名字叫状态句柄劫持。
  2. 先描述攻击，四步很短：服务端为已认证用户铸一个句柄并放在工具结果里返回；攻击者拿到或猜到这个句柄；攻击者把它当成普通工具参数发过来；服务端没检查这个句柄属不属于调用者，于是操作了原用户的状态。
  3. 拆「拿到或猜到」这一层很关键，因为它决定了防线该架在哪。猜到，说明句柄可预测（自增 id、时间戳、短随机数）；拿到，路径就多了——它出现在工具结果里，而工具结果会进模型上下文、会进日志、可能被另一个服务端看到，也可能被一次提示注入骗着吐出来。所以「句柄不会泄漏」这个假设不能要。
  4. 防线按规范分三层答。硬性的：实现了授权的服务端**必须**校验所有入站请求，并且**绝不能**把持有句柄当成身份认证——这是整题的题眼，句柄是名字不是凭证。应当层：用安全随机数生成，避免可预测或连续的标识，并设过期。最管用的一层也是应当：**在服务端把句柄绑定到已认证的主体**，比如存储的键做成「用户 id 加句柄」，用户 id 从校验过的令牌里取而不是客户端传，别的主体拿着同一个句柄来就查不到。这样即使猜中也冒充不了别人。
  5. 然后主动把 requestState 归到同一类：它是多轮请求里由服务端签发、经客户端转手带回的不透明状态，规范要求把它当成攻击者可控输入，用 HMAC 或 AEAD 做完整性保护、验签用定长比较，并把认证主体、原请求标识、短过期一起签进去，分别挡跨用户、跨请求和超时三种重放。
  6. 结论一句话：无状态没有消灭状态，只是把状态挪到了客户端手里，于是「谁能出示它」和「谁有权用它」必须被分开对待。
  7. 可预期的追问一：签名能不能保证一次性？不能，签名只缩小重放窗口，真要单次消费得在服务端加一层消费记录。追问二：多副本部署怎么办？句柄背后的数据本来就在共享存储里，requestState 只需要各副本共享签名密钥——这仍然是无状态的，因为服务端内存里没有为某个客户端留东西。

  Key points

  • The new surface is state handle hijacking: anyone who obtains or guesses a handle can act on another user's state
  • Handles surface in tool results, model context and logs, so secrecy is not a safe assumption
  • Mandatory: verify every inbound request and never treat possession of a handle as authentication
  • Use secure randomness, expiry, and server-side binding keyed by principal plus handle; requestState needs signing bound to principal and a short expiry

  答题要点

  • 新攻击面叫状态句柄劫持：拿到或猜到句柄的人可以操作别人的状态
  • 句柄会出现在工具结果、上下文与日志里，不能假设它不泄漏
  • 硬性要求：必须校验所有入站请求，绝不能把持有句柄当成身份认证
  • 做法：安全随机、设过期、按「主体加句柄」在服务端绑定；requestState 同理，验签并签进主体与短过期