Amazon Bedrock workloads are landing in production, often before security has reviewed them. Development teams connect foundation models to internal data and ship agents, and security teams find out afterward, left to ask which models are approved, whether guardrails are attached to invocations, and what gets logged.
The answer is the same prevention-first approach that already protects the rest of your cloud. Prevention works in layers: block what should never happen at the access layer, and continuously enforce the right configuration at runtime. AI workloads are no exception.
Turbot Guardrails now includes prevention objectives for AWS Bedrock, covering approved foundation models, guardrail enforcement, network isolation, and invocation logging. This post follows one of them end to end, from an objective to coverage across layers.
Require a Bedrock Guardrail on Every Invocation
Bedrock guardrails are AWS's mechanism for protecting model invocations. They apply content filters, block denied topics, redact sensitive information like PII, and defend against prompt attacks. But they only protect invocations they're attached to. Any call that omits a guardrail bypasses all of it.
The objective Enforce mandatory Bedrock guardrail on AWS Bedrock invocations closes that gap. It requires every InvokeModel and InvokeModelWithResponseStream call to carry a Bedrock guardrail. The objective is rated high: without it, prompts and responses reach the model with no protection at all.
It is one of a growing set of prevention objectives for AWS Bedrock, spanning approved foundation models, guardrail enforcement, network isolation, and invocation logging, each shipping with ready-to-use examples.
Prevention objectives for AWS Bedrock, from approved models to invocation logging
But a guardrail is only as good as what's inside it. Before requiring one on every call, make sure it is strong.
Start with a Strong Guardrail
A guardrail being attached doesn't mean it protects much. One with no content filters passes everything through, and every invocation would still technically comply. So before enforcing it everywhere, make sure it's strong.
Our production guardrail covers all six harmful-content categories at HIGH strength: hate, insults, misconduct, sexual content, violence, and prompt attacks.
The production guardrail applies all six content-filter categories at High strength
Guardrails scores each guardrail against objectives like Enforce content filters for the AWS Bedrock enforced guardrail, so a weak guardrail shows up as a gap. With a strong guardrail in hand, the job is to make every invocation use it, at both the access and runtime layers.
Recommendations for Improvement
For each objective, Guardrails shows your current posture and the steps to close the gap. For the mandatory-guardrail objective, it reads the accounts in scope and the preventions already in place, then proposes ranked ways to enforce it across layers, each with deployment steps.
Guardrails recommends how to enforce the objective, ranked across layers
The recommendation lays out two complementary approaches:
- Access layer: a Service Control Policy that denies any Bedrock invocation that doesn't carry an approved guardrail.
- Runtime layer: an account-level enforced guardrail configuration that applies your guardrail to every in-region invocation automatically.
Start at the access layer. The most direct enforcement is a Service Control Policy that denies Bedrock invocation actions unless an approved guardrail is attached. Guardrails provides this as a ready-to-use example for the objective:
Two statements work together. The first denies any invocation that has no guardrail attached at all. The second goes further: even when a guardrail is attached, it must be one of the ARNs on your approved list. Teams can't satisfy the policy by attaching an empty guardrail they created themselves. Each approved guardrail appears twice in the list, once as a bare ARN and once with a :* suffix, because AWS appends the version number to the condition value when a caller pins a published guardrail version.
Attach the policy to the organizational unit that holds your AI workload accounts, then try to invoke a model without a guardrail. AWS denies the request.
With the SCP attached, invocations without an approved guardrail are denied
Guardrails picks up the new policy automatically. Its prevention discovery reads the SCP, translates it into plain language, and matches it to the objective it satisfies.
The discovered SCP in plain language: what it covers, the approved guardrail ARNs it allows, and the objective it satisfies
Runtime Prevention
The SCP draws a hard line, but it puts the burden on every caller. Each SDK call has to attach an approved guardrail or get denied. And the SCP only reaches accounts under the OU where it's attached.
AWS provides a complementary mechanism: the account-level enforced guardrail configuration. When it's set, Bedrock applies your guardrail to every in-region model invocation on the server side, whether or not the caller attached one. Application code doesn't change.
Guardrails manages this as a policy. Set AWS > Bedrock > Enforced Guardrail Configuration > Settings to Enforce: Configured, and point it at your production guardrail ARN and published version.
Point-and-click enforcement: the policy pack binds the production guardrail and version to every Bedrock invocation in the region
The control calls Bedrock's PutEnforcedGuardrailConfiguration API and brings the account into line. From this point on it works like any other runtime prevention: if anyone modifies or deletes the enforced configuration, the control detects the drift, raises an alarm, and reapplies the setting. In our testing, a deleted configuration was back in place about 30 seconds after the tampering.
The AWS console confirms it. The region's Bedrock settings now show the enforced guardrail, applied to all models.
AWS Bedrock settings: the guardrail is now enforced for every invocation in the region
With the guardrail enforced, the objective now lists preventions across the access, config, and runtime layers, and every Bedrock invocation in the account carries an approved, strongly configured guardrail.
Coverage across layers: SCP deny statements at the access layer, and the enforced guardrail config at the config and runtime layers, with the accounts each covers
That is one objective followed end to end. The same pattern covers the rest of the Bedrock catalog, from approved models to invocation logging.
Prevention-First Security for Your Entire Stack
Preventive security for AI brings the same prevention-first approach that enterprise teams rely on for AWS, Azure, GCP, GitHub, and OCI. Block what should never happen at the access layer, enforce the right configuration at runtime, and correct drift automatically, the same defense in depth that protects the rest of your cloud. It is one part of a broader set of AI preventions launching this week.
Interested in bringing preventive security to your AI environment? Connect with us to get your free preventive security posture assessment.