Answers · Runtime evidence

Answers about evidence from covered AI workflows.

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.

Evidence from covered AI workflows

How do you prove an AI agent followed policy?

Put a configured control at the action boundary and preserve a signed record of what that control path reported for the in-scope event. Glacis can evaluate an inference, tool call, retrieval, or agent action and produce an OVERT-compatible record naming the rule, decision, time, and covered evidence.

A verifier can check the record’s covered signatures and hash commitments. That does not by itself prove the control was effective, that its report was true, or that every action was captured. See policy at the action boundary for how scope is chosen.

What evidence does an auditor accept for AI decisions?

Acceptance depends on the audit objective, criteria, source system, key custody, scope, and corroborating evidence. Automatically generated, decision-linked records with independently checkable integrity can be stronger than editable screenshots or unsupported narratives, but a signature alone is not an audit opinion.

An evidence pack can assemble bounded records, scope, exclusions, and supporting context for review. The AI audit guide describes questions a reviewer may ask.

What is the difference between monitoring and assurance?

Monitoring helps operators understand system behavior. Operational evidence adds a portable record whose covered signatures, hashes, and supported chain properties can be checked by another party. That check confirms specific integrity properties, not the truth or completeness of every claim in the record.

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?

They can be evidence, but their weight depends on access controls, retention, integrity protection, independent anchors, and corroboration. Ordinary application logs are optimized for operations and may not provide those properties by default.

That distinction is the subject of documentation versus operational evidence and what an AI audit trail has to contain.

What is a runtime receipt?

A runtime receipt is a structured record for one in-scope event. Depending on the OVERT version and profile, it can carry a record identifier, workflow, timestamp, reported control outcomes, cryptographic commitments, signatures, scope, and chain or transparency evidence.

A data-minimizing profile can omit protected prompt and output text while carrying hashes that commit to them. Read the exact specimen and limits on the sample evidence pack.

What is a governed action?

A governed action is an AI step inside a configured control boundary: a model inference, a tool call, a retrieval, or an agent decision. When record generation is configured, it is the unit the operational record describes.

A step outside the instrumented boundary is outside the evidence. An evidence pack should state its scope and exclusions rather than allowing silence to read as coverage.

What does a receipt not prove?

A receipt does not prove that a system is safe, that every action was captured, that a control was effective, or that an organization is compliant. A valid signature binds the fields it covers to a key; supported hash and chain checks can make certain alterations detectable.

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?

A third party with a supported record and applicable public-key or transparency material can run the browser verifier. It reports which signatures, hashes, fields, and supported proofs it actually checked.

No account is needed for the public verifier. A pass remains bounded by the supplied evidence and does not establish completeness or truth. Try it at Verify a record.

Is every receipt witnessed?

No. A self-signed record carries an operator signature; a witnessed record also carries a recognized countersignature or supported transparency evidence. The verifier names which keys and proofs it checked.

A second signature is not automatically independent. Reviewers still need to examine key custody, operator separation, scope, and any external anchor.

What makes an attestation independent?

Independence is a property of the verification and trust arrangement, not a label. A reviewer needs a published procedure, suitable key material, explicit scope, and evidence that any witness or external anchor is separated from the operator for the claim being made.

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, short for 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 publishes the current specification and versioned materials at overt.is. Publication under a public specification and patent covenant supports independent implementation; it is not a claim that an external standards body endorses or governs OVERT. Read the overview.

Why Ed25519 and SHA-256?

Because both are standardized, 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, because 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?

A SOC 2 examination addresses controls within its stated system description, criteria, period, and auditor opinion. It may not answer a buyer’s separate question about what happened on one AI inference or tool call unless that evidence is in scope.

Workflow-level operational evidence can supplement, but 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. What it wants is 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 operational records can be assembled with explanatory material into a scoped review packet. Glacis does not currently offer a proof-bundle export route; the reviewer must assess the supplied artifacts and coverage. 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 behavior in deployment and act on what you find. Govern and Map are organisational, and no product supplies them.

Public materials include informational mapping references for the NIST AI RMF, ISO/IEC 42001, the EU AI Act, and OSCAL. No proof-bundle export route is currently offered, and the mappings are not a certification claim.

Do US state AI laws require records of automated decisions?

Several do, in different forms. Colorado’s SB 26-189 automated decision-making law, California’s automated decision-making technology regulations, New York City’s Local Law 144 bias-audit requirements, and the Texas Responsible Artificial Intelligence Governance Act each create their own scoped record, audit, notice, or disclosure duties around consequential automated decisions.

The common thread is that a regulator or claimant may ask what the system did in one specific case, on one specific date. A per-decision record can contribute to that answer; routing, source, timing, and coverage evidence remain necessary. 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.

Whether a BAA is required depends on the parties, roles, data, and services. A customer-hosted control path may be configured so Glacis does not receive PHI, but that architecture must be verified against the actual deployment, contracts, and data flow. See AI without a BAA and the HIPAA and AI guide; obtain legal advice for the specific arrangement.

What should an AI vendor be able to show in a security review?

Ask where controls run, what crosses each boundary, what happens on an exception, and what record remains for an in-scope decision. Architecture diagrams and assurance reports provide useful context; a workflow-level artifact addresses a different question.

There is a twelve-item vendor checklist on this site. It is free, it asks for no form and no email address, and a fuller due diligence guide sits 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, explain how the reviewer can check it, and include the routing, deployment, timing, and coverage evidence needed for the claim. A receipt supports integrity and signer attribution for its reported fields; it does not establish control execution by itself.

A verifiable artifact moves part of the answer from a narrative to an inspectable check. Acceptance still depends on scope and the reviewer’s criteria. The AI security questionnaire guide works through the common rows.

What is an evidence pack?

For a scoped engagement, a review packet is a manually assembled set of selected signed records, workflow context, coverage notes, and informational mapping references for one audience, such as a customer security team, auditor, regulator, insurer, or internal review.

It states the scope rather than implying complete coverage. Glacis does not currently offer an automated proof-bundle or OSCAL export route, and reviewer acceptance remains engagement-specific. See the review-packet pattern.

We already use Vanta or Drata. Do we need this?

Compliance-automation tools help manage programs, policies, and evidence requests. Operational records address a narrower question about a configured AI action and the control path that reported on it. The categories can be complementary.

If a review asks about control execution, egress, or per-decision evidence, answer with the relevant architecture, scope, and artifacts rather than assuming one platform clears the row.

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. Records and architecture answer different parts of those questions; reconstruction needs both, plus source, timing, and coverage evidence.

See questions for healthcare buyers and the ambient scribe guide for workflow-specific examples.

How does runtime evidence relate to AI insurance?

Operational evidence is a proposed input to underwriting and claims review: it may help an insurer examine what a configured control path reported for a defined workflow and period.

That is a research hypothesis, not evidence of insurer adoption, available coverage, or better terms. The insurability paper uses illustrative composite cases and states those boundaries.

Architecture and engineering

Where do the runtime controls run?

Controls can run beside the model or agent in a customer-hosted sidecar, or at another documented action boundary. For an ambient scribe that might be the draft-note egress boundary; for an agent it might be the tool-call boundary.

Placement determines what the control can see, stop, and record. The configured data path and exclusions still matter. Runtime security, explained covers the placement question.

What data leaves our environment?

It depends on the deployment. In customer-hosted sidecar mode, evaluation and record generation can run locally while bounded decision metadata, hashes, and signatures follow the configured path rather than protected prompts or responses.

The Order Form, DPA, and deployment configuration define the actual data flow. Verify that boundary for the specific system.

Is this an observability tool?

Observability helps operate a system. A signed operational record adds portable integrity checks for the fields it covers; it does not make every operational claim independently true.

Glacis sits underneath observability rather than replacing it. Reviewers may need both operational context and bounded evidence.

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 behavior reaches a workflow, a tool, a record or a customer.

What Glacis adds is the option to preserve a signed record for covered decisions. That record reports what the configured control path did; scope and effectiveness still require separate review.

How is this different from an AI gateway or a proxy?

A gateway can route, transform, observe, or enforce depending on its design. The relevant question is whether it is on the action path, which rule it applies, and what portable record remains.

If a gateway already sits at the right boundary it may host a policy point. OVERT defines a record and verification vocabulary rather than requiring one enforcement product. Your gateway is a cache or a policy point takes the argument apart.

What does signing a governed action cost in latency?

It depends on the control, payload size, signing path, hardware, network, and deployment mode. Hashing and Ed25519 signing can run locally, but benchmark the complete configured path on your own workload.

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 if the arbiter is unavailable?

The configured policy may fail open, fail closed, or escalate, subject to the deployment’s capabilities and risk decision. Record that posture explicitly.

A hash chain can make some removals or reorderings detectable to a reviewer who holds an earlier trusted link or external anchor; operational monitoring is still required to identify outages and missing coverage.

What happens when the model vendor ships an update?

A model update can invalidate assumptions behind a prior assessment. If the deployment records model identity, control outcomes, and relevant signals, reviewers can compare evidence before and after the change; the record does not guarantee that every behavioral regression will be detected.

That is detection rather than prevention, and it is worth naming the difference. Continuous attestation explains the mechanism.

Can record generation run in our own environment?

Customer-hosted options can generate operator-signed records inside your environment. Current licensing, limits, retention, support, and witnessing options are described in the applicable product documentation and agreed when the deployment is scoped.

An operator signature and an independently controlled witness are different trust claims. The record and verifier should make that distinction explicit.

Agents, tools and incidents

How do you govern an agent that holds credentials and calls tools?

Place a control at the tool-call boundary and define the allowed tool, arguments, credential scope, and escalation path. Generate a record for each configured in-scope call.

Those records turn a broad behavioral claim into a bounded list a reviewer can inspect. See AI agent governance and agentic AI security.

After a prompt injection, how do we show what held?

Produce the available in-scope records for the incident window and show what each configured control path reported. Then reconcile them against independent system and application evidence to identify uncovered actions and gaps.

Per-action records can add a bounded list of reported events to the reconstruction, but still require reconciliation with routing, system, coverage, and control-testing evidence. 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. Production is $995 a month billed annually, or $1,195 month to month, after a 14-day no-card trial, with 1,000,000 receipts a month and 12-month retention.

Enterprise is an annual agreement from $36,000. The meter is signed receipts rather than seats or agents, and verification is always free. Pricing is scoped to the deployment.

How do we start?

Create a free Starter account to inspect the currently available product surface. Separately, use the public sample record and verifier to inspect both passing checks and stated limitations. For one named customer review or consequential workflow, bring that workflow to a discussion.

Start free, inspect the sample record, or talk to us.

Is glacis.io the same company as glacis.com?

No. They are separate companies. GLACIS Technologies, Inc. at glacis.io builds supervision and operational-evidence infrastructure for consequential AI.

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

For product questions, email [email protected]. For questions about the standard, email [email protected].