AI Agent 的运行时护栏：拆解 SentinelOne 与 Amazon Bedrock AgentCore 的集成

当 Agent 开始在企业生产环境里真正「动手」——调用工具、访问数据、彼此通信——安全团队的第一个问题往往不是「它多聪明」，而是「它到底是谁、被允许做什么」。SentinelOne 宣布将把其 Prompt Security 能力与 Amazon Bedrock AgentCore 集成，为 AI Agent 提供运行时护栏：检测信号汇入 AgentCore 的策略引擎，在网关层、Agent 推理回路之外执行确定性控制。与此同时，VentureBeat 的调研给出一个刺眼的数字：在生产环境部署 Agent 的组织中，62% 仍在全部或部分共享凭证。本文拆解这套架构，并给出一份可落地的清单。

护栏必须站在推理回路之外，而不是之内

治理缺口：你的 Agent 到底是谁？

Agent 与传统软件的根本差别，在于它会自主做决定、自主调用工具。这让「身份与授权」从 IT 概念变成了安全的第一性问题：如果没有独立身份，一个 Agent 的行为就无法被归因、无法被限制、更无法被审计。VentureBeat 的调研揭示了这个缺口的规模——在生产环境运行 Agent 的组织里，62% 全部或部分共享凭证，只有 38% 给每个 Agent 配了独立身份。而值得注意的是，调研同时显示：有计划在 12 个月内引入 Agent 安全能力的两组组织（无论是否已用独立身份），其比例都高达 69%，说明需求已经普遍存在，只是落地滞后。

# The integration at a glance. Facts are from SentinelOne's press
# release and the AWS AgentCore product documentation.

INTEGRATION = {
    "vendor": "SentinelOne",
    "capability": "Prompt Security",
    "platform": "Amazon Bedrock AgentCore",
    "goal": "runtime guardrails for AI agents",
    "initial_step": "2026-06 (gateway guardrails)",
    "expansion": "full governance layer",
}

运行时护栏 vs. 建设期扫描

传统安全扫描发生在「建设期」：代码提交、依赖安装、镜像构建。但 Agent 的风险大多发生在「运行时」——一次被注入的提示、一次越权的工具调用、一次把敏感数据带出边界的响应，都不在扫描器的视野里。这正是「运行时护栏」的定位：它不假设 Agent 永远正确，而是在每一次关键交互的路径上设卡。SentinelOne 与 AgentCore 的分工很清晰——SentinelOne 负责「看见」：提供提示注入检测、PII 暴露、工具调用校验、LLM 响应监控与数据外泄防护等检测信号；AgentCore 负责「执行」：由策略引擎在网关层依据信号做出确定性决策。二者合起来，构成对运行中 Agent 的可观测与可控制。

# AgentCore's policy engine is the enforcement point. It watches
# all agent traffic and applies deterministic controls at the gateway.

TRAFFIC = [
    "agent-to-tool",
    "agent-to-LLM",
    "agent-to-agent",
]

def enforce(signal):
    # Detection signals come from SentinelOne; AgentCore acts on them
    # OUTSIDE the agent's reasoning loop.
    if signal.verdict == "block":
        return "deny_at_gateway"
    if signal.verdict == "review":
        return "escalate_to_human"
    return "allow"

每个工具调用都要经过策略校验

AgentCore 策略引擎如何执行控制

据 AWS 的产品说明，Amazon Bedrock AgentCore 是用于大规模构建、连接与优化 Agent 的平台；其策略引擎会在网关上对三类流量执行实时的、确定性的控制：Agent 到工具（agent-to-tool）、Agent 到模型（agent-to-LLM）、以及 Agent 到 Agent（agent-to-agent）。关键在于执行位置——控制发生在 Agent 的推理回路之外。这意味着无论 Agent 是否被注入、是否「想」绕过策略，它都无法用自己的推理去说服一道站在回路之外的网关。这是一种刻意的设计选择：把安全边界放在模型控制力之外，而不是寄望于模型自我约束。

# What Prompt Security detects and feeds into the policy engine.

DETECTIONS = [
    "prompt injection detection",
    "PII exposure",
    "tool-use validation",
    "LLM response monitoring",
    "data leakage prevention",
]

# The design principle: enforcement lives at the gateway, so a
# compromised or confused agent cannot argue its way past policy.

Prompt Security 检测什么

SentinelOne 的 Prompt Security 提供的检测信号覆盖五个方向：提示注入检测（识别试图劫持 Agent 行为的输入）、PII 暴露（敏感个人信息是否被带出）、工具调用校验（该调用是否越权或异常）、LLM 响应监控（模型输出是否偏离策略）、以及数据外泄防护（是否有敏感数据流向外部）。这些信号本身不是终点，而是策略引擎的输入——它们让网关能够做出「允许、复核、阻断」的判断。这种把「检测」与「执行」解耦的架构，意味着检测能力可以持续升级，而执行点保持稳定、可审计。

# A practical least-privilege checklist for production agents,
# grounded in the survey finding that most orgs still share creds.

CHECKLIST = {
    "identity": "give every agent its own identity, not shared creds",
    "scope": "grant least-privilege tool scopes per task, not per team",
    "budget": "cap tokens and tool calls per agent and per window",
    "audit": "log agent-to-tool, agent-to-LLM, agent-to-agent traffic",
    "enforce": "evaluate policy outside the agent's reasoning loop",
}

# Survey context: among orgs with agents in production, 62% share
# credentials wholly or partly; 38% give every agent its own identity.

凭证管理：62% 组织仍在共享，38% 为每个 Agent 配独立身份

一份可落地的 Agent 安全清单

把上面的原则收敛成可执行的清单，大致是五条：其一，身份——给每个 Agent 独立身份，而不是共享凭证；其二，作用域——按任务授予最小权限的工具范围，而不是按团队粗放授权；其三，预算——为每个 Agent 及其时间窗口设定 token 与工具调用的上限；其四，审计——记录 Agent 到工具、到模型、到 Agent 的全部流量；其五，执行——把策略评估放在 Agent 推理回路之外。若要再压缩成「周一开工三件事」：盘点每个 Agent 真实能触达的工具与权限、用独立身份替换共享服务账号、并把策略校验放到每一次工具调用之前。

# Where to start on Monday: three concrete moves.

WEEK_ONE = [
    "inventory every agent and the tools/scopes it can actually reach",
    "replace shared service accounts with per-agent identities",
    "put a policy check in front of every tool call, at the gateway",
]

# Guardrails are not a feature you bolt on after launch; they are the
# reason a regulated team can launch at all.

为什么护栏不是「上线后再补」的功能

很多团队把安全当作上线后的优化项，但对 Agent 而言，这是次序上的错误。Agent 与传统功能的不同在于：它的行为边界不是写死的，而是由模型在运行时推断的；它的权限往往横跨多个系统；它可能在没有人类在场时执行不可逆操作，比如付款或删数据。在这样的系统里，「先上线、后加固」意味着把不可逆的风险敞口留在生产环境里。相反，把护栏做扎实，往往是受监管团队能够「合法上线」的前提。换句话说，运行时护栏不是限制 Agent 能力的成本，而是让 Agent 被允许进入关键业务的前提条件。这也是为什么，在凭证共享率仍高达 62% 的当下，身份与策略治理会成为接下来一年 Agent 落地的核心议题。