Do I still need IAM if I deploy DeepInspect in front of Bedrock?

Yes. IAM continues to govern which infrastructure component, DeepInspect's proxy included, is permitted to call Bedrock's API at all. DeepInspect adds a request-level decision layer on top of that coarse-grained authorization; it does not replace IAM's role in securing the AWS account.

Can Bedrock Guardrails detect a caller sending data they are not authorized to share?

No. Guardrails evaluates content against configured filters (denied topics, PII patterns, harmful categories) regardless of who sent the prompt. It has no concept of "this specific user's role prohibits sharing this specific data classification." That evaluation requires identity context Guardrails was not designed to receive.

Does PrivateLink protect against a compromised application credential?

PrivateLink protects the network path the traffic takes, not the legitimacy of the traffic itself. A request made with a compromised or over-permissioned credential travels over the same private, encrypted path as a legitimate one. PrivateLink and identity-aware request authorization solve different problems and are not substitutes for each other.

What is the difference between Guardrails and a policy enforcement layer like DeepInspect?

Guardrails runs inside or alongside the model inference call and evaluates content: is this text harmful, does it match a denied topic, does it contain PII. A policy enforcement layer evaluates the request itself, before it reaches the model: is this authenticated caller, with this role, permitted to send this data to this model under the organization's current policy. The two operate at different points in the request path and answer different questions.

Does model invocation logging give me the identity-aware audit trail I need for a compliance review?

Not on its own. Bedrock's model invocation logging records the IAM ARN that made the call, which is typically a shared application role, not the end user the role was acting for. A compliance review that asks "which specific person authorized this AI decision" needs a record bound to that person's identity, which requires the calling application, or an enforcement layer in front of Bedrock, to supply and verify that context.

AWS Bedrock Security: What Guardrails, PrivateLink, and IAM Do Not Cover

Three separate Amazon Bedrock security features get bundled into one "is Bedrock secure" conversation more often than they should. Bedrock Guardrails filters content. AWS PrivateLink isolates network paths. IAM resource and identity policies gate which principal can call which API operation. Each control does its job well. None of the three asks whether this specific authenticated user, sending this specific prompt, right now, should be allowed to reach this specific model.

I want to map what each control actually secures, then walk through the request-level question none of them answer.

TL;DR

Bedrock Guardrails filters content (hate, insults, PII, denied topics, hallucination checks) at inference time or via a standalone ApplyGuardrail API call.
AWS PrivateLink creates a private network path to Bedrock's API, removing exposure to the public internet; it expanded to the bedrock-mantle endpoint in February 2026.
IAM policies control which principal can call which Bedrock operation, but a shared application role authorizes every request that role makes, regardless of the end user behind it.
None of the three evaluates a live request against the specific authenticated caller's role and the data classification of that specific prompt.

Guardrails filter content, not callers

Amazon Bedrock Guardrails provides content filters for categories like hate, insults, violence, and prompt attacks, denied-topic blocking, word filters, sensitive-information filters for PII, and contextual grounding checks for RAG hallucinations. A guardrail can run inline during a model invocation or standalone through the ApplyGuardrail API without touching the model at all.

That is a genuinely useful safety layer, and it is also a model-level behavior. Guardrails evaluates the content of a prompt or response against configured filters. It does not evaluate who the authenticated caller is, what role they hold, or whether that specific person is permitted to discuss that topic with that model at all. A guardrail configured to block a denied topic blocks it for every caller equally. Model guardrails, whether Bedrock's or any provider's, are a probabilistic content check running inside the inference path, not an identity-aware access decision.

PrivateLink secures the network path, not the request

AWS PrivateLink support for Bedrock lets a VPC reach Bedrock's API through an interface endpoint instead of the public internet, with no internet gateway, NAT device, or public IP required on the calling instance. AWS expanded this coverage in February 2026 to include the bedrock-mantle endpoint alongside bedrock-runtime, bedrock, bedrock-agent, and bedrock-agent-runtime.

PrivateLink answers a real question: can traffic to Bedrock avoid the public internet. It does not answer whether the traffic that does arrive, over that private path, should be permitted. A compromised credential or an over-permissioned service account sends its request over the same private, encrypted, network-isolated path as a legitimate one. Network isolation and request authorization are different layers, and PrivateLink only covers the first.

IAM authorizes the role, not the human behind it

IAM identity and resource policies determine which principal can call InvokeModel, Converse, or the guardrails API, and cross-account resource policies extend that to principals outside the account. This is the correct mechanism for coarse-grained access control: which team's service role can reach which model.

It is also, by construction, role-level. One application typically assumes one IAM role to serve every end user it has, which means IAM's authorization decision is made once, for the role, not once per request for the specific person the role is currently acting on behalf of. That is the same shared-credential pattern documented in Bedrock's own model invocation logging, where the identity.arn field records the assumed role and session name, not the natural person behind a given call. IAM secures who may hold the credential. It does not evaluate what a specific request, made with that credential, on behalf of a specific person, should be allowed to contain.

The request-level gap between all three

Stack Guardrails, PrivateLink, and IAM together and you get a private network path, content filtering on what crosses it, and coarse authorization on who can use it. None of the three evaluates the combination that actually matters for a regulated deployment: this authenticated user, this data classification, this model, this policy, right now. That is the post-authentication gap: authentication of the calling credential is solved by IAM, but authorization of the specific request against a specific identity is not solved by any of Bedrock's native controls. Why AI security must be inline makes the broader version of this argument: a decision that happens after the fact, in a log review, cannot prevent the request it is reviewing.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits inline in front of Bedrock (or any other HTTP-based LLM endpoint the same organization uses) as a stateless proxy. Every request is evaluated against the identity context the calling application supplies, the role behind that identity, and the data classification of the prompt, before the request reaches Bedrock. The decision, permit, redact, or deny, is recorded in a signed, tamper-evident audit entry tied to the actual authenticated caller rather than the shared IAM role that made the underlying API call.

Guardrails, PrivateLink, and IAM stay exactly as useful as they are today. DeepInspect adds the layer none of them were built to provide: a per-request, identity-bound policy decision, independent of the AWS account's own configuration.

Book a demo today.