Agent权限越权风险：Prompt无法鉴权，需前置校验用户身份
Your agent acts with its own permissions, not the user's
Agent安全是落地关键痛点，这篇复盘给出了具体的鉴权缺失场景与可复现的修复流程，做Agent开发的同学建议对照检查自己的权限链路。
I learned this the hard way with an ops agent I built at work. I gave it one write tool: open a PR against our GitOps repo. Not merge, just open. It felt safe, until I realized the agent's token could push, so it would open a PR for anyone who asked, including people with read-only access to that repo.
我是通过一个在工作的 ops agent 惨痛地学到了这一点。我给了它一个写入工具：针对我们的 GitOps 仓库打开一个 PR（Pull Request）。不是合并，只是打开。当时觉得挺安全，直到我意识到该 agent 的 token 具有推送权限，因此它会为任何提出要求的人打开 PR，包括那些对该仓库只有只读权限的人。
What I learned fixing it:
我在修复过程中学到的教训：
- The prompt can't do authorization. The model has never seen your GitHub permissions, and even if it guessed right, the API call still runs with the bot's token.
- The user can't be a tool argument. If the model fills in who it acts for, it can be talked into filling in an admin. The user has to come from your session (Slack, SSO), set before the agent runs.
- No answer means no. If GitHub times out or errors, the agent stops instead of going ahead.
- 提示词无法执行授权。模型从未见过你的 GitHub 权限设置，即使它猜对了，API 调用仍然使用机器人的 token 运行。
- 用户不能作为工具参数传入。如果模型自行填充其代表谁操作，它可能会被诱导去填充管理员身份。用户信息必须来自你的会话上下文（如 Slack、SSO），且在 agent 运行前就已设定好。
- 没有回答即意味着拒绝。如果 GitHub 超时或报错，agent 应停止执行，而不是继续推进。
The fix was one call before the write: ask GitHub whether the person who typed the request may push to that repo. Yes → go ahead. No or no answer → stop and say why.
修复方案是在执行写入操作之前增加一次调用：询问 GitHub 提出请求的人是否有权向该仓库推送代码。允许 → 继续执行；不允许或无回复 → 停止并说明原因。
Full write-up: https://medium.com/@roeehersh/i-gave-my-ai-agent-one-harmless-permission-it-became-a-backdoor-for-everyone-728acf52e37e
完整文章：https://medium.com/@roeehersh/i-gave-my-ai-agent-one-harmless-permission-it-became-a-backdoor-for-everyone-728acf52e37e
How do you pass the user's identity into your tools today? Context var, closure, something else?
你今天如何将用户的身份信息传递给工具？是通过上下文变量、闭包，还是其他方式？
更进一步：量化金融体系
看懂新闻只是起点——沿量化金融路径，把它变成能交付的工程能力