Operational supervision · Verifiable evidence
Supervise consequential AI. Keep evidence of what happened.
Glacis evaluates named rules as in-scope AI actions pass through a configured control path, can allow, block, or escalate them, and emits a signed record of the policy decision and recorded outcome. In sidecar mode, protected prompts and responses can remain inside your environment.
- glc_a3f1c98e02 sha256:7bd1e94c8a…3f02 allowed
- glc_b27e4d11ab sha256:c019fb5d72…a8e1 allowed
- glc_4f0892ce6d sha256:9e5a16d8c4…b7d2 flagged
- glc_dc73a5602f sha256:b48f02ad19…5c0f allowed
- glc_91eb22a7d3 sha256:5d2c8e91b6…e304 withheld
Protected payloads can stay local
Sidecar mode
Inline enforcement
Shadow to enforce
Tamper-evident
Crypto signatures
Measured overhead
Reported per deployment
Local evaluation, portable evidence
In sidecar mode, policy evaluation can run inside your environment. The portable record can contain bounded decision metadata, hashes, and signatures rather than protected prompts or responses; the exact data path remains deployment-specific and documented in your configuration.
S3 object lock / WORM storage
Helps preserve stored logs under configured retention controls. It does not establish which control was evaluated before an AI action or whether coverage was complete.
Continuous attestation
A bounded record is generated alongside an in-scope event. It carries the configured path’s claim that named controls were evaluated and its reported outcome; verification does not, by itself, establish execution, source truth, timing, control effectiveness, compliance, safety, or complete coverage.
How it works
In a configured deployment, in-scope events can produce signed records of the rule, control decision, and recorded outcome.
Request arrives
In inline mode, a configured AI request is routed through the Glacis arbiter before it reaches the model or returns to the user. Only traffic routed through the configured path is in scope.
The configured path evaluates controls
Configured controls can include content filters, policy checks, PII detection, or consent rules. The record carries that path’s claim that named controls were evaluated and the outcome it reported; surrounding deployment evidence is needed to establish execution.
Policy enforced
The arbiter evaluates the active policy version and renders an allow, block, escalate, or flag decision. In enforcing mode, an action that matches a configured deny condition can be stopped before it reaches the model or downstream tool.
Evidence sealed
The covered fields are signed and can be linked to prior records. Signature checks can detect changes to covered fields; chain and deletion claims require the relevant reference records or an external log checkpoint.
Auditors verify
A reviewer can check the signature, covered fields, and any included chain or log evidence without accepting a Glacis verdict. Verification establishes only the checks reported; it does not establish safety, compliance, effectiveness, or complete coverage.
Deployment modes
Start in observation mode, then move to enforcement once the policy has settled.
Shadow
Observe traffic routed through the configured path, evaluate it against policy, and generate records without blocking. Use those observations to refine policy before enforcement.
Warn
Evaluate policy violations and alert on them, and generate receipts carrying the violation flags. Requests still go through, so your team can review what warn mode caught before enforcement is switched on.
Enforce
Block actions that match configured deny conditions and allow those that do not. In-scope allow and block decisions can produce signed records for later verification.
Strict
Block violations and circuit-break when violation thresholds are exceeded. For environments where policy breaches require immediate pipeline shutdown.
Failure modes
You declare how your system behaves when the arbiter is unavailable.
Fail-closed
DefaultWhen fail-closed behavior is configured, requests routed through the arbiter are denied if it is unavailable. That trades availability for requiring a policy evaluation on the configured path.
Fail-open
ConfigurableRequests proceed with a flag if the arbiter is unavailable. Availability takes priority. The unevaluated request is logged and flagged for retroactive review.
What changes in practice
The gap that matters is time. A control that was reviewed in March and an incident that happened in July are separated by four months of behavior nobody wrote down, and the record that closes a gap like that has to be produced while the system is running rather than reconstructed afterwards from memory and screenshots.
Traditional approach
- Annual audits sample a fraction of interactions
- Policies say what should happen
- Logs can be altered after the fact
- Months between control check and evidence
Continuous attestation
- In-scope events can generate bounded records
- Records identify the control decision reported for a captured event
- Cryptographic signatures make tampering detectable
- Records are generated alongside the configured event
What the record can show
A record is worth as much as the fields it binds, and no more. The categories below are the ones a configured deployment can commit to, each of them bounded by what the control path reported at the time rather than by what anyone concluded later.
Control evaluation
Which configured content, output, or escalation rules were evaluated and the result recorded for an in-scope event.
Bias testing
When included, the record can bind a named fairness check, its version, declared parameters, and reported result to the event.
Data privacy
The configured PII, masking, or access-control decision reported before an in-scope request was forwarded.
Attestation chain
Signed fields and chain links can make later modification or reordering detectable. Complete coverage requires additional reference or log evidence.
Model versioning
The declared model version and deployment identifiers can be bound into the signed record for the captured event.
Response times
Recorded latency metadata can be bound to a timestamped event. SLA assessment still depends on agreed scope and measurement methodology.
Organize records against familiar frameworks
Attestations map to the compliance frameworks your customers and regulators already reference. The mapping is an informational crosswalk, not a certification claim.
Ready to make supervision provable?
Start where AI already acts: define the intended rule, observe the control decision, and inspect the bounded record.
Related resources
Runtime coverage
Supervise one named AI workflow and inspect the evidence its configured control path produces.
The proof gap
Why documentation isn’t enough for AI compliance.
NIST AI RMF guide
Complete guide to implementing the AI Risk Management Framework.
What is AI attestation?
What signatures, covered fields, and independent verification establish, and where they stop.
AI audit guide
Preparing for third-party AI compliance audits.
Independent verification
What a third party can check, and why a valid signature is not an assurance opinion.
The evidence layer
The missing layer between security claims and verifiable proof.
Security that leaves a receipt
Runtime controls that emit signed, verifiable receipts.