What is AI Attestation?

What is AI Attestation?

AI attestation is the process of generating cryptographic, tamper-evident records that assert which named controls ran, when they reportedly ran, which parameters are covered, and what outcomes were recorded during a scoped AI operation. A valid signature supports record integrity and attribution to a key; it does not by itself prove the event occurred as claimed or that the control operated correctly.

The concept draws from established practices in software supply-chain security, where frameworks such as SLSA (Supply-chain Levels for Software Artifacts) and in-toto use signed statements about build provenance. AI attestation applies a similar record pattern to operation: it signs bounded claims about configured events rather than explaining model reasoning or establishing overall system behavior.

The Core Promise

Traditional AI compliance relies on three pillars: policies (what should happen), configurations (what is set up), and logs (what was recorded). Each has a fundamental weakness:

• Policies describe intent but do not by themselves establish execution. A privacy policy may say data is de-identified; separate operational evidence is needed to assess what happened in a covered workflow.
• Configurations show controls are enabled but don’t prove they triggered. A guardrail can be configured yet never fire if the conditions aren’t met.
• Logs record events but may lack cryptographic integrity or disclosed signer provenance. They can still be useful evidence, but a reviewer must assess how they were created, protected, and scoped.

AI attestation addresses a narrower gap: it can make a signed claim about which control was invoked, what outcome was recorded, and when. Signature and chain checks can expose later alteration of covered fields. They do not prove the control was correctly designed, that every action was captured, or that the overall system was safe or compliant.

Formal Definition

An AI attestation is a cryptographically-signed, timestamped record asserting that a specific AI control or set of controls ran with defined parameters and reported defined outcomes during a specific covered operation. The attestation:

• Can be generated on the configured path as a covered control reports its outcome
• Includes a cryptographic signature that makes later changes to covered fields detectable
• May be linked to prior attestations, making certain changes within the presented chain detectable
• Can be checked by third parties against disclosed keys, while the truth of the signed claim still requires separate evidence

The Verification Vacuum

AI attestation matters now because AI compliance has a structural problem that policies, configurations, and logs do not solve between them. Call it the verification vacuum.

Consider a healthcare AI system processing patient data. The organization has:

• A BAA with the AI vendor
• Policies requiring PHI de-identification before LLM processing
• A de-identification module configured in the pipeline
• Logs showing the de-identification service was called

Now an auditor asks: “For the 50,000 patient interactions last month, can you prove PHI was de-identified before reaching the LLM for each one?”

The organization cannot answer from those artifacts alone. The logs show the de-identification service was called, but not that it succeeded for every field. The configuration shows de-identification is enabled, but a bug could have bypassed it. The policy describes intent rather than the result of a specific operation.

This is the verification vacuum: the gap between what an organization says its AI system should do and the bounded evidence it can produce about actual operation.

Why Traditional Approaches Fail

What Regulators Now Expect

The verification vacuum matters more as regulations mature. EU AI Act Article 12 requires high-risk AI systems to support automatic recording of events and traceability. Whether a particular logging or attestation design satisfies applicable obligations depends on the system, its classification, implementation, and legal analysis; a signature alone does not answer that question.

Similarly, when enterprise customers send AI security questionnaires asking “How do you ensure PII is protected in AI processing?” they increasingly want evidence, not assurances. The answer “we have a policy” is no longer sufficient.

How AI Attestation Works

AI attestation systems can operate alongside configured AI controls and record stated outcomes. A representative technical flow follows; exact fields, timing, and trust boundaries depend on the deployment.

Step 1: Control Execution Observation

When a request follows a configured path, controls may run: content filters, PII detectors, guardrails, bias checks, or consent verifiers. The attestation component can capture selected fields reported by that path:

• Control identifier: Which control the record says ran
• Reported event time: The time value asserted by the configured path
• Input hash: Cryptographic fingerprint of input (not the input itself)
• Configuration identifiers: The version or parameter references reported for the event
• Outcome: Pass/fail/warning and any actions taken

Step 2: Attestation Record Creation

The observed data is assembled into an attestation record. This record is then:

• Time field included as a reported claim; trusted-time proof requires a separately disclosed and verified timestamp or external anchor
• Signed with a private key controlled by the attestation system
• Chained to the previous attestation record via hash linking

When each attestation includes the hash of a previous record, changes to covered fields or links within the presented sequence become detectable. A chain does not show that an event omitted before signing ever existed, and deletion detection depends on retained records, expected sequence information, or an external commitment.

Step 3: Storage and Verification

Attestation records are stored in tamper-evident storage. When verification is needed (audit, customer request, regulatory inquiry), the chain can be validated:

• Each signature can be verified against the public key
• Each chain link can be verified by recomputing hashes
• Timestamps can be verified against the time source

Verification lets a reviewer check supported signatures, covered fields, timestamps, and chain links against disclosed keys or time sources. Those checks reduce reliance on an editable narrative; they do not eliminate trust in key custody, source systems, signer honesty, scope declarations, or organizational relationships.

Attestation vs. Logging vs. Monitoring

AI attestation is often confused with logging and monitoring. While related, they serve fundamentally different purposes.

Why Logs Aren’t Enough

Organizations often say, “We already log everything, isn’t that sufficient?” Consider what an auditor examining those logs has to accept on faith:

• The logs haven’t been modified since creation
• No log entries have been deleted
• No fake entries have been inserted
• The logging system didn’t miss any events
• The timestamps are accurate

With attestation, an auditor can independently test signatures and chain links instead of accepting record integrity solely on assertion. The auditor must still assess whether the records are complete, whether the source claims are truthful, and whether the control was effective.

Why S3 Object Lock Isn’t Enough

Some organizations use WORM (Write Once Read Many) storage such as S3 Object Lock as part of an evidence architecture. Its retention controls address a different set of properties from signed operational attestation.

Properly configured WORM storage can make later modification of stored logs detectable or prohibited under its retention controls. It does not establish:

• The logs were accurate when written
• The source claim about control execution was truthful
• No events were omitted before writing

An attestation component can sign a claim as a configured event is reported. WORM storage protects a stored record under its configured retention controls. The two are complementary but neither establishes source truth or complete coverage on its own.

What Control Claims You Can Record

AI attestation can record claims and reported outcomes for controls integrated into the covered path. The meaning of each field depends on the control and source system. Common categories include:

Regulatory Drivers

Multiple regulatory frameworks address logging, traceability, documentation, monitoring, and audit controls. Scoped signed records may contribute to an evidence package, but no attestation format is automatically necessary or sufficient for compliance.

EU AI Act Article 12: Logging and Traceability

Article 12 of the EU AI Act requires high-risk AI systems to have “automatic recording of events (’logs’)” that enable:

• Tracing of system operations throughout the lifecycle
• Monitoring of system operation with respect to risk
• Post-market monitoring and incident investigation

Article 12 specifies capabilities and content for logging high-risk AI systems. Signed operational records may support integrity and traceability for selected fields, but satisfying Article 12 depends on the applicable system, required log content, lifecycle processes, and legal assessment. A receipt on its own does not settle it.

Deadline: the AI Omnibus entered into force on July 27, 2026. Relevant high-risk obligations apply from December 2, 2027 for Annex III systems and August 2, 2028 for Annex I product-embedded systems.

Colorado: Automated Decision-Making Technology (SB 26-189)

Colorado’s original AI Act (SB 24-205) was repealed and replaced before it took effect. Governor Polis signed SB 26-189, the Automated Decision-Making Technology Act, on May 14, 2026; its substantive obligations commence January 1, 2027. The earlier “June 30, 2026” date and the “high-risk AI system” framework no longer apply. The law now regulates covered automated decision-making technology (ADMT), meaning technology used to materially influence a consequential decision in domains such as employment, housing, lending, insurance, health-care services, and education. Under SB 26-189, developers and deployers must keep records (retained at least three years) and provide disclosure, including:

• Clear-and-conspicuous notice before a covered ADMT is used to materially influence a consequential decision
• A plain-language disclosure, within 30 days of an adverse outcome, of the ADMT’s role and the consumer’s rights
• On request, data correction and meaningful human review of the decision

The earlier reasonable-care duty against algorithmic discrimination, mandatory risk-management programs, and annual impact assessments were not carried into SB 26-189. When consumers exercise applicable rights, scoped operational records may contribute to an account of how a covered interaction was handled; they do not establish legal compliance or control effectiveness on their own.

HIPAA: Audit Controls for AI Processing PHI

HIPAA’s Security Rule (45 CFR 164.312(b)) requires “hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.”

When AI systems process electronic protected health information, an evidence review may examine whether the deployment can account for claims such as:

• De-identification executed before data reached the model
• Access controls enforced for each interaction
• Minimum necessary principle applied

Neither a traditional log nor a signature alone establishes that de-identification succeeded. A stronger evidence package can combine scoped signed records with control validation, test results, data-flow review, and coverage accounting.

NIST AI RMF: Continuous Monitoring

The NIST AI Risk Management Framework recommends organizations “continuously monitor AI systems for changes that may impact trustworthiness” and maintain “documentation of AI system behavior.”

The framework’s Govern function addresses documentation and accountability structures. Attestation can be one technical input to that work; it does not satisfy the framework or establish trustworthiness by itself.

Deployment Modes

Organizations implementing GLACIS attestation choose between two deployment modes based on their AI architecture:

Sidecar Mode (Inside Your VPC)

GLACIS can run as a sidecar or embedded component alongside AI workloads inside the operator’s infrastructure. The evidence scope is limited to the configured paths that pass through that component; deployment review must identify any paths that bypass it.

When to use:

• Complex multi-agent systems with internal agent-to-agent communication
• Custom GPU clusters or on-premises AI infrastructure
• Distributed AI workloads across multiple services
• Requirements to keep protected payloads inside a defined trust boundary

Pros: Local control execution, an explicit evidence boundary, and deployment-specific visibility into configured paths

Cons: Requires infrastructure integration, deployment complexity

Proxy Mode (External)

GLACIS can deploy as a proxy at a defined chokepoint. This is suitable only when the relevant AI interactions are routed through that point and the team can identify and monitor bypass paths.

When to use:

• Simple API shielding with single chokepoint (e.g., OpenAI API wrapper)
• Cloud-hosted applications with external AI service calls
• Simpler deployment requirements

Pros: A simpler integration surface and a clearly defined control boundary for routed traffic

Cons: Covers less of a distributed internal system, and depends on network routing

Core principle: configured supervision and evidence

On configured, routed paths, GLACIS can connect an intended rule to a selected control decision, such as allow, block, or escalate, and preserve a signed report of the covered event. That scope must be tested: neither deployment mode eliminates bypass paths, proves complete capture, or establishes that the control was effective.

Key Implementation Considerations

Frequently Asked Questions