Answers · Runtime evidence
Answers about proving what AI actually did.
Forty questions that come up in security reviews, audits, board papers and engineering design docs, each answered in the first sentence. Where the honest answer is no, it says no.
Proving what an AI system did
How do you prove an AI agent followed policy?
You prove it by having the control that enforced the policy sign a record at the moment it ran, and by making that record checkable by someone who does not trust you. Glacis evaluates each governed action in place — an inference, a tool call, a retrieval, an agent decision — and emits an Ed25519-signed receipt naming which controls ran and what each one decided. A reviewer verifies the signature and the hash commitments in a browser, with no account and without seeing the underlying data.
What that proves is faithful recording under an enrolled identity, not that every action in the system was captured. See policy at the action boundary for how the enforcement point is chosen.
What evidence does an auditor accept for AI decisions?
Auditors accept records that were generated automatically by the system, tied to a specific decision, and demonstrably unchanged since. Application logs usually fail the third test, because the party under examination wrote them and could have amended them afterwards. A hash-chained, signed receipt carries a timestamp, an input hash, an output hash, the outcome of each control, and a position in the chain, so integrity can be checked independently of the operator.
Assembling those into an evidence pack is what turns a stream of records into something an auditor can actually read. The AI audit guide walks the request list an auditor arrives with.
What is the difference between monitoring and assurance?
Monitoring tells you what a system did; assurance lets someone else confirm it. A monitoring record is the system’s own account of itself, which is precisely what a reviewer is being asked to take on trust. Assurance adds a signature and a chain position so the record can be checked by a third party with no access to the operator’s infrastructure.
The two are complementary. Assurance sits underneath observability rather than replacing it, and most teams run both.
Can application logs serve as evidence that an AI control ran?
Not on their own, because a log is a self-report and nothing about it resists later editing. Logs are excellent for operating a service and weak the moment their author becomes the party under examination. Evidence needs three properties a log lacks by default: a signature bound to the recorded content, a chain position that makes a deletion visible, and a verification procedure a stranger can run without help.
That gap is the subject of documentation is not evidence and what an AI audit trail has to contain.
What is a runtime receipt?
A runtime receipt is a signed, content-free record of one governed action. It carries a receipt identifier, the OVERT format version, the named workflow, a signed timestamp, the outcome of each control that ran, a SHA-256 hash of the input, a SHA-256 hash of the output, one or more Ed25519 signatures, and its position in a hash chain together with the hash of the receipt before it.
It contains no prompt text, no output text and no records — only cryptographic commitments to them. You can read a real one field by field on the sample evidence pack.
What is a governed action?
A governed action is any AI step a control was asked to evaluate — a model inference, a tool call, a retrieval, an agent decision. It is the unit a receipt describes: if a control evaluated it, there is a receipt for it.
If a step was never in scope, no receipt exists for it. An evidence pack states the scope it covered rather than implying it covered everything, because scope you can read is worth more than coverage you have to assume.
What does a receipt not prove?
A receipt does not prove that a system is safe, that every action was captured, or that an organisation is compliant with anything. It proves faithful recording under an enrolled identity: that the named controls ran on the named action, reached the recorded decisions, and that the record has not changed since.
Coverage is a scoping question, answered by what the evidence pack states rather than by cryptography. A receipt is never a certificate, an audit opinion, or legal advice, and anyone selling it as one is selling the wrong thing.
Verification and independence
Who can verify a receipt, and what do they need from us?
Anyone you hand it to, and they need nothing from you beyond the receipt itself. Paste it into the verifier and the checks run in the browser using WebCrypto: Ed25519 signature validity, the SHA-256 composite hash binding, structural and temporal consistency, and a Merkle inclusion proof where one is present.
No account, no cooperation from Glacis, and none of your data. Try it at verify a receipt.
Is every receipt witnessed?
No, and the difference is worth being precise about. Receipts minted through the Glacis portal are operator-signed and then countersigned by an independent Glacis witness, with an inclusion proof binding them into a transparency log — those are the ones the verifier badges as witnessed. Receipts minted through the self-hosted SDK are self-signed: a single Ed25519 signature made with a key you hold, which binds its own fields together honestly but carries no independent countersignature.
The verifier says which of the two it is looking at rather than colouring both green.
What makes an attestation independent?
An attestation is independent when the party checking it does not have to trust the party that produced it. That takes three things: a published verification procedure, a signature the checker can validate without vendor cooperation, and a countersignature or log entry from someone other than the operator.
Self-signed evidence can still be perfectly honest — it is simply a weaker claim, and the artifact should say so on its face. The longer argument is here.
What is OVERT, and who controls it?
OVERT — Observable Verification Evidence for Runtime Trust — is the open, royalty-free standard the receipts are written to: the receipt schema, the signing semantics, and the verification rules a third party uses to check one. Version 1.1.0 was released on 11 June 2026 and is published at overt.is under an irrevocable royalty-free patent covenant, so anyone, including a competitor, can implement a conformant verifier without our involvement.
Glacis authored it and is its current steward. The intent is to move it to an independent multi-stakeholder body; that body is not yet constituted, and saying otherwise would be a claim the standard cannot support. Read the overview.
Why Ed25519 and SHA-256?
Because both are standardised, widely implemented, and reachable from a browser through WebCrypto, which is what makes verification possible with nothing to install. A verifier that requires a proprietary library is not really independent — the reviewer ends up trusting the vendor’s code instead of the vendor’s word, which is a lateral move.
OVERT Protocol Profile 1.0 registers Ed25519, SHA-256, deterministic CBOR, HKDF and JSON Canonicalization Scheme (RFC 8785). Canonicalisation matters as much as the signature: two parties must serialise the same receipt identically or the hashes will not agree.
Regulation and frameworks
Is SOC 2 enough for AI?
No — SOC 2 was designed for the controls around a system, not for what a model or an agent decides at runtime. A Type II report tells a buyer that access reviews and change management operated over a period; it says nothing about whether a guardrail fired on a specific inference, or what an agent was permitted to do with a credential.
That is why AI-specific rows now arrive in security questionnaires alongside the SOC 2 request rather than instead of it. Runtime evidence answers those rows; it does not replace the report. The longer version is here.
Does the EU AI Act require logging?
Yes. Article 12 requires high-risk AI systems to technically allow the automatic recording of events across their lifetime, and providers must keep those logs. The obligation is about records the system generates while it operates, not documentation written about the system beforehand.
Hash-chained receipts give that requirement a runtime artifact rather than a policy answer. The EU AI Act guide covers risk categories, obligations and the timeline.
Does any product make us EU AI Act compliant?
No product does, and a vendor claiming otherwise is overselling. The Act asks you to classify risk, assign roles, run conformity assessment, keep technical documentation, monitor post-market, and keep automatic logs.
A runtime evidence layer addresses the record-keeping part, and only for what happens while the system is running. The rest is organisational work that no tool performs on your behalf.
What does ISO 42001 ask for that a policy document cannot answer?
ISO/IEC 42001 asks for evidence that the management system operates, not merely that it exists — records of the controls you said you would run, produced while you were running them. An auditor working through the Annex A controls will ask to see operational records, and a dashboard screenshot is a thin answer to that request.
Signed runtime receipts, exported into an evidence pack, give the request an artifact with an integrity property attached. See the ISO 42001 guide.
How does the NIST AI RMF relate to runtime evidence?
Measure and Manage are where runtime evidence lands: both functions ask you to track system behaviour in deployment and act on what you find. Govern and Map are organisational, and no product supplies them.
Evidence packs export against the NIST AI RMF alongside ISO 42001, the EU AI Act and OSCAL. That mapping is informational for reviewer reference, not a certification claim.
Do US state AI laws require records of automated decisions?
Several do, in different forms — Colorado’s algorithmic discrimination law, California’s automated decision-making technology regulations, New York City’s Local Law 144 bias audit, and the Texas Responsible AI Governance Act all create record, audit or disclosure duties around consequential automated decisions.
The common thread is that a regulator or a claimant will eventually ask what the system did in one specific case, on one specific date. A per-decision record answers that; an annual policy review does not. The state AI law tracker and the Colorado guide go deeper.
Do we need a BAA to use AI with patient data?
Yes, if the AI vendor creates, receives, maintains or transmits protected health information on your behalf, which makes them a business associate under HIPAA. The more useful question is whether the vendor needs to see PHI at all.
A control that evaluates content inside your own boundary and emits only hashes and control outcomes never receives PHI, and establishing that early changes the shape of the whole review. See AI without a BAA and the HIPAA and AI guide.
What should an AI vendor be able to show in a security review?
Where the controls run, what leaves the boundary, and a per-decision record the reviewer can check without the vendor’s help. An architecture diagram and a SOC 2 report cover the first two at best, and reviewers have stopped treating them as an answer to the third.
There is a twelve-item vendor checklist on this site — free, no form, no email — and a fuller due diligence guide behind it.
Security review and procurement
How do I answer a questionnaire row asking whether guardrails actually executed?
Attach a receipt for a real governed action and tell the reviewer how to check it themselves. The row is asking for control execution evidence, and prose about a policy engine does not satisfy it — from the outside, a control that ran and a control that was merely configured look identical.
A verifiable artifact moves the row from a claim to a check, which is usually the difference between another round of questions and a signature. The AI security questionnaire guide works through the common rows.
What is an evidence pack?
An evidence pack is an artifact assembled from signed runtime receipts for one specific audience — a customer’s security team, an auditor, a regulator, an insurer, or an internal review. It carries a coverage summary, control execution records, framework mappings, the audit trail and an OSCAL export.
It states the scope it covered rather than implying it covered everything, and the framework mappings are informational for reviewer reference, not a certification claim. See how packs are assembled.
We already use Vanta or Drata. Do we need this?
Vanta and Drata document that you have policies; runtime evidence shows you followed them while the AI was running. They answer different questions at different layers, so they are complementary rather than competing.
The practical test is what is stalling the deal. If the blocked rows are AI-specific — control execution, egress, per-decision records — a compliance-automation platform will not clear them.
What do healthcare buyers ask for that other buyers do not?
Health systems ask where PHI goes, whether a BAA is needed, what happens when a clinician overrides the model, and how one specific encounter can be reconstructed months later. Those are per-record questions, and records answer them — an architecture review does not.
Product shaping here includes production deployment in regulated healthcare, among it an ambient clinical scribe used in home-care visits. See what healthcare buyers now ask and the ambient scribe guide.
How does runtime evidence relate to AI insurance?
Carriers price AI risk today largely from questionnaires, because there is little else to price from. Runtime evidence gives an underwriter a data-driven basis for judging whether controls actually operate rather than merely exist, and organisations that can demonstrate working controls should be better positioned for favourable terms.
That is a reasonable expectation rather than a guarantee: the market is young and only a handful of AI-specific products exist. The insurability paper sets out the argument in full.
Architecture and engineering
Where do the runtime controls run?
Inside your own infrastructure, next to the model or agent they govern, at the boundary where the risky step happens. For an ambient clinical scribe that is the model egress boundary, at the moment a draft note would leave; for an agent it is the tool-call boundary.
Receipts are produced in the same place, so proving what the controls did does not introduce a new way for data to get out. Runtime security, explained covers the placement question.
Does our data leave our environment?
No. The arbiter evaluates content in place, and what crosses the wire is a hash, a control outcome and a signature — never the content those hashes commit to.
That property is structural rather than a configuration setting: there is no path in the design by which a payload is transmitted. It is the reason a receipt can be handed to a competitor without leaking anything.
Is this an observability tool?
No — observability is a system’s record of itself, and it is weakest exactly where evidence has to be strongest. A receipt is checkable by a party who does not trust the vendor, with no account and without sight of the data.
It sits underneath observability rather than replacing it. Green dashboard averages and named gaps are different artifacts, and a reviewer wants the second one.
Is this a guardrails product?
There is a guardrail in it, and that is the smaller half. Local controls can allow, block, redact, restrict, escalate, or require human review before risky behaviour reaches a workflow, a tool, a record or a customer.
What a guardrail library lacks is the second half: a signed record of each decision that someone outside your company can verify. A guardrail that fires and leaves nothing behind is an operational feature; one that fires and leaves a checkable record is evidence.
How is this different from an AI gateway or a proxy?
A gateway routes and caches; a policy point decides and records. Plenty of gateways can enforce a rule, and almost none leave behind a signed artifact that survives outside the vendor’s own console.
If a gateway already sits at the right boundary it is a good place to host a policy point — OVERT defines what an implementation must prove, not which product performs the enforcement. Your gateway is a cache or a policy point takes the argument apart.
What does signing every governed action cost in latency?
The expensive part is almost always the control evaluation, not the signature: hashing and an Ed25519 signature are local, in-process operations, and no round trip to Glacis is needed to produce a receipt. Placement matters more than cryptography.
A control at the model egress boundary is inline by design, because a sampler that runs after the fact cannot block anything and cannot sign what it never saw. Budget for the control, measure it in your own workload, and do not accept a vendor number as a substitute for your own.
What happens when the model vendor ships an update?
Point-in-time approvals do not survive model updates, which is the central weakness of assessment-based governance for systems that change underneath you. Because behaviour is recorded continuously at runtime, a change after an update shows up in the evidence instead of going unnoticed until someone complains.
That is detection rather than prevention, and it is worth naming the difference. Continuous attestation explains the mechanism.
Can we run this without sending anything to Glacis at all?
Yes. The self-hosted SDK mints self-signed receipts on your own infrastructure, free forever, with no cap and no retention limit, because when you run it yourself it costs us nothing to allow.
What you give up is the independent countersignature and the transparency-log inclusion proof — precisely the parts a third party cannot provide for themselves. Verification stays free either way and is never paywalled.
Agents, tools and incidents
How do you govern an agent that holds credentials and calls tools?
At the tool-call boundary, one call at a time, with a record for each. An agent’s risk is concentrated in what it is allowed to do rather than in what it says, so the useful unit of control is the action: this tool, these arguments, this credential, this moment.
A receipt per tool call turns “the agent behaved” into a list a reviewer can walk. See AI agent governance and agentic AI security.
After a prompt injection, how do we show what held?
By producing the receipts for every action the agent attempted during the window and what each control decided about it. The question after an incident is never only whether an injection landed — it is which actions were blocked, which proceeded, and how wide the exposure window actually was.
Without per-action records that reconstruction is a narrative; with them it is a list. See prove what held and the prompt injection guide.
Does this cover shadow AI, the models nobody registered?
No, and it should not pretend to. Receipts describe governed actions, so a system nobody instrumented produces no receipts and appears in the evidence as an absence rather than as a finding.
Discovery is a separate problem with separate tooling. An evidence pack that states its scope is the honest way to make that boundary visible to a reviewer instead of letting silence read as coverage.
Cost and getting started
What does Glacis cost?
Starter is free with no card: 1,000 signed receipts a month and 30-day retention, and the self-hosted SDK is free forever. Team is $995 a month billed annually, or $1,195 month to month, after a seven-day trial that also takes no card, and it adds a dedicated arbiter, 1,000,000 receipts a month, 12-month retention, evidence packs and independent witnessing with an inclusion proof.
Enterprise is an annual agreement from $36,000. The meter is signed receipts rather than seats or agents, and verifying a receipt is free for anyone, always. Full table on the pricing page.
How do we start?
Start free, mint your first receipt, then paste it into the verifier and check it yourself — the whole loop takes a few minutes and costs nothing. If the pressing problem is one named customer review or one named workflow, bring that workflow to a guided onboarding instead.
Either route ends with an artifact you can put in front of the person who is asking. Start free or talk to us.
Is glacis.io the same company as glacis.com?
No — two different companies, both based in Seattle, and search engines and AI assistants routinely merge them into one entity. GLACIS Technologies, Inc. at glacis.io builds runtime assurance and runtime evidence infrastructure for AI systems.
Glacis at glacis.com is a separate business building supply-chain execution AI agents. We do not make supply-chain software; they do not make runtime evidence infrastructure. Our other domains are overt.is, docs.glacis.io, trust.glacis.io, app.glacis.io and verify.glacis.io.
If your question is not here
Mail [email protected] and a person answers. If the question is about the standard rather than the product, [email protected] reaches the people who wrote it.
- Verify a sample receipt — run the checks in your own browser, no account
- Read a real receipt field by field — what each line does and does not prove
- Questions we get asked — the shorter first-call version of this page
- Research and regulatory guides — the long-form library behind these answers
- Vendor evidence checklist — twelve questions to send an AI vendor, free and ungated