很多团队在给 AI Agent 配权限时只有两个选项：完全访问，或者只能读取数据。前者把一次错误决策变成生产事故，后者又让 Agent 很难真正完成工作。更实用的做法是引入“分级自主权”：Agent 从低风险、低权限状态开始，根据持续的可靠表现逐步获得更多操作权限；当质量下降、风险升高或监控发现异常时，权限会自动收回。
这种模式的关键不在于给 Agent 一个永久的信任等级，而在于建立一个可以持续评估、升级和降级的控制回路。Amazon Bedrock AgentCore 可以承担 Agent 的运行边界，Amazon DynamoDB 保存信任状态和评估记录，AWS CodePipeline 则可以把权限策略、评估逻辑和部署流程纳入可审计的交付链路。
为什么“全开或全关”不够用
只给 Agent 只读权限看起来安全，但它无法完成写入工单、更新库存、触发部署或发送通知等真实工作。于是工程团队常见的结果是：Agent 能提出建议，却不能执行；或者开发者为了让流程跑通，直接绑定一组过大的 IAM 权限。
这两个极端都忽略了一个事实：Agent 的风险取决于具体操作，而不是一个抽象的“是否可信”。读取知识库、创建草稿、修改生产数据、删除资源，显然不应使用同一套权限。
可以把自主权拆成几个等级：
L0：只能读取上下文并生成建议。L1：可以创建草稿，但必须由人批准后提交。L2：可以执行低风险、可回滚的操作。L3：可以处理经过约束的生产任务，但仍受额度、时间和资源范围限制。L4：可以执行高影响操作，通常只适用于经过严格验证的场景，并需要额外的审批或隔离环境。
等级本身不是安全边界。真正的边界仍然应由 IAM、工具网关、资源范围、审批策略和运行时监控共同提供。信任等级只是决定 Agent 在这些边界内可以看到哪些工具、使用多大的操作范围。
把信任变成可计算的状态
一个可落地的设计通常需要保存三类数据：Agent 当前的信任等级、近期任务表现，以及升级或降级原因。DynamoDB 适合保存这类按 Agent 查询、按时间追加的状态数据。
评估指标不应只有“任务是否成功”，还可以包括：
- 结果是否通过业务校验。
- 是否触发人工回滚或拒绝。
- 是否调用了不必要的工具。
- 是否超出预算、数量或时间限制。
- 是否出现安全策略违规。
- 在最近一段时间内是否稳定，而不是只在一次任务中表现良好。
升级应当比降级更谨慎。例如，连续多个窗口达到阈值才升级；一次严重违规就立即降级到人工审批状态。这样可以避免 Agent 因为偶然的高分获得过大的权限，也能在风险出现时快速收敛。
下面是一个可以直接运行和改造的最小信任评估器。它使用内存字典模拟 DynamoDB，实际接入时可以把 trust_store 替换为 DynamoDB 表，并用条件更新避免并发任务覆盖状态。
from dataclasses import dataclass, asdict
from typing import Dict, List
LEVELS = ["L0", "L1", "L2", "L3", "L4"]
@dataclass
class TrustState:
agent_id: str
level: str = "L0"
reliable_windows: int = 0
last_reason: str = "initial state"
trust_store: Dict[str, TrustState] = {}
def evaluate(agent_id: str, *, success_rate: float,
policy_violations: int, human_rejections: int,
severe_incident: bool = False) -> TrustState:
state = trust_store.setdefault(agent_id, TrustState(agent_id=agent_id))
current_index = LEVELS.index(state.level)
# 严重事件立即降级，避免等待下一个评估周期。
if severe_incident or policy_violations > 0:
state.level = "L0"
state.reliable_windows = 0
state.last_reason = "security or policy incident"
return state
reliable = success_rate >= 0.98 and human_rejections == 0
if reliable:
state.reliable_windows += 1
else:
state.reliable_windows = 0
# 连续三个稳定窗口才提升一级；表现变差时降低一级。
if state.reliable_windows >= 3 and current_index < len(LEVELS) - 1:
state.level = LEVELS[current_index + 1]
state.reliable_windows = 0
state.last_reason = "three reliable evaluation windows"
elif success_rate < 0.90 or human_rejections >= 2:
state.level = LEVELS[max(0, current_index - 1)]
state.last_reason = "degraded reliability"
else:
state.last_reason = "no level change"
return state
if __name__ == "__main__":
for window in range(3):
print(asdict(evaluate(
"support-agent",
success_rate=0.99,
policy_violations=0,
human_rejections=0,
)))
print(asdict(evaluate(
"support-agent",
success_rate=0.70,
policy_violations=0,
human_rejections=2,
)))
这段代码只演示决策逻辑，生产实现还需要补充评估窗口、事件时间、操作者、模型版本和证据链接。升级结果也不应直接变成一组新的长期凭证，而应映射到短时有效、范围受限的工具授权。
让运行时权限随信任等级变化
推荐把 Agent 的工具调用放在一个可检查的边界上。AgentCore 负责运行 Agent 和工具交互时，可以在每次调用前检查当前信任等级、任务类型、资源范围和人工审批状态。
例如，权限映射可以保持简单且可审计：
trust_policy:
L0:
allowed_tools:
- search_knowledge_base
- draft_response
approval_required: true
max_write_operations: 0
L1:
allowed_tools:
- search_knowledge_base
- draft_response
- create_ticket_draft
approval_required: true
max_write_operations: 0
L2:
allowed_tools:
- search_knowledge_base
- create_ticket
- update_ticket_tags
approval_required: false
max_write_operations: 5
allowed_resources:
- "tickets:team-support"
L3:
allowed_tools:
- search_knowledge_base
- create_ticket
- update_ticket
- trigger_reversible_workflow
approval_required: false
max_write_operations: 20
allowed_resources:
- "tickets:team-support"
- "workflows:staging"
L4:
allowed_tools:
- search_knowledge_base
- create_ticket
- update_ticket
- trigger_reversible_workflow
- request_production_change
approval_required: true
max_write_operations: 20
allowed_resources:
- "tickets:team-support"
- "workflows:staging"
- "changes:approved-production"
工具网关在真正执行操作前至少要检查以下字段：agent_id、当前信任等级、任务 ID、工具名称、资源标识、操作额度和审批令牌。所有拒绝和允许的调用都应该记录下来，这些事件既是审计证据，也是下一轮信任评估的输入。
一个重要边界是：信任等级不能绕过基础安全控制。即使 Agent 处于 L4，IAM 仍应限制它能访问的账户和资源；工具实现仍应验证输入；高影响操作仍应使用幂等键、预览和回滚机制。
用 CodePipeline 管住策略变化
信任策略和评估代码会直接影响生产权限，因此不宜只在 Agent 运行时动态修改。可以把策略文件、评估器、测试数据和部署配置放入版本库，使用 AWS CodePipeline 推送到测试环境，再经过自动检查和人工审批后发布。
一个简化的 CodeBuild 配置可以这样写：
version: 0.2
phases:
install:
runtime-versions:
python: 3.11
build:
commands:
- python -m unittest discover -s tests -v
- python scripts/check_policy.py policies/trust-policy.yaml
post_build:
commands:
- aws cloudformation package --template-file infra/template.yaml --s3-bucket "$ARTIFACT_BUCKET" --output-template-file packaged.yaml
artifacts:
files:
- packaged.yaml
- policies/trust-policy.yaml
测试不只要覆盖“正常成功”的路径，还要验证：严重违规是否立即降级、并发更新是否不会丢失、权限等级变化是否会影响工具列表、旧版本策略是否可以回滚，以及 Agent 是否会在授权过期后继续执行写操作。
采用时需要保留的刹车片
分级自主权不是让 Agent 自己证明自己值得信任，而是让系统根据可验证的历史记录做出有限授权。设计时可以遵循以下检查清单：
- 从最低权限开始，逐步增加工具和资源范围。
- 升级使用多个连续评估窗口，降级支持即时触发。
- 为写入、删除、付款、部署等操作设置单独的风险等级。
- 给每次授权设置短时有效期、额度和资源白名单。
- 把人工拒绝、回滚和安全违规纳入评估指标。
- 将策略和评估器纳入 CodePipeline，并保留版本与回滚能力。
- 在 DynamoDB 中保存状态变更原因、证据和时间戳。
- 用 AgentCore 或类似运行时边界阻断未授权工具调用。
最适合先试点的场景通常是可回滚、资源范围明确、结果容易验证的内部流程，例如工单分类、测试环境变更和知识库维护。等评估指标稳定后，再扩大自主权范围。这样，Agent 的价值可以随着可靠性增长，而系统的风险也始终保持在可观测、可撤销的范围内。