test(base): 验证最后一种工具拒绝(角色不符),四种分支全部实测通过
分支 4 是最难构造的一种,两个前提缺一不可:
1. **工具的角色集合必须比 Agent 的更窄**。Agent 层的 validate_access(base.py:101)会先按
AgentDefinition.allowed_roles 拦截,两者一致时永远进不到工具层的角色校验。所以把
probe_alt 收窄为 ("risk_operator",),而 Agent 仍允许 admin。
2. **调用者必须有工具要求的权限**,否则会先命中权限分支。所以脚本临时给 admin 授
probe:read,验证后撤销。
过程中又修掉一处自己写错的地方:探针的 handle 原先硬编码调用 PROBE_TOOL,导致分支 4
(需要调 probe_alt)与分支 2(需要调白名单之外的那一个)互相干扰——第一次跑出来的结果
是"工具不在当前意图白名单"。改为按消息里的 "alt" 选择要调的工具。
四种分支的实测结果,message 各自独立、指向不同处置动作:
- 白名单为空 → 该意图未配置工具白名单
- 工具不在白名单 → 工具不在当前意图白名单
- 缺少工具权限 → 缺少工具权限
- 角色不符 → 角色不能使用工具
目标的另一半也验证了:审计里是完整细节(reason = "角色 ['admin'] 与工具允许的角色
['risk_operator'] 无交集",并带 tool_name / intent / trace_id),而异常 message 只有
"角色不能使用工具"、不含角色集合。**内部配置只进审计,不进客户可见响应。**
环境复原:生效配置 9 条(与起点一致);sys_permission / sys_role_permission 中
probe:read 的行数为 0。
This commit is contained in:
@@ -189,13 +189,18 @@ def get_agent_factory() -> AgentFactory:
|
||||
required_permission=PROBE_PERMISSION,
|
||||
allowed_roles=("admin",),
|
||||
))
|
||||
# 第二个探针工具:让"有白名单但不含该工具"的分支可被构造(见 platform_probe 的说明)
|
||||
# 第二个探针工具,两个用途:
|
||||
# ① 让"有白名单但不含该工具"的分支可被构造(见 platform_probe 的说明);
|
||||
# ② 让**工具层**的"角色不能使用工具"分支可被构造 —— 它的角色集合**比 Agent 的更窄**
|
||||
# (Agent 允许 admin,本工具只允许 risk_operator)。必须更窄才行:Agent 层的
|
||||
# validate_access 会先按 AgentDefinition.allowed_roles 拦截,两者一致时永远进不到
|
||||
# 工具层的角色校验。
|
||||
registry.register(ToolDefinition(
|
||||
name=PROBE_ALT_TOOL,
|
||||
input_model=ProbeEchoArgs,
|
||||
handler=cast(Any, probe_alt_tool),
|
||||
required_permission=PROBE_PERMISSION,
|
||||
allowed_roles=("admin",),
|
||||
allowed_roles=("risk_operator",),
|
||||
))
|
||||
registry.register(ToolDefinition(
|
||||
name="check_suitability",
|
||||
|
||||
Reference in New Issue
Block a user