Healthcare AI guardrails: Bedrock, Azure, Lakera, NeMo, and Arcjet

Which healthcare AI guardrails can you compare?

Healthcare AI guardrails screen a model's input and output, or the action an AI agent is about to take, so protected health information (PHI) stays where it belongs. The options are AWS Bedrock Guardrails, Azure AI Content Safety with Microsoft Foundry guardrails, Lakera Guard, NVIDIA NeMo Guardrails, and Arcjet. Most screen prompts and responses. Arcjet decides on the agent's action, such as a send or a write, before it runs.

Arcjet publishes this comparison. Competitor details come from each vendor's public documentation, checked on November 6, 2026. The comparison covers documented scope, not measured detection accuracy, and it's technical guidance, not legal advice.

PHI is health information that can be linked to a specific person through an identifier, such as a name, a medical record number (MRN), or a health plan member ID. In a chat assistant, PHI arrives in the prompt and leaves in the response. An agent also reads a chart and then calls a tool to send a referral or post to a payer's API, and the PHI travels in that tool call's arguments.

How do Bedrock, Azure, Lakera, NeMo, and Arcjet compare?

All five products detect personally identifiable information (PII) in text, and all five can block. They differ on three points that matter for PHI: whether they see tool-call arguments, whether a check can stop an action before it runs, and whether a business associate agreement (BAA) covers the service. The following table summarizes each product.

How is a guardrail different from a policy on the agent's action?

A guardrail checks the content a model reads and writes. A policy on the action checks what the agent is about to do, with its arguments, before the tool runs. Healthcare teams need both, because an agent's PHI often leaves through tool arguments that a prompt and response check never sees.

Take a prior authorization agent. A nurse asks it to submit a request. The agent reads the chart, builds a send_fax call with the patient's name, MRN, and diagnosis, and replies "Done, the request is on its way." An output guardrail screens that reply and finds nothing. The PHI went to the fax number in the tool call, and if the model picked the wrong number, the disclosure already happened.

HIPAA's terms show why the tool call is the point to control. A covered entity is a health plan, a clearinghouse, or a provider that sends health information electronically in a covered transaction, such as a claim, and a business associate is a vendor that handles PHI on its behalf, as defined in 45 CFR 160.103. The minimum necessary standard in 45 CFR 164.502(b) asks you to limit a use or disclosure to what its purpose needs. For an agent, the disclosure is the tool call.

An action policy can also use context that a content filter doesn't have. It can allow a member ID in a claims lookup and deny the same member ID in an email to an outside address. The audit controls standard in 45 CFR 164.312(b) gives a reason to keep those decisions, since a record of what the agent tried and what was refused is evidence that a filtered transcript can't provide.

What do AWS Bedrock Guardrails cover for HIPAA workloads?

Bedrock Guardrails screens prompts and model responses for harmful content, prompt attacks, denied topics, and sensitive information, and Amazon Bedrock is HIPAA eligible under an AWS BAA. AWS documents that the sensitive information filter doesn't evaluate tool-call arguments, tool results, or tool definitions, so Guardrails alone doesn't screen PHI that an agent writes into a tool call.

The sensitive information filter blocks a request or masks each match with its type, such as {NAME}. Built-in types include NAME, ADDRESS, PHONE, and US_SOCIAL_SECURITY_NUMBER, but no US medical record number or member ID, so you add those as regex patterns. AWS gives its own example: if the model passes a customer's email address to a tool that writes a file, the address isn't masked. Masking also doesn't reach model invocation logs, where the input field keeps the original request.

The ApplyGuardrail API evaluates any text without calling a model. You can pass a tool's arguments to it before the tool runs, and then your code owns the check and the decision.

AWS's control for the action is a separate service. Policy in Amazon Bedrock AgentCore, generally available since March 3, 2026, evaluates tool calls that pass through an AgentCore Gateway against Cedar policies before the tool runs. A policy can call a Guardrails sensitive information check on a tool's input and forbid the call. AWS documents the limits: only Gateway traffic is covered, guardrails in policies don't support regex, they run in a subset of Regions, and scores can differ between calls. Amazon Bedrock AgentCore has its own line on the HIPAA eligible services list.

What do Azure AI Content Safety and Foundry guardrails cover?

Microsoft Foundry guardrails apply Azure AI Content Safety classifiers at four points: user input, tool call, tool response, and output. The tool-call and tool-response points are in preview, apply only to agents built in Foundry Agent Service, and work only with tools that support moderation. Microsoft's HIPAA BAA covers Azure.

Prompt Shields detects prompt attacks in user input and in documents. Through the standalone Content Safety API, it returns a result and your application decides. Inside Foundry, a blocking control stops the input before the model processes it.

The guardrails overview lists PII detection (preview) for models and agents. The PII filter page describes it as scanning model output, with annotate and block modes and no masking mode. For redaction, you call Azure Language PII detection from your own code.

When a tool-call control fires, the intervention points page says the tool call isn't executed. The supported tools are Azure AI Search, Azure Functions, OpenAPI, SharePoint Grounding, Fabric Data Agent, Bing Grounding, Bing Custom Search, and Browser Automation, and a control doesn't apply to any other tool. The page's tool-call example screens for hateful content, so confirm that a PII control applies at that point before you rely on it for PHI. Microsoft's HIPAA page says the BAA is available by default to covered entities and business associates through the Data Protection Addendum.

What does Lakera Guard cover for PHI?

Lakera Guard, part of Check Point and now documented as Check Point AI Guardrails, is an API that screens prompts, outputs, and tool calls for prompt attacks, data leakage, and harmful content. It runs as SaaS or self-hosted. Its listed PII detectors don't include health identifiers, and its public documentation doesn't mention a BAA, so ask Check Point before you send PHI.

Data Leakage Prevention lists eight detectors: names, US mailing addresses, US phone numbers, email addresses, IP addresses, card numbers, IBANs, and US Social Security numbers. You can add custom entity types, and a match can be masked or blocked. Tool-call arguments are screened when you include them in the request. The API returns a flagged result, and your application decides what to do, as the integration guide describes. Lakera's trust center lists a HIPAA report. For a wider comparison, see Lakera alternatives.

What does NVIDIA NeMo Guardrails cover?

NeMo Guardrails is an open source library under the Apache 2.0 license that you run in your Python application or as a server in your own infrastructure. Its rails cover input, output, retrieval, and dialog, and execution rails check the inputs and outputs of tools. You host it, so no vendor BAA applies to the library itself.

A rail is a check that runs at one point in the conversation. The PII detection rails run on input, output, and retrieval, using Presidio, the NVIDIA GLiNER-PII model, or the Private AI API. A detect flow blocks the message, and a mask flow replaces each match with a label such as [FIRST_NAME]. The page lists no healthcare entity types.

Where each detector runs matters for a BAA. Presidio runs in your process, GLiNER-PII runs locally or as an NVIDIA-hosted endpoint, and Private AI is an external API in its cloud mode. NeMo gives you the hook points, and the MRN patterns, the action rules, and their tests are yours to build.

How does Arcjet decide on an agent's action?

Arcjet is an AI agent runtime security platform that enforces policy where the action happens, in your code and in coding-agent hooks, not on the network. A guard() call before a tool runs sends the tool's arguments to a published policy. A server-side detector checks them for PHI identifiers, and when the policy denies the call, your code refuses it before anything is sent.

A policy is a set of rules that Arcjet evaluates on each call, written in Rego, an open source policy language, or in a visual builder. A detector is a check the policy can call. PHI detection adds five types to the 20 core entity types, including MEDICAL_RECORD_NUMBER and HEALTH_PLAN_BENEFICIARY_NUMBER. An MRN has no fixed format, so Arcjet recognizes it from a nearby label such as MRN.

In the prior authorization example, the fax tool calls Arcjet first:

1
import { launchArcjet, policyInput } from "@arcjet/guard";
2

3
const arcjet = launchArcjet({ key: process.env.ARCJET_KEY! });
4

5
const decision = await arcjet.guard({
6
  label: "fax.sent", // selects the published policy with this label
7
  actor: userId,
8
  inputs: {
9
    note: policyInput.server.string(faxBody),
10
    external: policyInput.server.boolean(true),
11
  },
12
});
13

14
if (decision.conclusion === "DENY" || decision.hasFailedOpen()) {
15
  // refuse the tool call and tell the agent why
16
}

The policy denies the call when the detector, with the ID phi, finds an identifier in a note bound for an outside recipient:

1
deny contains "identifiers-to-external" if {
2
  input.signals.sensitive_info.phi.detected
3
  input.values.external
4
}

The PHI types work only in this server-side detector, which reads SERVER inputs on Arcjet's servers. When it flags a value, Arcjet removes the value and keeps only the entity types and positions, as described in Privacy. Arcjet enters into a BAA with Enterprise-level customers whose use of Arcjet involves PHI, and both parties must sign it before any PHI is processed.

Claude Code, GitHub Copilot, Cursor, OpenAI Codex, and Muse Code call Arcjet from their hooks, the commands or HTTP calls each agent makes at set points such as before a tool call. A coding agent policy can deny an MRN in a developer's prompt, except in Copilot, which records a prompt denial but doesn't apply it. When a tool result, such as a fixture file of real patient rows, contains a denied type, session analysis flags the session, and the coding-agent.session-analysis starter refuses later web and Model Context Protocol (MCP) calls, the calls that could send data out.

Arcjet detects identifiers and doesn't redact or de-identify text. It can't block a coding agent's tool result, because the hook reports it after the tool ran. It doesn't detect dates, ages over 89, biometric identifiers, full-face photographs, or the catch-all class of other unique codes from the Safe Harbor list in 45 CFR 164.514(b)(2), and detection doesn't make a system HIPAA compliant on its own. For the full approach, see how to stop AI agents leaking PHI and HIPAA compliance for AI agents.

Which healthcare AI guardrail fits your stack?

Pick the guardrail that sits where your model and agent traffic already runs, then check whether it reaches your tool calls. Bedrock Guardrails suits workloads on Bedrock, Foundry guardrails suit Foundry Agent Service, NeMo suits teams that want open source in their own infrastructure, and Arcjet suits agents whose tool calls need a decision in code.

Bedrock Guardrails is the natural choice if your models run in Bedrock and your BAA is with AWS. Add Policy in AgentCore if your tools can sit behind an AgentCore Gateway, and add regex patterns for your MRN and member ID formats. Foundry guardrails fit agents in Foundry Agent Service that use the supported tools, under a Microsoft BAA you may already have, once you've tested the preview tool-call controls against PHI.

NeMo Guardrails fits a team that must keep every byte in its own environment and can maintain the rails. Lakera fits a content-screening API in front of chat and retrieval, with a self-hosted option, once you've settled the BAA question with Check Point.

Arcjet fits when your agents run in your own code, on any model provider, and the decision depends on the action's arguments and context. It also covers coding agents that read repositories with real patient data. You can run two layers, with a provider guardrail on the model and Arcjet on the tool calls. For detection products, see PHI detection tools, and for the wider market, see AI agent security platforms.

How do you test a guardrail against PHI in tool calls?

Test each candidate with synthetic records in your own formats. Put a labeled MRN and member ID in a prompt, a model response, a tool-call argument, and a tool result, then record which checks fired and whether the tool ran.

Include a bare eight-digit number with no label to see what each detector misses, and a claims lookup that must carry a member ID to measure false positives. Record whether a denied call reached the downstream service, what the product stored, and the latency it added. Run rules in dry run first, then block once the results match what you expect. For agent-specific attacks, see prompt injection in healthcare AI agents.