Does AWS have an AI gateway product?

Not by that name. Amazon Bedrock AgentCore Gateway is the closest, and AWS's own documentation describes it as a secure AI gateway for agents, tools, and models. The three other things people mean by "AWS AI gateway" are the Amazon API Gateway plus Bedrock reference architecture, the Multi-Provider Generative AI Gateway guidance that deploys LiteLLM into your account, and Amazon Bedrock Guardrails, which is a policy layer rather than a gateway. The four have different security properties, so establishing which one is in play is the first question in any architecture review.

Do Bedrock Guardrails detect PHI?

They detect PII, with named built-in entity types such as ADDRESS, EMAIL, PHONE, NAME, and US_SOCIAL_SECURITY_NUMBER, plus custom regex, and they can block, anonymize, or pass. There is no PHI category and no MNPI category. Clinical content such as a SOAP note or a diagnostic plan carries protected health information that is not reducible to a named entity pattern, so a HIPAA workload that relies on Bedrock's entity types alone has a classification gap it will have to close somewhere else.

Is CloudTrail enough for AI audit?

CloudTrail records API activity and supports log-file integrity validation, producing a SHA-256 digest of a log file and signing that digest. This proves the file was not altered after CloudTrail wrote it. It does not produce a record of a single inference decision that binds the natural person, the prompt content, the data classification outcome, and the policy version that was active. Bedrock model invocation logging writes to S3 and CloudWatch, which are logs of what happened, not evidence of what was authorized and why.

How is DeepInspect different from Bedrock Guardrails?

Bedrock Guardrails evaluates content: is this text harmful, does it contain PII, is the response grounded in the source. It answers a question about the text. DeepInspect evaluates authorization: is this specific authenticated person, on this route, permitted to send this class of data to this model right now, and what record proves the decision. It answers a question about the principal. Both are useful, and they are not substitutes. The common production pattern runs DeepInspect for identity-bound authorization and evidence, with Bedrock Guardrails still applying content filters and contextual grounding behind it.

Can I use DeepInspect with Bedrock?

Yes, and it is one of the most common deployments. DeepInspect is model-agnostic and sits in front of any HTTP LLM endpoint, Bedrock included. The application calls DeepInspect, which binds the identity, classifies the prompt, commits the audit record, and forwards to Bedrock or AgentCore Gateway. Bedrock Guardrails keeps running. The difference is that the record of who authorized the call now exists outside the AWS account boundary that produced the call.

What about AgentCore Gateway's ingress and egress auth?

It is a real control and worth using. Per-tool credential injection on egress means an agent reaching a downstream tool does so with a credential scoped to that tool rather than a shared secret, which limits blast radius meaningfully. What it does not do is carry the originating human principal through the delegation chain, because the identity model is oriented to the agent and the tool. The gap it leaves is the same one A2A and MCP leave: the person who started the chain is not a field in the record at the far end of it.

DeepInspect vs AWS AI Gateway: What AWS Actually Ships and Where the Audit Record Stops

AWS ships no product called AI Gateway. When a platform team says "we're using the AWS AI gateway," they mean one of four different things, and the four have different security properties. I have had this conversation enough times that the disambiguation is worth writing down before any comparison makes sense.

The four are: Amazon Bedrock AgentCore Gateway, which is the closest thing to a real named product; the Amazon API Gateway plus Bedrock reference architecture, which is a pattern you assemble; the Multi-Provider Generative AI Gateway guidance, which deploys LiteLLM into your own account; and Amazon Bedrock Guardrails, which is a policy layer rather than a gateway at all.

I want to separate them, describe what each actually enforces, and then walk through what a regulated workload on AWS still has to add on top.

TL;DR

AWS gives you strong routing, real PII detection through Bedrock Guardrails, and log delivery to S3 and CloudWatch. Identity on the model call resolves to an IAM principal or a Cognito identity, and the invocation record is keyed to that. DeepInspect binds the natural person, classifies prompt content across PHI and MNPI as well as PII, and commits a signed per-decision audit record on a write path the application never touches. On AWS the two compose: DeepInspect in front, Bedrock behind.

The four things called "AWS AI gateway"

[Amazon Bedrock AgentCore Gateway](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html) is the real product, and AWS's own documentation heading calls it a secure AI gateway for agents, tools, and models. It converts APIs, Lambda functions, and existing services into MCP-compatible tools, supports passthrough targets fronting other agents including A2A traffic, does model-based routing across providers through a unified endpoint, and handles credential injection per tool. AWS claims it is the only fully managed service providing both ingress and egress authentication. It also does semantic tool discovery across large tool catalogs to keep prompts small. Serverless, with built-in observability.

[The API Gateway plus Bedrock pattern](https://aws.amazon.com/blogs/architecture/building-an-ai-gateway-to-amazon-bedrock-with-amazon-api-gateway/) is an AWS Architecture Blog reference derived from Dynatrace's production implementation. Amazon API Gateway is the entry point handling authorization, throttling, and lifecycle. A Lambda authorizer validates JWTs against your existing identity provider. A Lambda request forwarder SigV4-signs and routes to the right Bedrock endpoint. You get authorization, usage quotas, and response streaming. This is an architecture you build, not a service you enable.

[The Multi-Provider Generative AI Gateway guidance](https://aws.amazon.com/solutions/guidance/multi-provider-generative-ai-gateway-on-aws/) deploys LiteLLM into your AWS account on ECS or EKS, fronted by an ALB, with RDS, ElastiCache, Secrets Manager, AWS WAF, and S3 for application logs. It gives a unified OpenAI-compatible API across Bedrock, SageMaker AI, and external providers. Worth reading the fine print: AWS explicitly disclaims this as sample code not intended for production use as shipped.

[Amazon Bedrock Guardrails](https://aws.amazon.com/bedrock/guardrails/) is the policy layer. Six safeguard types: content filters, denied topics, word filters, sensitive information filters, contextual grounding, and Automated Reasoning checks, which use formal logic to catch hallucination. The sensitive information filters do genuine PII work, with built-in entity types including ADDRESS, EMAIL, PHONE, NAME, and US_SOCIAL_SECURITY_NUMBER, plus custom regex, and actions of BLOCK, ANONYMIZE, or NONE. The ApplyGuardrail API can be called against non-Bedrock models too, which is the underrated part.

What AWS enforces well

I do not want to strawman this. Bedrock Guardrails does real PII detection and masking, and the ApplyGuardrail API means you can use it in front of models that are not Bedrock. AgentCore Gateway's per-tool credential injection is a genuine control on the egress side. API Gateway with a Lambda authorizer gives you JWT validation against your existing identity provider, which is more than most gateways offer out of the box. CloudTrail supports log-file integrity validation with SHA-256 and signed digest files.

Any team that assembles these carefully has a defensible AI platform for a workload that carries no regulatory audit obligation.

Where the audit record stops

Three specific gaps, and each has a precise shape.

Identity resolves to a principal, not a person. Across all four patterns, the identity on the model call is an IAM principal, a Cognito identity, or an API key. AgentCore Identity supports inbound OAuth and JWT, so a user identity can be carried through, but the invocation record is keyed to the IAM principal that made the call. When six analysts share a service role, the record says the service role called the model six hundred times.

Classification covers PII, and stops there. Bedrock Guardrails' sensitive information filters have named PII entity types and custom regex. They have no PHI category and no MNPI category. A clinical documentation workload that needs to recognize a SOAP note, or a trading desk that needs to recognize material non-public information, is writing regex against a problem that regex was not built for.

CloudTrail signs the log file, not the decision. This distinction gets glossed over constantly. CloudTrail's log-file integrity validation produces a SHA-256 digest of a log file and signs the digest. That proves the file was not altered after CloudTrail wrote it. It does not bind an identity, a prompt, a classification outcome, and a policy version into a single signed record of one inference decision. Bedrock model invocation logging writes to S3 and CloudWatch, and those are logs.

That third gap is the self-attestation problem in a different costume. The system under audit is producing the audit record.

Feature comparison

| Capability | AWS (AgentCore / API GW / Bedrock) | DeepInspect | |---|---|---| | Multi-provider routing | Yes, AgentCore or LiteLLM guidance | Forwards to a configured upstream | | MCP tool conversion and hosting | Yes, AgentCore Gateway | Policy on MCP calls, not hosting | | Ingress and egress auth | Yes, AgentCore | Yes | | JWT validation | Yes, Lambda authorizer or AgentCore Identity | Yes | | Identity on the model call | IAM principal, Cognito identity, API key | Natural person from the identity provider | | PII detection and masking | Yes, Bedrock Guardrails | Yes | | PHI and MNPI classification | Not offered | Yes | | Content filters, denied topics | Yes, Bedrock Guardrails | Policy-driven | | Automated Reasoning hallucination checks | Yes, and unique to AWS | Out of scope | | Per-decision signed audit record | Invocation logs to S3 and CloudWatch | Yes, signed and identity-bound | | Log-file integrity | CloudTrail digest signing, at file level | Record-level signing | | Non-AWS model endpoints | ApplyGuardrail API works externally; routing is AWS-centric | Model-agnostic by design | | Deployment | AWS only | Any cloud, on-prem, air-gapped |

Pick AWS if

Pick the AWS stack if the model estate is Bedrock and stays Bedrock, and the workload carries no obligation to name a natural person in an audit record. Pick AgentCore Gateway if the deployment is agent-heavy and you want managed MCP tool hosting with per-tool credential injection, which is a genuinely good control and one of the better things AWS has shipped in this space. Pick Bedrock Guardrails wherever you can, including in front of non-Bedrock models through ApplyGuardrail, because contextual grounding and Automated Reasoning checks have no equivalent elsewhere.

Pick DeepInspect if

Pick DeepInspect if the audit record has to identify the person rather than the role. Pick it if the classification requirement includes PHI, MNPI, or jurisdictional data categories that Bedrock's PII entity types do not cover. Pick it if the model estate spans Bedrock and OpenAI and Anthropic direct and a self-hosted Llama, and the policy has to be identical across all four. Pick it if the deployment has to run outside AWS, on-premises, or air-gapped. And pick it if a reviewer is going to ask whether the application could have suppressed the record of its own decision.

Composition in production

The AWS topology that works for regulated workloads: the application calls DeepInspect. DeepInspect resolves the natural-person identity from the identity provider, classifies the prompt content, evaluates the per-route policy, commits the signed audit record, and forwards the cleared request to Bedrock or to AgentCore Gateway. Bedrock Guardrails still runs its content filters and contextual grounding. AgentCore still injects per-tool credentials. The response returns through DeepInspect, which evaluates it and closes the record.

Nothing in the AWS stack gets displaced. The identity binding happens before the request enters it, and the evidence record exists on a write path outside it.

Pricing approach

AWS bills consumption: Bedrock per token, API Gateway per request, AgentCore per usage, and the GenAI Gateway guidance costs you whatever the underlying ECS, EKS, RDS, and ElastiCache resources cost, since you run it yourself. Bedrock Guardrails bills per text unit evaluated, which is worth modeling before you turn it on across every route. DeepInspect is priced through sales conversation and deploys self-hosted or managed in any environment. Neither publishes an enterprise list price.

DeepInspect

This is the problem DeepInspect was built to solve. Every AI request is evaluated against the natural-person identity the application supplies, the route it arrived on, the classification of the data inside the prompt, and the policy version active at that moment. The decision is deterministic and fail-closed, and it lands before the request reaches Bedrock.

The per-decision audit record is the piece the AWS stack structurally cannot produce, because the only identity it ever sees on the model call is an IAM principal. DeepInspect commits a signed record carrying the person, the classification outcome, the policy version, and the outcome, and commits it before the response returns to the application. The write path is decoupled, so the service that made the AI call has no custody of the evidence describing it. That is what turns a log into something an EU AI Act Article 12 reviewer, a HIPAA auditor, or a DORA examiner accepts.

If you are running Bedrock against regulated data and the August 2, 2026 deadline is on your calendar, let's talk today.