Earlier than AI brokers, it was usually adequate for entry controls to deal with every motion as an unbiased occasion. Functions relied on deterministic enterprise logic to implement whether or not actions occurred in the correct order or whether or not the information was up-to-date. AI brokers behave in basically alternative ways than conventional purposes. 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 manage. One instrument name could be deemed protected when thought-about in isolation, however dangerous within the context of the previous name, resembling after studying from an untrusted knowledge supply. The query then turns into, how do you implement authorization guidelines that account for an agent\u2019s session historical past, in a manner the agent can’t circumvent?<\/p>\n
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\u2019s trajectory. As a result of these insurance policies run on the AgentCore Gateway perimeter, outdoors the agent\u2019s personal code, the agent can’t intercept or manipulate them.<\/p>\n
On this put up, you’ll study what temporal insurance policies are, how they work, and stroll by way of an instance to reveal. We’ll present you learn how to use temporal insurance policies to implement workflow sequencing, forestall knowledge fabrication between instrument calls, cap cumulative monetary publicity per session, and require human approval for high-value actions. Additionally, you will see learn how to mechanically tighten permissions when an agent operates with out human engagement. First, nevertheless, we’ll discover the wants and use instances for stateful insurance policies in additional element.<\/p>\n
Why brokers want stateful coverage enforcement<\/h2>\n
Current entry controls in AgentCore Coverage implement stateless, deterministic guidelines on every particular person request: who can name which instrument, underneath what situations. Stateless controls are obligatory however usually inadequate for brokers. Think about the next eventualities the place current stateless controls fail to catch crucial points:<\/p>\n
An agent calls a lookup_customer instrument, hallucinates a unique account quantity than what was returned, and passes it to a transfer_funds instrument that then strikes cash to the incorrect buyer\u2019s account.
\n 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.
\n An agent each approves and denies the identical insurance coverage declare inside seconds.<\/p>\n
Every particular person instrument name in these eventualities would go a stateless coverage examine. The issue solely turns into obvious while you have a look at the agent\u2019s 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, outdoors the agent\u2019s code, in order 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 widespread temporal coverage use instances embrace:<\/p>\n
Imposing output integrity throughout chained instruments. Require that an argument handed to the present instrument name precisely matches the output of a previous instrument name, stopping the agent from hallucinating or substituting values between steps.
\n Imposing tool-call ordering. Require that one instrument is named earlier than one other instrument to confirm normal working process (SOP) adherence.
\n Requiring human approval earlier than privileged actions. Block damaging or delicate instrument calls till an express human approval occasion is recorded within the trajectory.
\n Imposing knowledge freshness. Require {that a} knowledge lookup accomplished inside a given timeframe earlier than a dependent motion is permitted, stopping choices primarily based on stale data.Temporal insurance policies are authorization controls that reply the query \u201cgiven the current trajectory noticed on the AgentCore Gateway, is that this particular request approved?\u201d. They consider whether or not a gateway-routed request ought to be permitted primarily based on the present request and up to date trajectory (that’s, occasions inside a session). They don’t rework requests, name instruments, carry out evaluation, or immediately orchestrate the agent.<\/p>\n
Temporal insurance policies function on the site visitors that flows by way of AgentCore Gateway. As a result of Gateway routes an agent\u2019s Mannequin Context Protocol (MCP) instrument calls, agent-to-agent calls, and mannequin inference calls by way of a single endpoint, a temporal coverage can govern all three every time your agent points these calls by way of the gateway. This offers you one constant place to cause about an agent\u2019s habits over time, no matter which form of name the agent is making.<\/p>\n
How temporal insurance policies work<\/h2>\n
Temporal insurance policies construct on the prevailing coverage engine that\u2019s 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 prevailing AgentCore Coverage options, temporal insurance policies deny by default and forbid wins over allow.<\/p>\n
When the gateway receives a instrument name, the coverage engine:<\/p>\n
Queries the trajectory state for actions, inputs, and outputs related to the insurance policies being evaluated.
\n Evaluates every temporal coverage in opposition to the present request within the context of its historic scope (that’s, prior occasions throughout the customer-defined trajectory).
\n Returns a deterministic ALLOW or DENY determination and logs the total context of the choice.<\/p>\n
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 smart in your software, whether or not that may be a single consumer dialog, a multi-step activity, or a longer-running workflow. As a result of there might be no a couple of concurrent authorization request per session, we advocate preserving the scope of a session as slim as potential. If no header is handed, one will likely be generated in your behalf. Nevertheless, observe {that a} new session ID implies that the coverage engine will consider in opposition to a brand new, empty trajectory with no historical past.<\/p>\n
A session is rarely outlined by its ID alone. AgentCore combines the session ID with the top consumer\u2019s identification to provide a novel session, which implies two completely different identities can current the identical session ID and nonetheless be handled as having solely separate periods. Insurance policies apply independently to every trajectory, as a result of the underlying identification differs. Inside an lively session, agent trajectories carry a most look-back window of 24 hours. Any trajectory occasions older than which are mechanically deleted. One extra rule governs the connection between periods and the insurance policies themselves. Each time a change is made to the insurance policies in a coverage engine, current periods 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.<\/p>\n
Making use of temporal insurance policies to a personal banking portfolio agent<\/h2>\n
To make these ideas concrete, we\u2019ll stroll by way of how temporal insurance policies can safe a hypothetical non-public 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\u2019s behalf.<\/p>\n
On this state of affairs, the next MCP instruments are uncovered by way of the AgentCore Gateway:<\/p>\n
Instrument
\n Description<\/p>\n
get_client_profile
\n Retrieves shopper\u2019s threat tolerance, funding coverage, account restrictions, and related portfolio IDs<\/p>\n
load_portfolio
\n Retrieves a shopper\u2019s portfolio holdings and present positions<\/p>\n
get_market_price
\n Fetches present market worth for a safety<\/p>\n
execute_trade
\n Executes a purchase or promote order in opposition to a portfolio<\/p>\n
rebalance_portfolio
\n Adjusts portfolio allocations throughout holdings<\/p>\n
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’ll use Amazon Cognito for identification and go JWTs for inbound auth to the AgentCore Gateway, which hosts our agent\u2019s instruments. To study AgentCore Gateway and learn how 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 allows assist for temporal situations. As a result of Dogwood is suitable with current Cedar insurance policies, clients 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.<\/p>\n
The compliance crew requires the next temporal controls earlier than the agent reaches manufacturing:<\/p>\n
The agent should pull the shopper profile, then load the portfolio, earlier than any commerce executes.
\n The portfolio_id utilized in a commerce should precisely match the output from get_client_profile.
\n Market costs have to be retrieved inside 1 minute of a commerce execution.
\n No single session can exceed $60,000 in complete commerce worth.
\n Any particular person commerce over $25,000 requires advisor approval, one approval per commerce.
\n The agent can’t purchase after which promote the identical safety throughout the identical trajectory if it sells for a loss.
\n After quarter-hour with out advisor interplay, the agent loses entry to jot down operations.<\/p>\n
Request stream by way of gateway and coverage<\/h2>\n\n ![\"Request](\"https:\/\/d2908q01vomqb2.cloudfront.net\/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59\/2026\/08\/06\/ML-21661-1.png\")
<\/p>\nDetermine 1: Request stream by way of AgentCore Gateway and Coverage<\/p>\n<\/p><\/div>\n
This diagram demonstrates how requests to your gateway are intercepted and evaluated by Coverage in AgentCore. When the portfolio agent initiates a instrument name, the next steps happen:<\/p>\n
The request arrives on the AgentCore Gateway. The advisor is already authenticated by way of AgentCore Identification. The request carries the trajectory ID for the present session.
\n The coverage engine retrieves the trajectory\u2019s accrued state.
\n Every temporal coverage evaluates the present request in opposition to that historical past.
\n If all insurance policies allow, the request proceeds to the MCP instrument. If any coverage forbids, the request is denied and the denial is logged.
\n On profitable execution, the motion and its outcome are appended to the trajectory state for future evaluations.<\/p>\n
Implementing temporal insurance policies<\/h2>\n
In case 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 beneficial for manufacturing workloads since insurance policies will now not implement these safety guidelines.<\/p>\n
Stipulations<\/h3>\n
Earlier than implementing this answer, confirm that you’ve met the next stipulations:<\/p>\n
An lively AWS account with Amazon Bedrock AgentCore enabled.
\n An AgentCore Gateway with a minimum of one MCP goal configured.
\n A coverage engine hooked up to the gateway.
\n Applicable Identification and Entry Administration (IAM) permissions to create and handle coverage sources (see documentation).<\/p>\n
Coverage 1: Workflow sequencing (multi-hop chain)<\/h3>\n
The compliance crew requires that the agent comply with 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\u2019s threat tolerance is, or what account restrictions apply.<\/p>\n
\n allow (principal, motion == AgentCore::Motion::”FinTarget___load_portfolio”, useful resource == AgentCore::Gateway::)
\nwhen temporal {
\n previously inside 5m (AgentCore::Motion::”FinTarget___get_client_profile”::response{eventResource: useful resource})
\n};<\/p>\nallow (principal, motion == AgentCore::Motion::”FinTarget___rebalance_portfolio”, useful resource == AgentCore::Gateway::)
\nwhen temporal {
\n previously inside 5m (AgentCore::Motion::”FinTarget___load_portfolio”::response{eventResource: useful resource})
\n};\n <\/p><\/div>\n
This coverage forbids rebalance_portfolio except get_client_profile and load_portfolio have each accomplished within the appropriate 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.<\/p>\n
Trajectory state
\n Motion tried
\n Anticipated outcome<\/p>\n
Empty
\n rebalance_portfolio (portfolio_id: \u201d 8821\u201d, quantity: 15000)
\n DENY<\/p>\n
get_client_profile accomplished
\n rebalance_portfolio (portfolio_id: \u201d 8821\u201d, quantity: 15000)
\n DENY<\/p>\n
get_client_profile then load_portfolio accomplished
\n rebalance_portfolio(portfolio_id: \u201d 8821\u201d, quantity: 15000)
\n ALLOW<\/p>\n
Coverage 2: Output-to-input integrity<\/h3>\n
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.<\/p>\n
\n allow (
\n principal,
\n motion == AgentCore::Motion::”execute_trade”,
\n useful resource
\n)
\nwhen temporal {
\n previously inside 24h (
\n AgentCore::Motion::”get_client_profile”::response{
\n enter.profile_id: context.enter.profile_id,
\n eventResource: useful resource
\n }
\n )
\n};\n <\/div>\nThis coverage prevents an attacker from utilizing immediate injection to steer the agent to commerce in opposition to a unique shopper\u2019s 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.<\/p>\n
get_client_profile returned
\n execute_trade portfolio_id
\n Anticipated outcome<\/p>\n
port-8821
\n port-8821
\n ALLOW<\/p>\n
port-8821
\n port-3347
\n DENY<\/p>\n
Coverage 3: Information freshness<\/h3>\n
A get_market_price name will need to have accomplished throughout the final 30 seconds earlier than execute_trade is permitted. The agent can’t act on stale quotes.<\/p>\n
\n allow (
\n principal,
\n motion == AgentCore::Motion::”execute_trade”,
\n useful resource
\n)
\nwhen temporal {
\n previously inside 30s (
\n AgentCore::Motion::”get_market_price”::response{eventResource: useful resource}
\n )
\n};\n <\/div>\nIn unstable markets, even a 60-second-old quote can symbolize important worth drift. This coverage forces the agent to refresh its market knowledge earlier than each commerce, making certain that choices are primarily based on present data.<\/p>\n
Time since get_market_price
\n Motion
\n Anticipated outcome<\/p>\n
4 seconds in the past
\n BUY Inventory A
\n ALLOW<\/p>\n
2 minutes in the past
\n BUY Inventory A
\n DENY<\/p>\n
By no means referred to as
\n BUY Inventory A
\n DENY<\/p>\n
Coverage 4: Cumulative price range cap per trajectory<\/h3>\n
Complete commerce worth in a single coverage session (or trajectory) can’t exceed $60,000. This accommodates blast radius from runaway brokers or profitable assaults.<\/p>\n
\n allow (
\n principal,
\n motion == AgentCore::Motion::”execute_trade”,
\n useful resource
\n)
\nwhen temporal {
\n exists (complete: Lengthy). ((sum quantity for (quantity: Lengthy), (t: Timepoint). the place (previously inside 24h (
\n AgentCore::Motion::”get_market_price”::request{enter.value: quantity, eventResource: useful resource} && tp(t)))) == complete && complete < 60000
\n )
\n};\n <\/div>\nA compromised agent executing dozens of small trades that individually look positive can nonetheless accumulate catastrophic publicity. After $60,000, all trades are denied till a brand new trajectory begins.<\/p>\n
Prior cumulative trades
\n Present commerce quantity
\n Complete
\n Anticipated outcome<\/p>\n
$0
\n $15,000
\n $15,000
\n Permit<\/p>\n
$15,000
\n $22,000
\n $37,000
\n Permit<\/p>\n
$37,000
\n $30,000
\n $67,000
\n DENY<\/p>\n
Coverage 5: Human approval for big trades (one-time consumption)<\/h3>\n
Any commerce exceeding $25,000 requires the advisor\u2019s express approval. Every approval is consumed by a single commerce. A second massive commerce requires a recent approval.<\/p>\n
\n allow (
\n principal,
\n motion == AgentCore::Motion::”execute_trade”,
\n useful resource
\n)
\nwhen {
\n context.enter.value < 25000 || temporal {
\n !(
\n AgentCore::Motion::”execute_trade”::response{eventResource: useful resource}
\n )
\n since inside 24h (
\n AgentCore::Motion::”approve_trade”::response{ enter.standing: “authorised”, eventResource: useful resource}
\n )
\n }
\n};\n <\/div>\nThis prevents the agent from decoding a single approval as blanket permission for a number of massive trades. Every approval covers precisely one execution.<\/p>\n
Commerce quantity
\n Approval in trajectory
\n Anticipated outcome<\/p>\n
$15,000
\n None
\n Permit (under threshold)<\/p>\n
$30,000
\n None
\n DENY<\/p>\n
$30,000
\n Authorized (unconsumed)
\n ALLOW<\/p>\n
$30,000 (second commerce)
\n Solely prior approval (consumed)
\n DENY<\/p>\n
Coverage 6: Mutual exclusion<\/h3>\n
The agent can’t purchase after which promote the identical safety throughout the identical trajectory if it sells for a loss.<\/p>\n
\n allow (
\n principal,
\n motion == AgentCore::Motion::”execute_sell”,
\n useful resource
\n)
\nexcept {
\n context.enter.revenue < 0 && temporal {
\n previously inside 24h (
\n AgentCore::Motion::”execute_buy”{
\n stock_symbol: context.enter.stock_symbol, eventResource: useful resource}
\n )
\n }
\n}
\n};\n <\/div>\nIf 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 incorrect and the session ought to be reviewed.<\/p>\n
Prior motion
\n Present motion
\n Time hole
\n Anticipated outcome<\/p>\n
SELL Inventory A
\n BUY Inventory A
\n 2 min
\n DENY<\/p>\n
SELL Inventory A
\n BUY Inventory A
\n 7 min
\n ALLOW<\/p>\n
SELL Inventory A
\n BUY Inventory B
\n 2 min
\n ALLOW (completely different safety)<\/p>\n
Coverage 7: Progressive belief decay<\/h3>\n
After quarter-hour with out advisor interplay, the agent loses entry to jot down operations (execute_trade, rebalance_portfolio). The advisor can re-engage at any time to revive full entry.<\/p>\n
\n allow (
\n principal,
\n motion in [
\n AgentCore::Action::”execute_trade”,
\n AgentCore::Action::”rebalance_portfolio”
\n ],
\n useful resource == AgentCore::Gateway::””
\n)
\nexcept temporal {
\n previously inside 15m AgentCore::Motion::”interact_advisor”::response{eventResource: useful resource}
\n};\n <\/div>\nIf the advisor walks away, the agent naturally converges towards read-only habits. This ensures that prolonged autonomous operation doesn’t accumulate unchecked threat.<\/p>\n
Time since final advisor interplay
\n Motion tried
\n Anticipated outcome<\/p>\n
3 minutes
\n execute_trade
\n ALLOW<\/p>\n
20 minutes
\n execute_trade
\n DENY<\/p>\n
20 minutes
\n get_market_price
\n ALLOW (read-only)<\/p>\n
Price issues<\/h2>\n
You solely pay for the authorization requests carried out throughout agent execution. Every time an agent calls a instrument by way of 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).<\/p>\n
Clear up<\/h2>\n
To keep away from ongoing expenses, 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 accommodates insurance policies or stays hooked up to a gateway. In case you created the gateway, its MCP goal solely for this walkthrough, delete these as properly. Be aware that deleting or altering insurance policies invalidates any lively coverage periods, so carry out cleanup solely after your check periods are full.<\/p>\n
Listing and delete the insurance policies on the coverage engine. Repeat the delete-policy command for every of the seven insurance policies:<\/p>\n
\n aws bedrock-agentcore-control list-policies $
\n –policy-engine-id <\/p>\naws bedrock-agentcore-control delete-policy $
\n –policy-engine-id $
\n –policy-id\n <\/p><\/div>\n
Detach the coverage engine from the gateway by updating the gateway and not using a coverage engine configuration:<\/p>\n
\n aws bedrock-agentcore-control create-gateway $
\n –name my-gateway $
\n –role-arn arn:aws:iam::123456789012:position\/my-gateway-service-role $
\n –protocol-type MCP $
\n –authorizer-type CUSTOM_JWT $
\n –authorizer-configuration ‘{
\n “customJWTAuthorizer”: {
\n “discoveryUrl”: “https:\/\/cognito-idp.us-west-2.amazonaws.com\/some-user-pool\/.well-known\/openid-configuration”,
\n “allowedClients”: [“clientId”]
\n }
\n }’\n <\/div>\nDelete the coverage engine:<\/p>\n
\n aws bedrock-agentcore-control delete-policy-engine $
\n –policy-engine-id\n <\/div>\n(Non-obligatory) Delete the gateway goal and gateway in the event you created them for this walkthrough:<\/p>\n
<\/p>\nDetermine 1: Request stream by way of AgentCore Gateway and Coverage<\/p>\n<\/p><\/div>\n
This diagram demonstrates how requests to your gateway are intercepted and evaluated by Coverage in AgentCore. When the portfolio agent initiates a instrument name, the next steps happen:<\/p>\n
The request arrives on the AgentCore Gateway. The advisor is already authenticated by way of AgentCore Identification. The request carries the trajectory ID for the present session.
\n The coverage engine retrieves the trajectory\u2019s accrued state.
\n Every temporal coverage evaluates the present request in opposition to that historical past.
\n If all insurance policies allow, the request proceeds to the MCP instrument. If any coverage forbids, the request is denied and the denial is logged.
\n On profitable execution, the motion and its outcome are appended to the trajectory state for future evaluations.<\/p>\n
Implementing temporal insurance policies<\/h2>\n
In case 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 beneficial for manufacturing workloads since insurance policies will now not implement these safety guidelines.<\/p>\n
Stipulations<\/h3>\n
Earlier than implementing this answer, confirm that you’ve met the next stipulations:<\/p>\n
An lively AWS account with Amazon Bedrock AgentCore enabled.
\n An AgentCore Gateway with a minimum of one MCP goal configured.
\n A coverage engine hooked up to the gateway.
\n Applicable Identification and Entry Administration (IAM) permissions to create and handle coverage sources (see documentation).<\/p>\n
Coverage 1: Workflow sequencing (multi-hop chain)<\/h3>\n
The compliance crew requires that the agent comply with 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\u2019s threat tolerance is, or what account restrictions apply.<\/p>\n
\nwhen temporal {
\n previously inside 5m (AgentCore::Motion::”FinTarget___get_client_profile”::response{eventResource: useful resource})
\n};<\/p>\n
allow (principal, motion == AgentCore::Motion::”FinTarget___rebalance_portfolio”, useful resource == AgentCore::Gateway::)
\nwhen temporal {
\n previously inside 5m (AgentCore::Motion::”FinTarget___load_portfolio”::response{eventResource: useful resource})
\n};\n <\/p><\/div>\n
This coverage forbids rebalance_portfolio except get_client_profile and load_portfolio have each accomplished within the appropriate 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.<\/p>\n
Trajectory state
\n Motion tried
\n Anticipated outcome<\/p>\n
Empty
\n rebalance_portfolio (portfolio_id: \u201d 8821\u201d, quantity: 15000)
\n DENY<\/p>\n
get_client_profile accomplished
\n rebalance_portfolio (portfolio_id: \u201d 8821\u201d, quantity: 15000)
\n DENY<\/p>\n
get_client_profile then load_portfolio accomplished
\n rebalance_portfolio(portfolio_id: \u201d 8821\u201d, quantity: 15000)
\n ALLOW<\/p>\n
Coverage 2: Output-to-input integrity<\/h3>\n
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.<\/p>\n
\n principal,
\n motion == AgentCore::Motion::”execute_trade”,
\n useful resource
\n)
\nwhen temporal {
\n previously inside 24h (
\n AgentCore::Motion::”get_client_profile”::response{
\n enter.profile_id: context.enter.profile_id,
\n eventResource: useful resource
\n }
\n )
\n};\n <\/div>\n
This coverage prevents an attacker from utilizing immediate injection to steer the agent to commerce in opposition to a unique shopper\u2019s 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.<\/p>\n
get_client_profile returned
\n execute_trade portfolio_id
\n Anticipated outcome<\/p>\n
port-8821
\n port-8821
\n ALLOW<\/p>\n
port-8821
\n port-3347
\n DENY<\/p>\n
Coverage 3: Information freshness<\/h3>\n
A get_market_price name will need to have accomplished throughout the final 30 seconds earlier than execute_trade is permitted. The agent can’t act on stale quotes.<\/p>\n
\n principal,
\n motion == AgentCore::Motion::”execute_trade”,
\n useful resource
\n)
\nwhen temporal {
\n previously inside 30s (
\n AgentCore::Motion::”get_market_price”::response{eventResource: useful resource}
\n )
\n};\n <\/div>\n
In unstable markets, even a 60-second-old quote can symbolize important worth drift. This coverage forces the agent to refresh its market knowledge earlier than each commerce, making certain that choices are primarily based on present data.<\/p>\n
Time since get_market_price
\n Motion
\n Anticipated outcome<\/p>\n
4 seconds in the past
\n BUY Inventory A
\n ALLOW<\/p>\n
2 minutes in the past
\n BUY Inventory A
\n DENY<\/p>\n
By no means referred to as
\n BUY Inventory A
\n DENY<\/p>\n
Coverage 4: Cumulative price range cap per trajectory<\/h3>\n
Complete commerce worth in a single coverage session (or trajectory) can’t exceed $60,000. This accommodates blast radius from runaway brokers or profitable assaults.<\/p>\n
\n principal,
\n motion == AgentCore::Motion::”execute_trade”,
\n useful resource
\n)
\nwhen temporal {
\n exists (complete: Lengthy). ((sum quantity for (quantity: Lengthy), (t: Timepoint). the place (previously inside 24h (
\n AgentCore::Motion::”get_market_price”::request{enter.value: quantity, eventResource: useful resource} && tp(t)))) == complete && complete < 60000
\n )
\n};\n <\/div>\n
A compromised agent executing dozens of small trades that individually look positive can nonetheless accumulate catastrophic publicity. After $60,000, all trades are denied till a brand new trajectory begins.<\/p>\n
Prior cumulative trades
\n Present commerce quantity
\n Complete
\n Anticipated outcome<\/p>\n
$0
\n $15,000
\n $15,000
\n Permit<\/p>\n
$15,000
\n $22,000
\n $37,000
\n Permit<\/p>\n
$37,000
\n $30,000
\n $67,000
\n DENY<\/p>\n
Coverage 5: Human approval for big trades (one-time consumption)<\/h3>\n
Any commerce exceeding $25,000 requires the advisor\u2019s express approval. Every approval is consumed by a single commerce. A second massive commerce requires a recent approval.<\/p>\n
\n principal,
\n motion == AgentCore::Motion::”execute_trade”,
\n useful resource
\n)
\nwhen {
\n context.enter.value < 25000 || temporal {
\n !(
\n AgentCore::Motion::”execute_trade”::response{eventResource: useful resource}
\n )
\n since inside 24h (
\n AgentCore::Motion::”approve_trade”::response{ enter.standing: “authorised”, eventResource: useful resource}
\n )
\n }
\n};\n <\/div>\n
This prevents the agent from decoding a single approval as blanket permission for a number of massive trades. Every approval covers precisely one execution.<\/p>\n
Commerce quantity
\n Approval in trajectory
\n Anticipated outcome<\/p>\n
$15,000
\n None
\n Permit (under threshold)<\/p>\n
$30,000
\n None
\n DENY<\/p>\n
$30,000
\n Authorized (unconsumed)
\n ALLOW<\/p>\n
$30,000 (second commerce)
\n Solely prior approval (consumed)
\n DENY<\/p>\n
Coverage 6: Mutual exclusion<\/h3>\n
The agent can’t purchase after which promote the identical safety throughout the identical trajectory if it sells for a loss.<\/p>\n
\n principal,
\n motion == AgentCore::Motion::”execute_sell”,
\n useful resource
\n)
\nexcept {
\n context.enter.revenue < 0 && temporal {
\n previously inside 24h (
\n AgentCore::Motion::”execute_buy”{
\n stock_symbol: context.enter.stock_symbol, eventResource: useful resource}
\n )
\n }
\n}
\n};\n <\/div>\n
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 incorrect and the session ought to be reviewed.<\/p>\n
Prior motion
\n Present motion
\n Time hole
\n Anticipated outcome<\/p>\n
SELL Inventory A
\n BUY Inventory A
\n 2 min
\n DENY<\/p>\n
SELL Inventory A
\n BUY Inventory A
\n 7 min
\n ALLOW<\/p>\n
SELL Inventory A
\n BUY Inventory B
\n 2 min
\n ALLOW (completely different safety)<\/p>\n
Coverage 7: Progressive belief decay<\/h3>\n
After quarter-hour with out advisor interplay, the agent loses entry to jot down operations (execute_trade, rebalance_portfolio). The advisor can re-engage at any time to revive full entry.<\/p>\n
\n principal,
\n motion in [
\n AgentCore::Action::”execute_trade”,
\n AgentCore::Action::”rebalance_portfolio”
\n ],
\n useful resource == AgentCore::Gateway::””
\n)
\nexcept temporal {
\n previously inside 15m AgentCore::Motion::”interact_advisor”::response{eventResource: useful resource}
\n};\n <\/div>\n
If the advisor walks away, the agent naturally converges towards read-only habits. This ensures that prolonged autonomous operation doesn’t accumulate unchecked threat.<\/p>\n
Time since final advisor interplay
\n Motion tried
\n Anticipated outcome<\/p>\n
3 minutes
\n execute_trade
\n ALLOW<\/p>\n
20 minutes
\n execute_trade
\n DENY<\/p>\n
20 minutes
\n get_market_price
\n ALLOW (read-only)<\/p>\n
Price issues<\/h2>\n
You solely pay for the authorization requests carried out throughout agent execution. Every time an agent calls a instrument by way of 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).<\/p>\n
Clear up<\/h2>\n
To keep away from ongoing expenses, 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 accommodates insurance policies or stays hooked up to a gateway. In case you created the gateway, its MCP goal solely for this walkthrough, delete these as properly. Be aware that deleting or altering insurance policies invalidates any lively coverage periods, so carry out cleanup solely after your check periods are full.<\/p>\n
Listing and delete the insurance policies on the coverage engine. Repeat the delete-policy command for every of the seven insurance policies:<\/p>\n
\n –policy-engine-id <\/p>\n
aws bedrock-agentcore-control delete-policy $
\n –policy-engine-id $
\n –policy-id\n <\/p><\/div>\n
Detach the coverage engine from the gateway by updating the gateway and not using a coverage engine configuration:<\/p>\n
\n –name my-gateway $
\n –role-arn arn:aws:iam::123456789012:position\/my-gateway-service-role $
\n –protocol-type MCP $
\n –authorizer-type CUSTOM_JWT $
\n –authorizer-configuration ‘{
\n “customJWTAuthorizer”: {
\n “discoveryUrl”: “https:\/\/cognito-idp.us-west-2.amazonaws.com\/some-user-pool\/.well-known\/openid-configuration”,
\n “allowedClients”: [“clientId”]
\n }
\n }’\n <\/div>\n
Delete the coverage engine:<\/p>\n
\n –policy-engine-id\n <\/div>\n
(Non-obligatory) Delete the gateway goal and gateway in the event you created them for this walkthrough:<\/p>\n
![\"Sean](\"https:\/\/d2908q01vomqb2.cloudfront.net\/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59\/2026\/08\/06\/ML-21661-2.png\")
<\/p>\n<\/p><\/div>\n![\"Philipp](\"https:\/\/d2908q01vomqb2.cloudfront.net\/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59\/2026\/08\/06\/ML-21661-3.jpg\")
<\/p>\n<\/p><\/div>\n![\"Nicholas](\"https:\/\/d2908q01vomqb2.cloudfront.net\/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59\/2026\/08\/06\/ML-21661-4.jpg\")
<\/p>\n<\/p><\/div>\n