Runtime Guardrails for AI Agents: Inside SentinelOne's Integration with Amazon Bedrock AgentCore

When agents start genuinely acting in enterprise production, calling tools, touching data, and talking to each other, the security team's first question is usually not how smart the agent is but who it is and what it is allowed to do. SentinelOne announced it will integrate its Prompt Security offering with Amazon Bedrock AgentCore to deliver runtime guardrails for AI agents: detection signals feed AgentCore's policy engine, which enforces deterministic controls at the gateway, outside the agent's reasoning loop. Meanwhile, a VentureBeat survey delivers a stark number: 62% of organizations with production agents still share credentials. Here is the architecture and a practical checklist you can put to work before your next agent ships.

Guardrails must sit outside the reasoning loop, not inside it

The governance gap: who is your agent, really?

The fundamental difference between agents and traditional software is that agents decide and call tools on their own. That turns identity and authorization from an IT concept into a first-order security problem: without a distinct identity, an agent's actions cannot be attributed, constrained, or audited. The VentureBeat survey reveals the scale of the gap. Among organizations running agents in production, 62% share credentials wholly or partly, and only 38% give every agent its own identity. Notably, the same survey finds demand is already widespread: 69% of organizations plan to adopt agent security within twelve months, whether or not they already use per-agent identity. The need is clear; implementation lags.

# 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",
}

Runtime guardrails vs. build-time scanning

Traditional security scanning happens at build time: commits, dependency installs, image builds. But most agent risk occurs at runtime: an injected prompt, an over-broad tool call, a response that carries sensitive data past a boundary, none of which a scanner sees. That is the role of runtime guardrails: they do not assume the agent is always right, but place a checkpoint on every critical interaction path. The division of labor between SentinelOne and AgentCore is clean. SentinelOne provides the seeing: detection signals covering prompt injection, PII exposure, tool-use validation, LLM response monitoring, and data leakage prevention. AgentCore provides the doing: a policy engine that makes deterministic decisions at the gateway based on those signals. Together they make running agents observable and controllable.

# 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"

Every tool call is subject to policy enforcement

How the AgentCore policy engine enforces controls

Per AWS, Amazon Bedrock AgentCore is the platform to build, connect, and optimize agents at scale, and its policy engine enforces real-time, deterministic controls at the gateway across three traffic classes: agent-to-tool, agent-to-LLM, and agent-to-agent. The crucial detail is where enforcement happens, outside the agent's reasoning loop. That means whether or not an agent is injected, or wants to route around policy, it cannot reason its way past a gateway that sits outside its loop. It is a deliberate design choice: place the security boundary beyond the model's control rather than trusting the model to police itself.

# 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.

What SentinelOne's Prompt Security detects

SentinelOne's Prompt Security supplies detection signals across five directions: prompt injection detection (inputs attempting to hijack agent behavior), PII exposure (whether sensitive personal data leaves the boundary), tool-use validation (whether a call is over-scoped or anomalous), LLM response monitoring (whether outputs drift from policy), and data leakage prevention (whether sensitive data is heading out). These signals are not the end point; they are inputs to the policy engine, letting the gateway decide allow, review, or block. Decoupling detection from enforcement means detection can keep improving while the enforcement point stays stable and auditable.

# 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.

Credentials: 62% still share, 38% give each agent its own identity

A practical checklist for agent identity and least privilege

Distilled into something executable, the checklist is five lines. First, identity: give every agent its own identity rather than shared credentials. Second, scope: grant least-privilege tool scopes per task, not per team. Third, budget: cap tokens and tool calls per agent and per window. Fourth, audit: log all agent-to-tool, agent-to-LLM, and agent-to-agent traffic. Fifth, enforce: evaluate policy outside the agent's reasoning loop. Compressed further into three Monday moves: inventory what each agent can actually reach, replace shared service accounts with per-agent identities, and put a policy check in front of every tool call, then revisit the list every quarter as agents and their tools change.

# 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.

Why guardrails are not a post-launch feature

Many teams treat security as a post-launch optimization, but for agents that is an error of ordering. What sets agents apart is that their behavioral boundary is not hard-coded but inferred by a model at runtime; their permissions often span multiple systems; and they may take irreversible actions, like paying or deleting data, with no human present. In such a system, ship-then-harden leaves irreversible exposure in production. Doing guardrails properly is often the precondition for a regulated team to launch at all. In other words, runtime guardrails are not a tax on agent capability but the ticket for agents to be allowed into critical business. That is why, with credential sharing still at 62%, identity and policy governance will be the core agent topic of the year ahead. The teams that treat identity, least privilege, and gateway-level enforcement as launch-blocking requirements will be the ones able to put agents on the paths that actually matter, while everyone else is still negotiating with their security review board.