AI Governance Means Signing the Authority, the Data, and the Graph

The missing object in AI governance is not better logs. It is a Decision Attestation Package — a signed, portable bundle that proves what was authorised, what was observed, and what machinery produced the outcome.

Scott Farrell | LeverageAI | March 2026

Your AI Made a Decision Last Tuesday

Can you prove it was authorised?

Not explain. Not reconstruct from logs. Not assemble a narrative from database entries, Slack messages, and committee meeting minutes.

Prove.

If you paused, you have company. Only 28% of organisations can reliably trace agent actions back to a human sponsor. 80% cannot tell in real time what their agents are doing or who is responsible.¹

Four independent authorities converged on the same structural gap in the same twelve-month window. NIST explicitly asked: “How do we ensure non-repudiation for agent actions and binding back to human authorization?”² Gartner named Digital Provenance a 2026 Top Strategic Technology Trend, predicting billion-dollar sanction risks for those who fail to invest.³ The EU AI Act hits full enforcement in August 2026 with penalties reaching 15M euros or 3% of worldwide turnover.⁴ And McKinsey called 2026 “the year of tackling the foundational enablers required to build, govern, and operate agentic workflows.”⁵

None of them are coordinating. They all arrived independently at the same hole in the floor.

This article names the missing object — and gives it a structure.

The Problem: Governance That Lives Outside the Decision

Most organisations deploying AI into consequential workflows — claims processing, credit decisions, compliance checks — govern those decisions the same way they’ve always governed everything: separately.

Policies live in SharePoint. Dashboards live in Grafana. Authority delegations live in meeting minutes. Audit trails live in log databases. The decision itself lives somewhere else entirely.

And every one of those governance artefacts can be separated from the decision it claims to govern.

“Audit logs record what happened — but can be modified after the fact. Signed commits prove what happened, with cryptographic binding to the author and timestamp.”

— SLSA Provenance / Legit Security⁶

ISACA put it plainly in 2026: “Every answer produced by an AI system should be traceable to an authenticated request, authorized data, enforced controls and auditable evidence.”⁷ Notice the word traceable. Not “reconstructable.” Not “probably somewhere in the logs.” Traceable — with a path you can follow from outcome to authority without forensic archaeology.

Here is the current state of AI governance at most mid-market organisations:

Compare this with what a regulator, auditor, or insurer will actually ask:

“For decision #47291 — the one the customer is disputing — can you prove the AI had authority to act, the data it observed was authentic, the policy in force at the time was evaluated, and the deterministic code that executed the outcome was the code you intended?”

That question requires a different kind of answer. Not a narrative reconstructed from logs. A receipt.

Three Signatures, Not One

AI governance is not one signature on one document. It is three cryptographic commitments, each proving something different.

1. Signed Authority

What it proves: Who was allowed to decide, under what delegation, within what scope, at what risk tier.

Most organisations assume authority exists because someone approved a project in a committee meeting. But authority that is not validated at runtime is not authority — it is a laminated promise card floating through the system.

The Authority Attestation records: the delegating principal, the role and mandate applied, scope limits, risk thresholds, expiry conditions, jurisdiction, and whether human approval was obtained for this specific decision class.

2. Signed Data

What it proves: What the system actually observed at the moment of decision — not what was available, but what was consumed.

The Observation Attestation records: cryptographic hashes of input documents, pointers to immutable evidence stores, feature-set digests, data classification labels, and the timestamp of observation. This is not a description. It is a cryptographic commitment: “These exact bytes entered this decision.”

3. Signed Graph

What it proves: What reasoning machinery produced the outcome — the AI judgements, the policy evaluation, and the deterministic code that assembled everything into a binding action.

This is the distinctive signature. Signing authority and data are at least conceptually familiar. Signing the graph is the architectural move.

“The graph” captures:

• AI micro-judgements — what each model node proposed, with what confidence, against what evidence
• Policy-as-code evaluation — what rules the IPA (In-Path Authority) checked at runtime and what it decided
• Deterministic assembly — the traditional code that consumed AI proposals and policy outcomes to produce the binding result
• SDLC provenance — that the code which ran was the code that was tested, reviewed, and deployed through governance

McKinsey’s framing captures why the graph matters: “Agency isn’t a feature — it’s a transfer of decision rights.”⁸ When a system acts, the question is not whether the model was accurate. The question is who is accountable when the system acts — and the graph is where that accountability lives.

The Decision Attestation Package

These three signatures are not separate documents filed in three different systems. They are layers of a single portable object: the Decision Attestation Package.

A governed AI decision is not complete when the model produces a judgement. It is complete when the judgement, authority, policy evaluation, and execution outcome are bound into one signed attestation package.

Seven sections. One bundle. Born at decision time.

The governing principle: every consequential step emits a signed artefact. Only deterministic, policy-aware machinery may convert those artefacts into action. The final action emits its own signed artefact that links back to all upstream ones.

Authority Is Potential. Policy Evaluation Is Activation.

Most governance architectures treat authority and policy as separate concerns. Authority is delegated in a meeting. Policy is written in a document. Neither is evaluated against the other at the moment the decision executes.

This is the gap. Authority without runtime policy evaluation is potential energy that never converts to kinetic energy. It exists on paper but is never validated against the actual decision being made.

The IPA — the In-Path Authority layer — closes this gap. It is a deterministic enforcement layer that sits between AI proposals and execution. It does not reason or infer. It evaluates conditions against policy rules.⁹

What the IPA contributes to the Decision Attestation Package:

1. Checks delegated authority against the specific action being proposed
2. Evaluates policy-as-code rules at runtime — not aspirational policy, executable policy
3. Emits a signed Policy Decision Attestation recording what was checked and what was decided
4. Gates execution: ALLOW / PAUSE / DENY with machine-readable reason codes

This is not slow. Advanced platforms implement governance checks in parallel with inference requests at sub-millisecond latency.¹⁰ AWS Bedrock AgentCore enforces Cedar policies deterministically outside the LLM reasoning loop — “the gateway enforces it at runtime before the action executes.”¹¹

The latency objection is a 2023 excuse applied to 2026 infrastructure.

Without the Policy Decision Attestation in the package, you can prove what was decided but not whether it was permitted. That distinction is the difference between a receipt and a narrative.

The Supply-Chain Template

This is not a greenfield design exercise. The software supply-chain world solved this structural problem years ago — and the tooling is now mature enough to adapt.

SLSA (Supply-Chain Levels for Software Artifacts) defines provenance as “the verifiable information about software artifacts describing where, when and how something was produced.”⁶ The provenance model records the builder’s actions, the recipe executed, external inputs, environmental parameters, and all materials consumed. SLSA 1.2 was released in December 2025, expanding beyond the build phase.¹²

in-toto provides the attestation format — a fixed, lightweight Statement that binds metadata to an artefact using context-specific Predicate schemas.¹³ The four-layer structure (Predicate, Statement, Envelope, Bundle) is domain-agnostic. Critically, in-toto explicitly supports custom predicates for any use case — the community review process allows proposing new predicate types.¹³

Sigstore makes signing practical through keyless, ephemeral certificates. It is now integrated with NPM, PyPI, Maven, GitHub, Homebrew, Kubernetes, and NVIDIA’s NGC model catalogue.^14,15 NVIDIA has been cryptographically signing all models in the NGC Catalog since March 2025.¹⁵ The model-transparency project hit v1.0 in 2025.¹⁶

The adaptation to business decisions is conceptual, not technological. Translate SLSA into decision systems and you get: not just “what software was built,” but “what decision was built, from what evidence, under what authority, through what policy gate, with what outcome.”

SLSA defines four maturity levels — from no provenance (Level 0) through signed, tamper-evident provenance (Level 2) to full build isolation with non-falsifiable attestations (Level 3).⁶

Most organisations deploying AI are at Level 0. They have logs — mutable, modifiable, deletable. The Decision Attestation Package targets Level 2 as the practical starting point for consequential decisions.

Deterministic Code Needs Governance Too

AI governance conversations focus almost exclusively on the AI. What about the code that acts on the AI’s output?

The accountable event in most regulated systems is not “the AI thought something.” It is “the system acted.” The claim was approved. The credit was extended. The compliance flag was cleared. Those actions are executed by deterministic code — and that code needs its own governance proof.

But the proof it needs is different.

AI nodes need epistemic proof: was the reasoning sound? Were the right evidence inputs consumed? Did the model operate within its validated domain?

Deterministic code needs control proof: was the action authorised? Was it bounded? Was it executed under the right policy version? Did the code that ran match the code that was tested and reviewed?

The Outcome Attestation — the deterministic node’s signed receipt — records which inputs it accepted, which upstream attestations it validated, what policy version it applied, whether the caller had mandate, and what result it produced.

That second receipt is not redundant. It is the binding explanation of control. The AI receipt says, “Here is what was inferred.” The deterministic receipt says, “Here is why this became an actual business outcome.”

For auditors and regulators, the Outcome Attestation is often the most important artefact in the package. It is the point where the system crosses from analysis into action.

Layered Receipts: How the Stack Works

The Decision Attestation Package is not a monolith. It is a stack of signed receipts, each produced by a different layer of the decision pipeline.

At the bottom, an AI micro-judgement node emits a receipt:

• Subject: what narrow question was answered
• Evidence set: hashes and references to the observed records
• Model identity: version, prompt-policy profile, inference config
• Output: structured decision object with confidence, uncertainty fields, failure flags
• Signature from the execution environment + timestamp

The IPA layer emits its receipt:

• Authority claim consumed and validated
• Policy set and version evaluated
• Inputs presented to the policy engine
• Gate outcome: ALLOW / PAUSE / DENY + reason codes
• Signature from the policy engine + timestamp

The deterministic assembly layer emits the final receipt:

• Upstream attestations consumed (AI judgement + policy decision)
• Signatures validated from upstream layers
• Policy version applied, rule set executed
• Outcome produced, action taken
• Signature from the deterministic execution environment + timestamp

These three receipts, plus the observation envelope and the package-level signature, form the Decision Attestation Package. Each layer signs its own output. The deterministic code brings them together.

This is the decision-control provenance — a provenance type that does not yet have a formal standard. Data provenance covers where data came from. Model provenance covers what model produced an output. Decision-control provenance covers who was allowed to act, what policy validated that authority, and what deterministic code executed the outcome. It is the missing layer.

What Existing Audit Approaches Are Missing

Governance frameworks already exist. SOC 2, SR 11-7, ISO 42001 all define what organisations should prove about their AI systems. The gap is not what but how — and specifically, how to make proof inseparable from the decision.

SOC 2 auditors increasingly flag AI-driven actions as accountability gaps. When an AI agent takes a privileged action without a documented human request, auditors treat it as a control failure — because SOC 2 expects privileged actions to be attributable to an accountable individual, not a generic system account.¹⁷

SR 11-7 (the Federal Reserve’s model risk management guidance) requires documentation detailed enough that unfamiliar parties can understand the model’s operation — yet only 44% of banks properly validate their AI tools.^18,19

ISO 42001 audits cluster on auditability failures — AI decisions that cannot be reconstructed or justified to auditors.²⁰

Each of these frameworks defines outcomes — what governance should demonstrate. None specify a runtime evidence format that makes governance inseparable from the decision itself. They define the destination but not the vehicle.

The Decision Attestation Package is that vehicle. It does not replace SOC 2, SR 11-7, or ISO 42001. It provides the runtime evidence format those frameworks implicitly assume but never specify.

The Convergence Window

The urgency is not theoretical.

EU AI Act full enforcement begins August 2026 — five months from now. Article 12 requires high-risk AI systems to automatically log events enabling traceability, with logs that are tamper-resistant and operate automatically.²¹ First enforcement actions are expected in the 10-30M euro range.⁴

Gartner predicts that by 2029, organisations that failed to adequately invest in digital provenance capabilities will face sanction risks running into billions of dollars.³

Cyber insurance carriers are introducing “AI Security Riders” — coverage conditioned on documented evidence of adversarial red-teaming, model-level risk assessments, and specialised safeguards.²² Governance that cannot demonstrate runtime enforcement may void coverage when it matters most.

80% of organisations have already encountered risky behaviour from AI agents.⁸ McKinsey’s assessment: “In the agentic organization, governance cannot remain a periodic, paper-heavy exercise. As agents operate continuously, governance must become real time, data driven, and embedded.”²³

The infrastructure to solve this exists. Supply-chain attestation is production-grade. Policy-as-code enforcement runs at sub-millisecond latency. What is missing is the output format — the Decision Attestation Package that makes governance a co-product of the decision, not a parallel activity.

Start With the Outcome Attestation

You do not need all seven sections on day one.

You need the architecture that makes all seven possible. And the place to start is where the risk lives: the Outcome Attestation — the signed receipt from the deterministic code that actually caused something to happen.

That receipt answers the regulator’s question: “What did the system do, under what authority, with what policy in force?”

Work backwards from there. Add the Policy Decision Record (what rules were evaluated). Add the Authority Envelope (who delegated). Add the Observation Envelope (what data was consumed). Add the Judgement Envelope (what the AI proposed).

Each layer you add makes the package more complete, the audit faster, and the governance more structurally sound.

The decision that carries its own proof does not need a committee to reconstruct what happened. It does not need a forensic investigation. It does not need hope that the logs are sufficient.

It has a receipt.