Friday, August 7, 2026

Securing AI brokers with temporal insurance policies in Amazon Bedrock AgentCore


Earlier than AI brokers, it was usually enough for entry controls to deal with every motion as an impartial occasion. Functions relied on deterministic enterprise logic to implement whether or not actions occurred in the appropriate order or whether or not the info was up-to-date. AI brokers behave in basically alternative ways than conventional functions. They determine at runtime which instruments to name, with which arguments, and in what order. That flexibility, mixed with more and more clever fashions, makes brokers equal measures succesful and difficult to regulate. One device name may be deemed secure when thought-about in isolation, however dangerous within the context of the previous name, equivalent to after studying from an untrusted knowledge supply. The query then turns into, how do you implement authorization guidelines that account for an agent’s session historical past, in a means the agent can’t circumvent?

Temporal insurance policies in Amazon Bedrock AgentCore allow you to outline stateful guidelines that decide authorization to AgentCore Gateway targets by evaluating the present request within the context of prior occasions in an agent’s trajectory. As a result of these insurance policies run on the AgentCore Gateway perimeter, exterior the agent’s personal code, the agent can’t intercept or manipulate them.

On this put up, you’ll study what temporal insurance policies are, how they work, and stroll by an instance to display. We’ll present you easy methods to use temporal insurance policies to implement workflow sequencing, forestall knowledge fabrication between device calls, cap cumulative monetary publicity per session, and require human approval for high-value actions. Additionally, you will see easy methods to routinely tighten permissions when an agent operates with out human engagement. First, nevertheless, we are going to discover the wants and use circumstances for stateful insurance policies in additional element.

Why brokers want stateful coverage enforcement

Present entry controls in AgentCore Coverage implement stateless, deterministic guidelines on every particular person request: who can name which device, below what situations. Stateless controls are mandatory however usually inadequate for brokers. Take into account the next eventualities the place current stateless controls fail to catch important points:

  • An agent calls a lookup_customer device, hallucinates a unique account quantity than what was returned, and passes it to a transfer_funds device that then strikes cash to the fallacious buyer’s account.
  • A runaway agent executes dozens of trades in a loop as a result of nothing tracks that cumulative publicity has already exceeded the chance restrict.
  • An agent each approves and denies the identical insurance coverage declare inside seconds.

Every particular person device name in these eventualities would move a stateless coverage test. The issue solely turns into obvious once you have a look at the agent’s trajectory, the ordered sequence of actions in a session. Temporal insurance policies lengthen Coverage in AgentCore with this trajectory-aware enforcement layer. Temporal insurance policies run on the gateway, exterior the agent’s code, so that they can’t be bypassed no matter what the agent does, how it’s prompted, or what bugs exist within the agent code. Some frequent temporal coverage use circumstances embody:

  • Imposing output integrity throughout chained instruments. Require that an argument handed to the present device name precisely matches the output of a previous device name, stopping the agent from hallucinating or substituting values between steps.
  • Imposing tool-call ordering. Require that one device known as earlier than one other device to confirm customary working process (SOP) adherence.
  • Requiring human approval earlier than privileged actions. Block harmful or delicate device calls till an specific human approval occasion is recorded within the trajectory.
  • Imposing knowledge freshness. Require {that a} knowledge lookup accomplished inside a given timeframe earlier than a dependent motion is allowed, stopping selections primarily based on stale info.Temporal insurance policies are authorization controls that reply the query “given the latest trajectory noticed on the AgentCore Gateway, is that this particular request licensed?”. They consider whether or not a gateway-routed request ought to be permitted primarily based on the present request and latest trajectory (that’s, occasions inside a session). They don’t rework requests, name instruments, carry out evaluation, or straight orchestrate the agent.

Temporal insurance policies function on the site visitors that flows by AgentCore Gateway. As a result of Gateway routes an agent’s Mannequin Context Protocol (MCP) device calls, agent-to-agent calls, and mannequin inference calls by a single endpoint, a temporal coverage can govern all three at any time when your agent points these calls by the gateway. This offers you one constant place to purpose about an agent’s conduct over time, no matter which sort of name the agent is making.

How temporal insurance policies work

Temporal insurance policies construct on the present coverage engine that’s already used for stateless entry management. They introduce the idea of agent trajectories, that are bounded sequences of actions recognized by a principal and session ID. Brokers by no means see the coverage logic, by no means contact the state retailer, and can’t alter the controls. As with the present AgentCore Coverage options, temporal insurance policies deny by default and forbid wins over allow.

When the gateway receives a device name, the coverage engine:

  1. Queries the trajectory state for actions, inputs, and outputs related to the insurance policies being evaluated.
  2. Evaluates every temporal coverage in opposition to the present request within the context of its historic scope (that’s, prior occasions inside the customer-defined trajectory).
  3. Returns a deterministic ALLOW or DENY determination and logs the complete context of the choice.

Each request {that a} temporal coverage evaluates should carry an x-amzn-bedrock-agentcore-policy-session-id header, which identifies the session the request belongs to. You determine what constitutes the start and finish of a session. The boundary can replicate no matter unit of labor is sensible on your utility, whether or not that may be a single person dialog, a multi-step activity, or a longer-running workflow. As a result of there may be no multiple concurrent authorization request per session, we advocate preserving the scope of a session as slim as attainable. If no header is handed, one can be generated in your behalf. Nonetheless, notice {that a} new session ID implies that the coverage engine will consider in opposition to a brand new, empty trajectory with no historical past.

A session isn’t outlined by its ID alone. AgentCore combines the session ID with the tip person’s identification to supply a singular session, which implies two completely different identities can current the identical session ID and nonetheless be handled as having solely separate classes. Insurance policies apply independently to every trajectory, as a result of the underlying identification differs. Inside an energetic session, agent trajectories carry a most look-back window of 24 hours. Any trajectory occasions older than which can be routinely deleted. One extra rule governs the connection between classes and the insurance policies themselves. Every time a change is made to the insurance policies in a coverage engine, current classes are invalidated. This makes certain that every session is evaluated in opposition to the present set of insurance policies and every related trajectory occasion is recorded with the anticipated schema.

Making use of temporal insurance policies to a non-public banking portfolio agent

To make these ideas concrete, we’ll stroll by how temporal insurance policies can safe a hypothetical personal banking agent. The agent helps wealth advisors at a monetary providers agency handle shopper portfolios. It retrieves shopper profiles, hundreds portfolio holdings, fetches real-time market costs, performs evaluation, and executes trades on the advisor’s behalf.

On this situation, the next MCP instruments are uncovered by the AgentCore Gateway:

Software Description
get_client_profile Retrieves shopper’s threat tolerance, funding coverage, account restrictions, and related portfolio IDs
load_portfolio Retrieves a shopper’s portfolio holdings and present positions
get_market_price Fetches present market worth for a safety
execute_trade Executes a purchase or promote order in opposition to a portfolio
rebalance_portfolio Adjusts portfolio allocations throughout holdings

There are three completely different advisor roles: junior advisors (restricted commerce authority), senior advisors (full commerce authority), and compliance officers (read-only monitoring entry). On this instance, we are going to use Amazon Cognito for identification and move JWTs for inbound auth to the AgentCore Gateway, which hosts our agent’s instruments. To find out about AgentCore Gateway and easy methods to arrange auth with Gateway, learn the AgentCore Gateway Documentation. Temporal insurance policies use Dogwood, a brand new open-source governance language designed for brokers and their instruments. Dogwood helps evaluating current Cedar insurance policies and permits help for temporal situations. As a result of Dogwood is appropriate with current Cedar insurance policies, prospects can proceed to make use of their present Cedar insurance policies without having emigrate. For added element on Dogwood and its semantics, you may learn the language documentation or this weblog put up.

The compliance crew requires the next temporal controls earlier than the agent reaches manufacturing:

  1. The agent should pull the shopper profile, then load the portfolio, earlier than any commerce executes.
  2. The portfolio_id utilized in a commerce should precisely match the output from get_client_profile.
  3. Market costs should be retrieved inside 1 minute of a commerce execution.
  4. No single session can exceed $60,000 in complete commerce worth.
  5. Any particular person commerce over $25,000 requires advisor approval, one approval per commerce.
  6. The agent can’t purchase after which promote the identical safety inside the similar trajectory if it sells for a loss.
  7. After quarter-hour with out advisor interplay, the agent loses entry to put in writing operations.

Request stream by gateway and coverage


Determine 1: Request stream by AgentCore Gateway and Coverage

This diagram demonstrates how requests to your gateway are intercepted and evaluated by Coverage in AgentCore. When the portfolio agent initiates a device name, the next steps happen:

  1. The request arrives on the AgentCore Gateway. The advisor is already authenticated by AgentCore Id. The request carries the trajectory ID for the present session.
  2. The coverage engine retrieves the trajectory’s amassed state.
  3. Every temporal coverage evaluates the present request in opposition to that historical past.
  4. If all insurance policies allow, the request proceeds to the MCP device. If any coverage forbids, the request is denied and the denial is logged.
  5. On profitable execution, the motion and its consequence are appended to the trajectory state for future evaluations.

Implementing temporal insurance policies

When you have an current coverage engine in ENFORCE mode, you may both replace its enforcement mode to LOG_ONLY, or you may change the enforcement mode of the person insurance policies. Switching current insurance policies or coverage engines to LOG_ONLY mode isn’t advisable for manufacturing workloads since insurance policies will now not implement these safety guidelines.

Conditions

Earlier than implementing this answer, confirm that you’ve got met the next conditions:

  • An energetic AWS account with Amazon Bedrock AgentCore enabled.
  • An AgentCore Gateway with not less than one MCP goal configured.
  • A coverage engine hooked up to the gateway.
  • Applicable Id and Entry Administration (IAM) permissions to create and handle coverage sources (see documentation).

Coverage 1: Workflow sequencing (multi-hop chain)

The compliance crew requires that the agent observe get_client_profile, then load_portfolio, then rebalance_portfolio in sequence. With out the shopper profile, the agent has no system-verified context about which portfolios belong to this shopper, what the shopper’s threat tolerance is, or what account restrictions apply.

allow (principal, motion == AgentCore::Motion::"FinTarget___load_portfolio", useful resource == AgentCore::Gateway::)
when temporal {
    previously inside 5m (AgentCore::Motion::"FinTarget___get_client_profile"::response{eventResource: useful resource})
};

allow (principal, motion == AgentCore::Motion::"FinTarget___rebalance_portfolio", useful resource == AgentCore::Gateway::)
when temporal {
    previously inside 5m (AgentCore::Motion::"FinTarget___load_portfolio"::response{eventResource: useful resource})
};

This coverage forbids rebalance_portfolio until get_client_profile and load_portfolio have each accomplished within the right order inside this trajectory. An agent that skips the load profile step and jumps on to rebalancing is denied no matter what directions it obtained.

Trajectory state Motion tried Anticipated consequence
Empty rebalance_portfolio (portfolio_id: ” 8821”, quantity: 15000) DENY
get_client_profile accomplished rebalance_portfolio (portfolio_id: ” 8821”, quantity: 15000) DENY
get_client_profile then load_portfolio accomplished rebalance_portfolio(portfolio_id: ” 8821”, quantity: 15000) ALLOW

Coverage 2: Output-to-input integrity

The portfolio_id handed to execute_trade should precisely match one of many portfolio IDs returned by get_client_profile. The agent can’t fabricate or substitute a unique portfolio ID.

allow (
    principal,
    motion == AgentCore::Motion::"execute_trade",
    useful resource
)
when temporal {
    previously inside 24h (
        AgentCore::Motion::"get_client_profile"::response{
            enter.profile_id: context.enter.profile_id,
            eventResource: useful resource
        }
    )
};

This coverage prevents an attacker from utilizing immediate injection to steer the agent to commerce in opposition to a unique shopper’s portfolio. The attacker can persuade the LLM to make use of a fabricated ID, however the coverage verifies the worth in opposition to what the CRM system really returned.

get_client_profile returned execute_trade portfolio_id Anticipated consequence
port-8821 port-8821 ALLOW
port-8821 port-3347 DENY

Coverage 3: Information freshness

A get_market_price name should have accomplished inside the final 30 seconds earlier than execute_trade is allowed. The agent can’t act on stale quotes.

allow (
    principal,
    motion == AgentCore::Motion::"execute_trade",
    useful resource
)
when temporal {
    previously inside 30s (
        AgentCore::Motion::"get_market_price"::response{eventResource: useful resource}
    )
};

In risky markets, even a 60-second-old quote can characterize vital worth drift. This coverage forces the agent to refresh its market knowledge earlier than each commerce, guaranteeing that selections are primarily based on present info.

Time since get_market_price Motion Anticipated consequence
4 seconds in the past BUY Inventory A ALLOW
2 minutes in the past BUY Inventory A DENY
By no means known as BUY Inventory A DENY

Coverage 4: Cumulative finances cap per trajectory

Whole commerce worth in a single coverage session (or trajectory) can’t exceed $60,000. This incorporates blast radius from runaway brokers or profitable assaults.

allow (
    principal,
    motion == AgentCore::Motion::"execute_trade",
    useful resource
)
when temporal {
    exists (complete: Lengthy). ((sum quantity for (quantity: Lengthy), (t: Timepoint). the place (previously inside 24h (
        AgentCore::Motion::"get_market_price"::request{enter.price: quantity, eventResource: useful resource} && tp(t)))) == complete && complete < 60000
    )
};

A compromised agent executing dozens of small trades that individually look wonderful can nonetheless accumulate catastrophic publicity. After $60,000, all trades are denied till a brand new trajectory begins.

Prior cumulative trades Present commerce quantity Whole Anticipated consequence
$0 $15,000 $15,000 Permit
$15,000 $22,000 $37,000 Permit
$37,000 $30,000 $67,000 DENY

Coverage 5: Human approval for big trades (one-time consumption)

Any commerce exceeding $25,000 requires the advisor’s specific approval. Every approval is consumed by a single commerce. A second massive commerce requires a recent approval.

allow (
    principal,
    motion == AgentCore::Motion::"execute_trade",
    useful resource
)
when {
    context.enter.price < 25000 || temporal {
        !(
            AgentCore::Motion::"execute_trade"::response{eventResource: useful resource}
        )
        since inside 24h (
            AgentCore::Motion::"approve_trade"::response{ enter.standing: "permitted", eventResource: useful resource}
        )
    }
};

This prevents the agent from deciphering a single approval as blanket permission for a number of massive trades. Every approval covers precisely one execution.

Commerce quantity Approval in trajectory Anticipated consequence
$15,000 None Permit (beneath threshold)
$30,000 None DENY
$30,000 Accredited (unconsumed) ALLOW
$30,000 (second commerce) Solely prior approval (consumed) DENY

Coverage 6: Mutual exclusion

The agent can’t purchase after which promote the identical safety inside the similar trajectory if it sells for a loss.

allow (
    principal,
    motion == AgentCore::Motion::"execute_sell",
    useful resource
)
until {
    context.enter.revenue < 0 && temporal {
        previously inside 24h (
            AgentCore::Motion::"execute_buy"{
                stock_symbol: context.enter.stock_symbol, eventResource: useful resource}
        )
    }
}
};

If the agent bought AAPL two minutes in the past and now tries to purchase AAPL, the request is denied. The contradiction itself is the sign that one thing has gone fallacious and the session ought to be reviewed.

Prior motion Present motion Time hole Anticipated consequence
SELL Inventory A BUY Inventory A 2 min DENY
SELL Inventory A BUY Inventory A 7 min ALLOW
SELL Inventory A BUY Inventory B 2 min ALLOW (completely different safety)

Coverage 7: Progressive belief decay

After quarter-hour with out advisor interplay, the agent loses entry to put in writing operations (execute_trade, rebalance_portfolio). The advisor can re-engage at any time to revive full entry.

allow (
    principal,
    motion in [
        AgentCore::Action::"execute_trade",
        AgentCore::Action::"rebalance_portfolio"
    ],
    useful resource == AgentCore::Gateway::""
)
until temporal {
    previously inside 15m AgentCore::Motion::"interact_advisor"::response{eventResource: useful resource}
};

If the advisor walks away, the agent naturally converges towards read-only conduct. This ensures that prolonged autonomous operation doesn’t accumulate unchecked threat.

Time since final advisor interplay Motion tried Anticipated consequence
3 minutes execute_trade ALLOW
20 minutes execute_trade DENY
20 minutes get_market_price ALLOW (read-only)

Price issues

You solely pay for the authorization requests carried out throughout agent execution. Every time an agent calls a device by AgentCore Gateway, Coverage checks the motion in opposition to your guidelines to find out whether or not it’s allowed or denied. Your first 100 temporal insurance policies per coverage engine are included within the current per-authorization-request worth (see the AgentCore pricing web page for particulars).

Clear up

To keep away from ongoing fees, take away the sources you created on this walkthrough. Delete the sources so as: first delete the temporal insurance policies from the coverage engine, then detach the coverage engine from the gateway, after which delete the coverage engine itself. A coverage engine can’t be deleted whereas it nonetheless incorporates insurance policies or stays hooked up to a gateway. For those who created the gateway, its MCP goal solely for this walkthrough, delete these as nicely. Notice that deleting or altering insurance policies invalidates any energetic coverage classes, so carry out cleanup solely after your check classes are full.

Checklist and delete the insurance policies on the coverage engine. Repeat the delete-policy command for every of the seven insurance policies:

aws bedrock-agentcore-control list-policies $
  --policy-engine-id 

aws bedrock-agentcore-control delete-policy $
  --policy-engine-id  $
  --policy-id 

Detach the coverage engine from the gateway by updating the gateway with no coverage engine configuration:

aws bedrock-agentcore-control create-gateway $
  --name my-gateway $
  --role-arn arn:aws:iam::123456789012:function/my-gateway-service-role $
  --protocol-type MCP $
  --authorizer-type CUSTOM_JWT $
  --authorizer-configuration '{
    "customJWTAuthorizer": {
      "discoveryUrl": "https://cognito-idp.us-west-2.amazonaws.com/some-user-pool/.well-known/openid-configuration",
      "allowedClients": ["clientId"]
    }
  }'

Delete the coverage engine:

aws bedrock-agentcore-control delete-policy-engine $
  --policy-engine-id 

(Non-obligatory) Delete the gateway goal and gateway should you created them for this walkthrough:

aws bedrock-agentcore-control delete-gateway-target $
  --gateway-identifier  $
  --target-id 

aws bedrock-agentcore-control delete-gateway $
  --gateway-identifier 

Conclusion

On this put up, you realized how temporal insurance policies carry stateful, trajectory-aware authorization to agentic AI methods. You utilized seven coverage patterns to a hypothetical personal banking portfolio agent. These patterns coated workflow sequencing, output-to-input integrity, knowledge freshness, cumulative finances caps, human-in-the-loop approvals, mutual exclusion, and progressive belief decay. These patterns generalize throughout domains the place brokers work together with delicate instruments at runtime. As a result of enforcement occurs on the AgentCore Gateway perimeter, exterior the agent’s personal reasoning loop, these protections stay tamper-proof no matter mannequin conduct. This offers you a declarative, auditable approach to implement operational boundaries with out constraining the flexibleness that makes brokers helpful. To get began, evaluation the AgentCore documentation.


In regards to the authors

Sean Eichenberger

Sean Eichenberger

Sean is a Principal Product Supervisor at AWS Agentic AI. He leads initiatives throughout agent governance, security, and connectivity for Amazon Bedrock AgentCore.

Philipp Trucksaess

Philipp Trucksaess

Philipp Trucksaess is a Senior Software program Growth Engineer at AWS, the place he builds primitives for agentic functions. He focuses on distributed methods applied in Rust, and enjoys offering prospects with deterministic controls for his or her stochastic methods.

Nicholas Gordon

Nicholas Gordon

Nick is a Principal Engineer at AWS. Throughout his 10 years at AWS, Nick has labored on Amazon Bedrock and Amazon DynamoDB constructing massive scale distributed methods. He’s presently centered on infrastructure for AI.

Related Articles

Latest Articles