Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

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

• 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，不靠调用方自觉；异常路径走同一个出口，堆栈里常夹着连接串
  • 线上走密钥管理服务按身份拉取；轮换用双活，新旧同时有效、切流量、确认无旧调用再吊销