Questions we get asked

What does Glacis actually do?

Glacis connects an intended rule to the point where a consequential AI workflow acts. Configured controls can allow, block, escalate, or flag an in-scope action, and supported events can produce an OVERT-compatible signed record of what the control path reported.

The record is bounded evidence: a signature can bind its covered fields and make later alteration detectable. It does not by itself prove complete coverage, control effectiveness, safety, legal compliance, or a model’s internal reasoning.

Is this an AI observability product?

Observability tells you what your system did, in records your system wrote about itself. That is genuinely useful for operating a service, and it is weak as evidence, because the party under examination produced the record and could have amended it.

A signed operational record is a different category of artifact. A third party with the record and applicable key material can check its covered signatures and hash commitments without asking Glacis to make the decision. It sits underneath observability rather than replacing it.

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

Compliance-automation tools help manage programs, policies, and evidence requests. Glacis addresses a narrower operational question: for a configured AI action, what control path ran, what did it report, and what bounded record remains? The categories can be complementary.

Is this a guardrails product?

There is a guardrail in it. Local controls can allow, block, redact, restrict, escalate, or require review before risky behavior reaches a workflow, a tool, a record, or a customer.

What separates it from a guardrail library is the second half: covered decisions can leave a signed record that someone outside your company can check. The record reports what the configured control path did; reviewers still have to examine scope, configuration, and whether the control was appropriate.

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.

When record generation is configured for an in-scope event, the resulting artifact should state the action, control, outcome, and scope it covers. Actions outside the instrumented boundary remain outside the evidence; silence is not proof of coverage.

What data crosses the deployment boundary?

It depends on the deployment. In customer-hosted sidecar mode, policy evaluation and record generation can run inside your environment, with a portable record containing bounded decision metadata, hashes, and signatures rather than protected prompts or responses.

The actual data path, operational telemetry, and any authorized processing are defined by the configuration, Order Form, and DPA. Treat “zero egress” as a claim to verify for a specific architecture, not as a universal slogan.

Where do the controls run?

Controls can run beside the model or agent in a customer-hosted sidecar, or at another documented action boundary selected for the deployment. For an ambient clinical 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 and stop. The record and the evidence pack must state that boundary and any exclusions.

What is actually in a receipt?

Fields vary by the applicable OVERT version and profile. A supported record can include a record identifier, named workflow, timestamp, reported control outcomes, cryptographic commitments, signatures, scope information, 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 fields and limitations in the sample evidence pack.

Who can verify a receipt, and what do they need from us?

A third party with a supported record and the applicable verification material can run the checks at verify.glacis.io. The browser verifier reports which signatures, hashes, fields, and supported chain proofs it actually checked.

A pass establishes only those checks. It does not establish that every event was recorded, that a reported control was effective, or that the system was safe or compliant.

What does “witnessed” mean, and is every receipt witnessed?

Not every receipt, and the difference is worth being precise about.

A self-signed record carries an operator signature. A witnessed record also carries a recognized countersignature or supported transparency evidence. The verifier distinguishes those states and 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 is OVERT?

OVERT is the open standard the receipts are written to: the schema, the signing rules, and the verification procedure. It is published at overt.is, so a receipt is not a proprietary Glacis blob.

An auditor, a customer, or a competitor can implement a verifier from the specification and check your receipts without our involvement. That is the point of writing it down in public.

Does this make us compliant with the EU AI Act, ISO 42001, or the NIST AI RMF?

No. Those frameworks and laws address policy, ownership, risk, documentation, controls, testing, and other obligations. For configured in-scope events, Glacis can contribute operational records to the wider evidence set; it does not classify a system, certify safety, or establish compliance.

EU AI Act Article 12 requires automatic logging capabilities appropriate to covered high-risk systems. Signed, scoped records may support part of that design when their fields and coverage are relevant. Evidence-pack mappings to NIST AI RMF, ISO 42001, the EU AI Act, or OSCAL are navigation aids for reviewers, not proof that a requirement is satisfied.

Our buyers send AI security questionnaires. Does this help?

Many AI security reviews ask where data flows, where controls run, what happens on an exception, and what record remains for a specific decision. A SOC 2 report or architecture diagram may be relevant, but it does not answer every workflow-level question.

A bounded operational record can support those rows with inspectable evidence. It does not replace the buyer’s diligence or guarantee acceptance.

How do we try it?

Start free to inspect the currently available product surface. Separately, use the public sample record and verifier to see what a supported record establishes and leaves open.

For a consequential production workflow, talk to us about the intended rule, action boundary, control path, evidence scope, and reviewer.

What does it 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, with 1,000,000 receipts a month, 12-month retention, and a 14-day trial that needs no card. Enterprise is an annual agreement from $36,000.

The meter is signed receipts rather than seats or agents. Pricing is scoped to the deployment.

Is Glacis (glacis.io) the same company as Glacis (glacis.com)?

No. They are two different companies, both based in Seattle, and search engines and AI assistants routinely merge the two into a single entity.

We are GLACIS Technologies, Inc. at glacis.io, building supervision and operational-evidence infrastructure for consequential AI. Glacis at glacis.com is a separate business. Our other domains include overt.is, docs.glacis.io, trust.glacis.io, app.glacis.io, and verify.glacis.io.