The Governance Gap Between the Model and the Vendor

Here is a failure mode the industry keeps meeting. A small group gains access to a restricted AI model through a third-party vendor environment and uses it for weeks. The access comes to light not through anyone's audit trail but through screenshots shared in a private chat and shown to a reporter. The provider can say only that the access went through one of its vendors.

The most revealing part of that story is what serves as evidence of the incident, not the incident itself.

Screenshots and demonstrations can be evidence, but their provenance and context need checking. Access logs, identity records and corroborating observations remain important. A signed decision export can add a check of retained values against an expected key; it does not by itself identify a person, establish wall-clock time or validate the whole account.

This is an industry problem, not one company's.

Model behavior and access controls are different tasks

Behavior evaluations and access-control reviews ask different questions. A model may behave as designed while someone uses a leaked credential. That possibility does not make model-safety work misplaced, nor does a signed record replace credential protection or incident response.

The task is to establish identity, authority and the sequence of recorded access across the organizations involved. Existing identity and logging systems may supply substantial parts of that evidence. AGA must be assessed alongside them, not assumed to fill an otherwise empty category.

Frontier models are increasingly deployed through multi-tenant vendor environments, with access gated by credentials that can be leaked, shared, transferred, or misused. A restricted program may grant access to a dozen named partners and dozens more organizations, each employing thousands of people and maintaining its own vendor relationships. The trust boundary cascades through at least four layers (provider, customer, contractor, and end user) before anyone touches the model.

Consider a hypothetical failure: a contractor's credentials for a vendor-hosted environment leak, and unauthorized use begins. If the parties retain only separate, mutable records with no shared verification path, investigators face a reconstruction problem. Deployments with protected audit trails, identity records or independent collection have different evidence available. The example does not establish what every vendor retains.

Workload identity, supply-chain attestation, signed logs and write-once storage address related tasks. Their guarantees differ. The comparison should ask what a particular export binds, how the recipient obtains the expected key, and what collection and identity assumptions remain.

If the only retained evidence is a mutable record controlled by a party under investigation, a reviewer has a corroboration problem. Independent collection, protected storage or retained signed copies may help. Whether a deployment uses those controls must be checked directly.

Where the Rules Are Heading

A cross-organization investigation needs records that the parties can exchange and evaluate. Access controls, audit logs and contractual duties each contribute; a portable signed record can add a check of the exported data against an expected key.

Evidence requirements depend on the system, organization and applicable rules. AGA is not a compliance determination. Its narrower contribution is an exported record that a reviewer can check without access to the producing system. Whether that reduces review time is a question to test with a reviewer, not an established outcome.

What Verifiable Evidence Actually Requires

The architectural requirements already appear in the cryptographic literature, in adjacent deployed systems, and in standards work. Two of them are load-bearing.

A recorded decision at the access boundary. Specify whether the record contains an authorization decision, an observed action or both. Under a pinned expected key, a changed signed value fails verification unless the key holder re-signs it. AGA keeps the receipt chain in memory until export, so retention outside the gateway process is a separate requirement.

Offline verifiability. A reviewer can check a retained bundle against an expected key without contacting the producer. This reduces dependence on continued access to the vendor's systems. It does not eliminate trust in collection, key custody or retention, and the key holder could re-sign a changed history. Signed logs can offer similar integrity properties. Compare the exported formats and checks, using a verifier whose code you can inspect, such as aga-verify.

AGA combines individual signed decisions, hash-linked receipts and argument hashes. These are format choices, not proof that signed batches or other logging designs are inadequate. Changing signed fields is detectable against an expected key unless the key holder re-signs. Argument hashes let a verifier check the record without the original arguments; other fields can still disclose information. The specified canonical JSON construction defines the bytes that compatible implementations must verify, with version and conformance limits documented in the specification.

These are established primitives: Ed25519 signatures, SHA-256 hashing and Merkle inclusion proofs. AGA combines them in an MCP gateway and a portable evidence format. Other systems also use signed audit records; the useful comparison is the precise record, trust boundary, export format and verification behavior, not a claim of category exclusivity.

The tradeoff is operational work: key management, export retention and a review process. Existing logging also needs security and storage controls. Not every deployment needs a separate offline bundle. Test whether it answers a real reviewer question before adding another evidence system; signing a later reconstruction does not turn it into a contemporaneous record.

Disclosure

I have been working on this problem for eighteen months. Attested Governance Artifacts (AGA) implements part of the architecture described above. The published gateway, aga-proxy, decides each MCP tool call at the boundary and does not forward one it denies. Its default profile, permissive, denies nothing on policy grounds; policy denial needs --profile standard or restrictive, or a --policy file in allowlist or denylist mode. It signs each decision into a hash-linked receipt (known issue 7 on /security describes the exceptions), commits arguments by hash, and exports evidence bundles that verify offline. A bundle file that repeats a field name still verifies, because the verifiers read the last copy (known issue 5 on /security). The patent application was filed with the USPTO in December 2025. The ML-DSA-65 (NIST FIPS 204) hybrid composite is implemented and cross-verified as a library export, and Ed25519 is the live signature.

AGA does not address model-behavior risks; those are the right focus of alignment research. It addresses the adjacent problem: when an AI system does something consequential through a governed tool call, can anyone check what was decided and under which policy? If your organization deploys AI where that question will be asked in an audit or an incident, this is the conversation to have now, while the architecture decisions can still be remade.

The Pattern Ahead

Vendor chains can make an investigation difficult because access, credentials and records are distributed across organizations. Some deployments retain strong identity and audit trails. Others leave gaps. The evaluation question is what a particular deployment can substantiate from its retained records.

The people behind one such episode said they were only curious about new models. That framing won't last. Future incidents will involve a more consequential actor or a more consequential use, and the question afterward will be the one that cannot be answered today: who did this, through which credentials, and how do we know?

A retained AGA bundle can show recorded gateway decisions and signed timestamp values under a pinned key. It does not independently establish wall-clock time or identify the person behind a call. Strong identity records and operational logs remain necessary context.

The model-safety investment of the last two years was necessary. It was never going to be sufficient on its own. The governance question now is not only whether models behave correctly, but whether anyone can show, to a standard that survives hostile scrutiny, what they were used for and by whom.