Deploying AI brokers safely in regulated industries is difficult. With out correct boundaries, brokers that entry delicate information or execute transactions can pose vital safety dangers. Not like conventional software program, an AI agent chooses actions to realize a objective by invoking instruments, accessing information, and adapting its reasoning utilizing information from its atmosphere and customers. This autonomy is exactly what makes brokers so highly effective and what makes safety a non-negotiable concern.
A helpful psychological mannequin for agent security is to isolate the agent from the skin world. To do that, consider partitions round an agent that defines what the agent can entry, what it could work together with, and what results it could have on the skin world. With no well-defined wall, an agent that may ship emails, question databases, execute code, or set off monetary transactions is dangerous. These capabilities can result in information exfiltration, unintended entry to code or infrastructure, or immediate injection assaults. How will you implement AI security reliably, at scale, with out slowing down innovation? Coverage in Amazon Bedrock AgentCore offers you a principled approach to implement these boundaries at runtime, at scale.
On this publish, we use a healthcare appointment scheduling agent to grasp how Coverage in Amazon Bedrock AgentCore creates a deterministic enforcement layer that operates independently of the agent’s personal reasoning. Healthcare is a pure match for this exploration. Brokers working on this area should deal with delicate affected person information, respect strict entry boundaries, and implement enterprise guidelines persistently. This requires deterministic coverage enforcement to keep up the security of affected person information and safe runtime operations. The complete pattern is out there on GitHub at amazon-bedrock-agentcore-samples.
You’ll discover ways to flip pure language descriptions of your online business guidelines into Cedar insurance policies, then use these insurance policies to implement fine-grained, identity-aware controls in order that brokers solely entry the instruments and information that their customers are licensed to make use of. Additionally, you will see methods to apply Coverage by AgentCore Gateway, intercepting and evaluating each agent-to-tool request at runtime.
The lacking layer: Why brokers want exterior coverage enforcement
Securing AI brokers is tougher than securing conventional software program. The issues that make brokers highly effective, equivalent to open-ended reasoning, versatile device use, and adaptableness to new conditions, additionally create unpredictable behaviors which are a lot tougher to securely management. Brokers depend on giant language mannequin (LLM) inference, which might hallucinate and has no built-in laborious separation between trusted directions and incidental textual content. This makes brokers susceptible to immediate injection and associated adversarial assaults that exploit these LLM weaknesses to override safeguards and subvert meant conduct. These dangers are sometimes managed by constraining the agent in code. This works, however it carries delicate prices. The agent’s conduct is now solely as protected because the correctness of that wrapper code, which is now an implicit safety boundary. Reasoning about whether or not the coverage is full requires cautious code overview throughout a probably giant code base. When a safety staff must audit whether or not the suitable guidelines are in place, they’re studying software code relatively than a transparent, auditable coverage definition. Coverage in Amazon Bedrock AgentCore takes a unique strategy: transfer the coverage completely outdoors the agent. Now the coverage is enforced earlier than the device invocation by the agent by AgentCore Gateway. Thus, coverage is enforced no matter what the agent does, no matter how the agent is prompted or manipulated, and no matter what bugs exist within the agent code itself. With this separation, you may give attention to functionality with out treating each line of tool-calling code as a possible safety boundary.
Cedar: Language for deterministic coverage enforcement
Not like embedding guidelines in agent code, exterior coverage enforcement supplies auditable safety boundaries and separates functionality improvement from safety issues. To make this sort of deterministic exterior enforcement sensible, you want a coverage language that’s each machine-efficient and human-auditable. Cedar, utilized by Coverage in Amazon Bedrock AgentCore, supplies this lacking layer by turning safety intent into exact, analyzable insurance policies.
Cedar is the authorization language utilized in AgentCore Coverage as a result of it was designed to be each a sensible authorization language and a goal for automated mathematical evaluation. Every coverage specifies a principal (who), motion (what), and useful resource (the place), with situations within the when clause. The next instance reveals methods to allow solely Alice to view the holiday picture:
allow( principal == Consumer::"alice", motion == Motion::"view", useful resource == Photograph::"VacationPhoto94.jpg");Along with attributes on principals, sources, and actions, you need to use Cedar to go a context object whose attributes (for instance, readOnly) might be referenced in insurance policies to situation choices on runtime info. This following instance reveals the way you would possibly create a coverage that enables the person alice to carry out a readOnly motion:
allow( principal == PhotoFlash::Consumer::"alice", motion, useful resource) when { context has readOnly && context.readOnly == true };Cedar’s semantics together with default deny, forbid wins over allow and order-independent analysis, make it easy to purpose about insurance policies compositionally. Analysis latency can also be minimal due to the restricted loop-free construction. Cedar insurance policies do not need unintended effects like file system entry, system calls, or networking. So, they are often safely evaluated with out sandboxing, even when written by untrusted authors.
Coverage in Amazon Bedrock AgentCore
Constructing on the necessity for deterministic, exterior enforcement, Coverage in Amazon Bedrock AgentCore supplies the concrete mechanism that evaluates each agent-to-tool request towards explicitly outlined Cedar insurance policies. A coverage engine is a group of insurance policies expressed in Cedar. To make coverage authoring accessible, insurance policies might be created in two methods: authored straight as Cedar for fine-grained programmatic management or generated from plain English statements which are mechanically formalized into Cedar. Ranging from pure language, the service generates syntactically right Cedar code, validates it towards the gateway schema, and analyzes it to floor overly permissive, overly restrictive, or in any other case problematic insurance policies earlier than they’re enforced. After outlined, Coverage in AgentCore intercepts agent site visitors by Amazon Bedrock AgentCore Gateways, evaluating each agent-to-tool request towards the insurance policies within the coverage engine earlier than granting or denying device entry.
Making use of coverage to a healthcare appointment scheduling agent
To make these ideas concrete, let’s stroll by how Coverage in Amazon Bedrock AgentCore might be utilized to a healthcare appointment scheduling agent. That is an AI system that helps inquire about present immunization standing/schedule, checks appointment slots, and books appointments. We wish to safe the AI system utilizing Coverage to assist forestall unauthorized entry to affected person information, inadvertent publicity of protected well being info (PHI), or a affected person canceling one other affected person’s appointment.
Coverage in Amazon Bedrock AgentCore has a default-deny posture and forbid wins over allow default-deny posture and forbid mechanically wins over allow. Along with these ideas, we present how insurance policies might be composed from a small set of readable, auditable Cedar guidelines to enhance the security of the AI agent in manufacturing.
Getting began
To do this instance your self, begin by cloning the Amazon Bedrock AgentCore samples repository and navigating to the healthcare appointment agent folder:
From there, comply with the setup and deployment directions within the README for this listing to configure your AWS atmosphere, deploy the pattern stack, and invoke the agent end-to-end.
Conditions
To make use of Coverage in Amazon Bedrock AgentCore together with your agentic software, confirm that you’ve got met the next conditions:
- An energetic AWS account
- Affirmation of the AWS Areas the place Coverage in AgentCore is obtainable
- Acceptable IAM permissions to create, check, and fasten coverage engine to your AgentCore Gateway. (Notice: The IAM coverage must be fine-grained and restricted to mandatory sources utilizing correct ARN patterns for manufacturing utilization):
[ { "Sid": "PolicyEngineManagement", "Effect": "Allow", "Action": [ "bedrock-agentcore:CreatePolicyEngine", "bedrock-agentcore:UpdatePolicyEngine", "bedrock-agentcore:GetPolicyEngine", "bedrock-agentcore:DeletePolicyEngine", "bedrock-agentcore:ListPolicyEngines" ], "Useful resource": "arn:aws:bedrock-agentcore:${aws:area}:${aws:accountId}:policy-engine/*" }, { "Sid": "CedarPolicyManagement", "Impact": "Permit", "Motion": [ "bedrock-agentcore:CreatePolicy", "bedrock-agentcore:GetPolicy", "bedrock-agentcore:ListPolicies", "bedrock-agentcore:UpdatePolicy", "bedrock-agentcore:DeletePolicy" ], "Useful resource": "arn:aws:bedrock-agentcore:${aws:area}:${aws:accountId}:policy-engine/*/coverage/*" }, { "Sid": "NaturalLanguagePolicyGeneration", "Impact": "Permit", "Motion": [ "bedrock-agentcore:StartPolicyGeneration", "bedrock-agentcore:GetPolicyGeneration", "bedrock-agentcore:ListPolicyGenerations", "bedrock-agentcore:ListPolicyGenerationAssets" ], "Useful resource": "arn:aws:bedrock-agentcore:${aws:area}:${aws:accountId}:policy-engine/*/policy-generation/*" }, { "Sid": "AttachPolicyEngineToGateway", "Impact": "Permit", "Motion": [ "bedrock-agentcore:UpdateGateway", "bedrock-agentcore:GetGateway", "bedrock-agentcore:ManageResourceScopedPolicy", "bedrock-agentcore:ManageAdminPolicy" ], "Useful resource": "arn:aws:bedrock-agentcore:${aws:area}:${aws:accountId}:gateway/*" }]Exchange
Coverage implementation steps
- To get began, first create a coverage engine that may maintain the required insurance policies that we are going to create for the healthcare appointment scheduling agent.
- There are three completely different choices to writer insurance policies. You may generate Cedar statements from guidelines expressed in pure language, use a form-based strategy to Cedar coverage creation, or straight present the Cedar assertion. Within the subsequent part, we are going to take a look at some examples which cowl these authoring choices.
- Lastly, the coverage engine might be related to a Gateway. This may be performed within the
LOG_ONLYmode to validate how insurance policies work to your agent with out disrupting manufacturing site visitors. That is performed by observing the conduct recorded within the observability logs. When you’re assured that the agent has the anticipated conduct, you may affiliate the coverage engine with the gateway within the implement mode.
The healthcare appointment agent has the next instruments:
getPatient: GET /get_patient_emr— Get a affected person report by the required question parameterpatient_id(string).searchImmunization: POST /search_immunization_emr— Search immunization information with required parametersearch_value(string; affected person ID).bookAppointment: POST /book_appointment— E book an appointment by offeringdate_string(string; “YYYY-MM-DD HH:MM”).getSlots: GET /get_available_slots— Get obtainable slots by required question parameterdate_string(string; “YYYY-MM-DD”).
Now let’s writer some insurance policies for this agent to safe how the agent accesses these instruments!
Id-based insurance policies
A elementary rule in a healthcare agent is that sufferers ought to solely be capable to act on their very own information. We wish to create a coverage that allows a affected person to learn their very own affected person/immunization information. For every device, you may state that the device parameter (patient_id within the case of the getPatient device, search_value within the case of searchImmunization device) should match the authenticated ID of the person. Within the following picture, we present you how one can writer these insurance policies through the use of statements in pure language and producing the corresponding Cedar insurance policies.
Learn vs. write separation
A typical sample in healthcare methods is to permit broad learn entry whereas tightly proscribing write operations. An instance coverage for this agent can be to make reads attainable just for an authenticated person with an appropriate scope (for instance, fhir:learn) and preserve the writes individually managed. Within the following picture, you may see how the form-based coverage creation works. You may select the impact, principal, useful resource, motion and supply the situations to create a coverage. The picture reveals the creation of a coverage to permit customers to entry instruments within the healthcare software’s gateway solely when the principal incorporates fhir:learn within the principal scope.
Like this coverage for scoped learn entry, now you can use a scope appointment:write within the scope of the principal to manage write entry.
Threat controls on scheduling
Past entry management, Coverage can implement enterprise guidelines or harmful patterns that assist forestall abuse. By utilizing specific forbids to laborious‑cease harmful enter patterns to instruments, you may safe your software even when the agent is compromised. For instance, allow us to create a coverage to dam exhibiting appointment slots outdoors of restricted hours.Within the following picture, you may see that the pure language assertion “Permit customers to get slots solely between 9 am and 9 pm UTC” is transformed to the Cedar coverage.
Now you can construct extra insurance policies to your use case and create a coherent coverage set coherent to ascertain a whole safety posture. The Coverage engine analysis mannequin is default-deny: if no allow coverage matches a request, it’s blocked. Use broad allow guidelines for widespread, low-risk operations. Add focused forbid guidelines for high-risk instruments, delicate information boundaries, and identified abuse vectors. This layered strategy helps you create a coverage set that’s each readable by a safety auditor and enforceable at runtime unbiased of what the agent’s LLM reasoning produces. Right here, the agent doesn’t have to “know” these guidelines. It doesn’t should be prompted to respect them, fine-tuned to comply with them, or trusted to use them accurately beneath adversarial situations. Coverage in Amazon Bedrock AgentCore enforces them on the gateway, earlier than device name execution, no matter how the agent arrived at its resolution.
Testing coverage enforcement
Allow us to now perceive the conduct of the insurance policies now we have created and related to the gateway for the healthcare appointment scheduling agent. The next two check circumstances reveal the identity-scoped entry coverage in motion when the agent invokes the getPatient device on behalf of a person. In each circumstances, the authenticated person is affected person adult-patient-001.The Cedar coverage being examined is the affected person read-only entry rule. This rule permits the getPatient device name solely when the `patient_id` within the request matches the authenticated person’s identification:
allow( principal, motion == AgentCore::Motion::"Target1___getPatient", useful resource == AgentCore::Gateway::"{gateway_arn}") when { principal.hasTag("position") && principal.getTag("position") == "affected person" && context.enter has patient_id && principal.hasTag("patient_id") && context.enter.patient_id == principal.getTag("patient_id")};Check 1a — ALLOW: Affected person accessing their very own report**
The agent sends a instruments/name request to the gateway to invoke getPatient with the device parameter for patient_id set to adult-patient-001. As a result of the patient_id within the device enter matches the authenticated person’s patient_id declare, the Cedar coverage permits the request:
Immediate: “Get my affected person info for affected person ID adult-patient-001”
Coverage resolution: ALLOW
End result: Affected person report returned efficiently
Check 1b — DENY: Affected person accessing one other affected person’s report
Now the agent sends the identical instruments/name request for getPatient, with patient_id set to pediatric-patient-001. The Cedar coverage compares the device enter towards the authenticated person’s patient_id declare, finds a mismatch, and denies the request as a result of there’s no matching allow coverage.
Immediate: “Get affected person info for affected person ID pediatric-patient-001”
Coverage resolution: DENY
End result: Instrument execution denied by coverage enforcement
The identical agent code, the identical mannequin, and the identical device are utilized in each circumstances. The one distinction is the coverage analysis on the gateway boundary. The device is protected against the denied request as a result of the gateway intercepts it earlier than execution.The next instance demonstrates a unique enforcement sample: a forbid rule that blocks scheduling operations outdoors of permitted hours. The earlier Threat Controls on Scheduling part used pure language to generate a allow rule that enables slot entry in the course of the 9 AM–9 PM window. The identical constraint might be expressed as a forbid that explicitly blocks requests outdoors that window. Each approaches produce the identical enforcement consequence; we use the forbid type as an example how Cedar’s “forbid all the time wins” semantics can hard-stop harmful patterns:
forbid( principal, motion == AgentCore::Motion::"Target1___getSlots", useful resource == AgentCore::Gateway::"{gateway_arn}") when context.time.hour > 21);Check 2a — ALLOW: Requesting slots throughout permitted hours
The agent requests obtainable slots for a date throughout clinic hours (e.g., 2 PM UTC). This coverage’s when clause doesn’t match as a result of the request hour falls throughout the 9–21 vary, so the request proceeds to the corresponding allow coverage and succeeds.
Immediate: “Present me obtainable appointment slots for 2025-08-15” (requested at 14:00 UTC)
Coverage resolution: ALLOW
End result: Obtainable slots returned for the requested date
Check 2b — DENY: Requesting slots outdoors permitted hours
The agent makes the identical request, however at 3 AM UTC. The forbid rule matches as a result of the request hour is lower than 9, and since forbid wins over allow in Cedar, the request is blocked whatever the different allow insurance policies.
Immediate: “Present me obtainable appointment slots for 2025-08-15” (requested at 03:00 UTC)
Coverage resolution: DENY
End result: Instrument execution denied by coverage enforcement
Collectively, these check circumstances illustrate each enforcement patterns: allow with identity-scoped situations and forbid with time-based restrictions. That is what makes exterior coverage enforcement deterministic. The end result depends upon the coverage definition and the request context, not on the agent’s reasoning.
Clear up sources
To keep away from ongoing fees, delete the Amazon Bedrock AgentCore insurance policies, take away check brokers, and clear up any related sources utilizing the offered CDK destroy instructions and the coverage cleanup script. To run the cleanup script:
python coverage/setup_policy.py --cleanupConclusion
AI brokers are solely as reliable because the boundaries that include them. These boundaries should be enforced deterministically. Coverage in Amazon Bedrock AgentCore offers you a principled approach to outline these boundaries and implement them on the gateway layer on each agent-to-tool request. These insurance policies are enforced independently of the agent’s reasoning and are auditable by anybody in your safety staff. For enterprises deploying brokers in regulated industries, this separation between functionality and enforcement is the inspiration that makes production-grade agentic methods attainable. Within the subsequent publish on this sequence, we’ll dive into the important thing variations between Lambda interceptors and Coverage in AgentCore Gateway, and stroll by architectural patterns for utilizing every individually and collectively, to construct sturdy ruled agentic purposes.
Subsequent steps
Prepared so as to add deterministic coverage enforcement to your individual brokers? These sources will get you up and operating rapidly:
- The Coverage Developer Information covers Cedar coverage authoring, pure language to Cedar formalization, AWS KMS encryption, and CDK constructs for infrastructure as code (IaC) deployments.
- The AgentCore Getting Began workshop walks you thru constructing and securing an agent end-to-end, together with integrating Coverage with AgentCore Gateway.
Have questions on implementing these insurance policies in your particular use case? Share your ideas within the feedback on this publish or join with the neighborhood within the AWS boards.
Acknowledgement
Particular due to everybody who contributed to the launch: groups lead by Pushpinder Dua, Raja Kapur, Sean Eichenberger, Jean-Baptiste Tristan, Sandesh Swamy, Maira Ladeira Tanke, Tanvi Girinath and Amanda Lester.
Concerning the authors
