AIUC-1 · technical evidence

Five evidence items, from one line of configuration.

AIUC-1 is a certification standard for AI agents, audited by accredited firms and published openly at aiuc-1.com. Its technical evidence list asks a company to hand an auditor proof of what its AI systems did. This page maps a Lyntway receipt against those items — including the ones it does not cover.

E015.4satisfied

Log integrity protection

The standard asks for: Write-once-read-many storage, cryptographic hashing, append-only databases, or tamper-evident log mechanisms ensuring immutability.

Every receipt is signed with Ed25519 over an RFC 8785 canonical form and chained to the one before it by digest, so a record removed from the middle breaks the chain. Digests are appended to an RFC 9162 transparency log and anchored to an RFC 3161 timestamp authority outside this service. WORM storage and an append-only database both satisfy this control while leaving the operator in control of the system; a signed receipt is checkable by the auditor without trusting the company being audited.

E015.1satisfied

System activity capture

The standard asks for: Logging inputs, processing steps, outputs and metadata for AI systems.

One receipt per governed action, on both the request and the response leg, recording the surface, the destination, the method, what was detected, what was done about it and under which ruleset. The direction is recorded because a tool result on its way into the next prompt is a different event from a prompt on its way out.

A008.5satisfied

Secrets redaction logs

The standard asks for: Log redaction rules and masking logic applied to stored artifacts before persistence.

The ruleset that matched is named in the receipt. Substitution is format-preserving for card numbers, email addresses, phone numbers and IP addresses — a substituted email is still a valid email, a card still passes a Luhn check, though printed spacing is not kept — so the downstream system behaves normally while the real value never leaves. Other classes, IBANs among them, are replaced by an opaque labelled placeholder such as LYNT_PCI_IBAN_… that nothing downstream can mistake for a real one. Credentials at high confidence are refused outright rather than masked.

B005.4satisfied

Input filtering logs

The standard asks for: Logging system showing how flagged inputs are captured, with metadata inclusion and audit trail documentation.

Findings carry a dotted class, a count and the detector that matched. A deterministic rule names itself, so anyone can re-run it on the same text months later and get the same answer; a model-formed opinion is labelled as one and is not presented as reproducible.

E015.2partial

Agent execution chains

The standard asks for: Agent provenance metadata per execution, tool call parameters and results, delegation chain records, approval events and reasoning traces for agentic workflows.

Provenance is a first-class field on every receipt, and MCP tool calls are recorded on their own surface with the parameters and the result. Delegation chains between agents and reasoning traces are not captured — this service governs content crossing a boundary, not an agent's internal deliberation. Claiming this control in full would be the kind of overstatement the receipt format exists to prevent.

Stated rather than left to be discovered

What this page is not.

Lyntway is not AIUC-1 certified.

We hold no certification of any kind — no SOC 2, no ISO, no independent penetration test. What is described above is evidence a certified company produces for its own audit, not a credential of ours.

This is a reading of a public standard, not an endorsement.

AIUC-1 is published openly and this mapping is ours alone. Neither AIUC nor any accredited auditor has reviewed or approved it. Your auditor decides what satisfies a control, and they may read it differently.

Most of the standard is elsewhere.

AIUC-1 spans data and privacy, security, safety, reliability, accountability and societal risk. The technical evidence list alone runs well past these five items — log retention platforms, access monitoring, incident tracking and third-party testing are all somebody else's job.

Who holds the key changes what a receipt proves.

On the hosted service we derive your signing key, so a receipt proves the record is unaltered — and, because we are not you, that you did not alter it. Self-hosted you hold the key, which is the stronger answer to a data-residency question and the weaker one to an auditor, since the party being assessed then controls the signature.

Check a receipt before you take any of this on trust.

The argument on this page is that an auditor should not have to believe a vendor. That applies to us. Generate a receipt and verify it yourself — four commands, no account, and the verification runs on your machine.

Verify a receipt How it works