Agent 安全架构避坑：权限、上下文与工具边界的三道坎

Agent 安全架构避坑权限、上下文与工具边界的三道坎一、给模型装了手和脚谁来管它不越界当大模型只是聊天机器人风险上限是说错话。一旦它升级成 Agent能调接口、读文件、发消息、下单风险上限立刻变成做错事。很多团队在搭建 Agent 时先把能力接满再补安全。结果权限、上下文、工具三处边界同时失守。第一道坎在权限。Agent 往往拿着一把万能钥匙同一个令牌既能读用户数据又能删库、能发全员邮件。它本该只在用户授权范围内动作却因令牌过宽一次误判就酿成事故。权限不是能不能调通而是该不该这么调。第二道坎在上下文。多轮对话把历史、检索结果、工具回传都堆进提示词。污染只要渗进任意一处就会在后续轮次里被模型当作事实。更糟的是上下文没有边界标记模型分不清哪句是用户说的、哪句是工具返回的、哪句是别人塞进来的。第三道坎在工具。工具描述写发送邮件模型就可能用它群发工具没有二次确认模型一次出错就对外生效。很多团队把工具当黑盒接上却没在工具层做权限与校验把所有信任压在模型的自觉上。这三道坎不是孤立的。权限过宽让越界后果放大上下文污染让越界被触发工具无校验让越界直接落地。任何一道失守Agent 都可能做出超出预期的动作。下面逐道拆解它们的机制与解法。二、三道坎的耦合机制一次越界如何层层放大把 Agent 的执行看成一条链权限、上下文、工具三道坎依次叠在链路上。任何一环的失守都会把风险放大到下一环。用户的一句注入先进入上下文管理器。若上下文不做来源标记污染会被当作可信事实。模型据此生成工具调用意图交到工具执行层。此时若权限网关过宽本不该放行的动作被通过工具执行层若没有二次确认动作直接对外生效。工具回传的结果再次进入上下文可能形成二次注入开启新一轮循环。这就是三道坎耦合放大的路径上下文污染触发误判宽权限放行误判无校验工具落地误判。断任何一环都能把事故拦在半路。但要认清模型本身无法真正理解禁止。系统提示里写不要删除文件只是提高了概率不构成强制。真正的约束必须落在权限网关与工具层让模型不能而非不该。三、生产级 Agent 安全骨架把三道坎变成三道闸下面是一段 Agent 安全执行骨架。它把权限网关、上下文来源标记、工具二次确认三道闸串起来并内置超时、并发与降级。import asyncio import uuid # 权限策略每个工具绑定最小必要作用域而非全局令牌 TOOL_POLICY { send_email: {scope: email:send:self, require_confirm: True}, read_record: {scope: record:read:owner, require_confirm: False}, delete_file: {scope: file:delete:owner, require_confirm: True}, } class AgentGuard: def __init__(self, policy: dict TOOL_POLICY, timeout: float 2.0): self._policy policy self._timeout timeout def _tag_context(self, items: list[tuple[str, str]]) - list[dict]: # 给每条上下文打来源标签防止污染被当成可信事实 return [{src: src, text: txt, id: uuid.uuid4().hex[:8]} for src, txt in items] async def _check_permission(self, tool: str, actor: str, target: str) - bool: rule self._policy.get(tool) if not rule: return False # 未登记工具一律拒绝默认最小权限 # 作用域校验动作主体必须等于授权主体 if rule[scope].endswith(:owner) and actor ! target: return False return True async def _execute_tool(self, tool: str, actor: str, target: str, payload: dict) - dict: async with asyncio.timeout(self._timeout): # 严格超时防止工具挂死拖垮 Agent if not await self._check_permission(tool, actor, target): return {ok: False, reason: permission_denied} rule self._policy[tool] if rule[require_confirm]: # 危险动作需外部二次确认模型单次意图不足以落地 confirmed await self._await_human_confirm(tool, actor, target) if not confirmed: return {ok: False, reason: not_confirmed} return {ok: True, tool: tool, target: target} async def _await_human_confirm(self, tool, actor, target) - bool: # 真实环境接入确认总线此处默认超时未确认即拒绝 await asyncio.sleep(0.01) return False async def run(self, ctx_items, tool_calls): tagged self._tag_context(ctx_items) # 先标记上下文来源 results [] for call in tool_calls: try: r await self._execute_tool(call[tool], call[actor], call[target], call.get(payload, {})) except asyncio.TimeoutError: r {ok: False, reason: tool_timeout} except Exception as e: r {ok: False, reason: ferror:{e}} results.append(r) return {context: tagged, results: results}要点工具按最小必要作用域登记未登记即拒绝默认最小权限上下文打来源标签让污染可被识别与隔离危险工具需外部二次确认模型单次意图不能落地工具执行严格超时避免挂死拖垮整个 Agent所有异常都转化为结构化拒绝确保失败也安全。落地时还应把每次工具调用的权限判定与确认结果写进审计日志。当某个 Agent 频繁触发拒绝或确认说明其意图偏离授权需要回看上下文是否被污染。四、安全架构的边界代价、误判与不可控外部三道闸并非没有代价落地前要先想清几条边界否则会把 Agent 从好用变成难用或假安全。二次确认有体验代价。每封邮件、每次删除都要人点确认Agent 的自动化优势就被削弱。应分层处理低风险动作免确认高风险动作强制确认中风险按置信度动态决定。一刀切全确认用户会疲劳到点全部允许反而架空确认机制。权限过细会拖慢开发。每个工具、每个作用域都要登记策略初期成本高。折中做法是先按危险等级分三档策略再随业务细化。一开始就追求完美权限矩阵容易因成本放弃安全得不偿失。上下文标记有信息损耗。给每条内容打来源、做隔离模型可能丢失跨源推理能力影响需要综合多源信息的任务。标记应是按需隔离只在风险越阈时隔离污染源而非对所有内容一视同仁。外部工具不可控。Agent 调用的第三方 API 可能自己有漏洞或被供应链攻击。权限网关再严也管不到对方内部。缓解办法是给外部调用加额度上限、速率限制与结果校验把外部不可控性关进笼子。最后没有任何架构能防住提示词层面的社会工程。如果用户本人被诱导主动授权了危险动作三道闸也会在合法授权下放行。因此用户侧的风险提示与可撤销机制是架构之外的最后一道防线。五、总结Agent 的安全不在能力多强而在三道边界是否守得住权限要最小必要、上下文要来源可辨、工具要二次确认。三者耦合任何一环失守都会放大下一环。工程上用默认拒绝、超时降级、审计留痕把约束落到执行层而非依赖模型自觉。边界上要承认确认有体验代价、权限有维护成本、外部不可控、用户侧风险需单独防护。把三道坎变成三道闸Agent 才能真正可控。