Runtime guardrails for AI in production
AI guardrails that leave a record anyone can check.
Usually Glacis finds nothing to stop and the work goes through. When an action crosses a line you set, it gets held, narrowed or denied while it’s live. Either way there’s a signed record an outside reviewer can verify in their own browser, with no Glacis account.
Who it’s for
The demo always works. Production is where it stops.
Getting the AI to do the work is the easy half. Getting anyone to sign off on it touching a real system, or a real patient record, is where pilots stall.
Start with the one that sounds like you:
I oversee AI in healthcare
Put your rules where the AI runs.
Privacy, clinical and escalation requirements, attached to the workflow rather than to each vendor.
How it works in healthcare →I build or run AI agents
Give agents room to act.
Each tool call is checked against your rules before it runs, and the decision goes on record.
How it works for agents →“Together, Glacis and nVoq have raised the bar for proactive AI trust and assurance, embedding consent validation, human‑in‑the‑loop oversight, and robust guardrails directly into ambient workflows.”
Chad HinerSenior Vice President of Product, nVoq
How the risk loop works
Most actions go straight through.
Nobody ships a control that blocks everything. Glacis checks each action against the bounds you set and steps in only when one crosses them. The decision is made while the action is live. Nothing waits in a queue for someone to review later.
- 01
AI attempts an action
- 02
Context and bounds
-
03 · Decision
Allow Constrain Hold Deny
- 04
Outcome reported
- 05
Signed record
Allow: the action goes through unchanged. Constrain: it goes through with the risky part narrowed or redacted. Hold: it waits for a person. Deny: it’s refused, and the refusal is recorded.
Build versus buy
Nine things you’d have to build first.
This is what sits between an agent that works and an agent anyone will let near production. Build the missing pieces yourself and you own them forever, through every model swap and every new rule.
- 01Agent and workload identity
- 02Scoped credentials
- 03Network and tool boundaries
- 04Policy evaluationShown below
- 05Classifier or model-based review
- 06Isolation
- 07Escalation
- 08Versioned evidenceLive
- 09Incident reconstructionLive
Policy evaluation, versioned evidence and incident reconstruction are in the product today; the demonstration below runs the first. The other six stay the systems you already run, and Glacis works inside them. It doesn’t replace your identity provider, your cloud or your security program.
Healthcare, in one action
A scribe note passes the PHI check.
A scribe drafts a note containing PHI. The control runs, finds nothing to stop, and lets it through. The record gets written anyway. Months later, when someone asks about this particular note, you answer from a signed record a reviewer can check, not from a vendor log you’d have to take on trust.
Demonstration workflow data. What the record does and doesn’t establish is set out under the verifier below.
- 09:14:02.118 workflow → ambient-scribe-draft-note action
- 09:14:02.131 PHI egress check → 14 rules evaluated control ran
- 09:14:02.140 0 rules triggered · policy mode enforce allowed
- 09:14:02.152 signed operational record created record signed
- Action
- ambient-scribe-draft-note
- Rule
- PHI egress check · policy mode enforce
- Control
- 14 rules evaluated · 0 triggered
- Outcome
- pass · allowed · signed record
The verifier
Someone outside your company can check it.
Risk and clinical leads don’t take a vendor’s word for how its AI behaved. This is the demonstration record from above. It verifies in your browser, with no Glacis account, and it carries hashes rather than the note itself.
The verifier confirms the record is intact, shows which key signed it and what it links to, and reads back the decision it recorded. It doesn’t tell you whether the note was clinically correct, whether every encounter was captured, or whether the system is safe or compliant, and it can’t confirm that events happened the way the record says. To check the signing key and the record’s provenance, open the full verifier.
After guardrails
What the record is for.
The record is for the questions that stall a pilot: the sign-off before an agent touches a real system, the security review that wants evidence instead of another policy document, and the question, months later, about one specific action. Guardrails come first because outside review and risk transfer both need a record to work from. Our part is the boundary and the signed record.
-
01
Guardrails, then evidence
Put the boundary where the AI acts. A record of each covered decision builds as it runs.
Glacis
-
02
Outside review
An independent evaluator examines the controls and the record. Where a recognized certification applies, the record is one input to the assessor’s own process.
Independent evaluator · accredited assessor
-
03
Risk transfer
You can put a defined risk schedule to insurers, usually through a broker. Underwriting, wording, pricing and claims are theirs to decide.
Broker · underwriter · licensed insurer
Glacis is not a certifier or an insurer, and doesn’t guarantee certification, insurability, pricing or claims outcomes. Steps two and three are what others can do with the record, not services Glacis performs.
Your records stay readable without us.
The format is open and published. A record you hold today stays readable whether or not you’re still a customer, and nobody needs our permission to check it.
Try it on one real action.
Start free, put Glacis in front of it, and read what the record says.