July 28, 2026

The Agent You Can’t Audit: Why Agentic AI Needs a Hardware Root

Below the API — Part 1

By lei zhou

8 min read

There is a structural rule that functional safety engineers learned the hard way in the 1990s, that automotive architects encoded into ISO 26262, and that AI security researchers have rediscovered empirically through a decade of broken guardrails: enforcement cannot live in the same failure domain as what it enforces.

In hardware safety, this is the Freedom from Common-Cause Failures requirement. A safety monitor that shares failure modes with the system it monitors provides no safety guarantee — it only provides the appearance of one. The enforcement element must be structurally independent of what it constrains.

In AI security, the same lesson arrived through evidence rather than standards. LLM judges evaluating LLM agents share correlated failure modes with the agents themselves. Probabilistic supervision of probabilistic systems cannot provide a deterministic lower bound for security. Adding more probabilistic layers does not compound to a guarantee.

Two communities. Independent routes. The same structural conclusion.

What I want to explore here is how this principle applies to the accountability stack the industry is building for agentic AI in 2026 — layer by layer, evaluating each against the same question: does this enforcement mechanism live inside or outside the failure domain of what it enforces?

The answer reveals something the vendor blogs and standards documents don't say explicitly, because each one only describes its own layer.

The question that matters

When an AI agent takes a consequential action — writes a file, calls an API, executes a transaction, modifies infrastructure — three questions follow immediately for anyone responsible for that system:

Who authorised this? What exactly did it do? Can I prove that to someone who doesn't trust me?

The third question is the one that exposes the architecture. It's easy to produce a log. It's much harder to produce a log that a regulator, auditor, counterparty, or insurer can verify without trusting the party who ran the agent. A log kept by the operator who ran the action is not evidence. It is a claim.

The industry is building toward an answer. Five distinct layers are emerging. Each one solves a real problem. Each one leaves a gap that the layer below it exposes.

Layer 1 — Identity: Who is this agent?

The Linux Foundation's Agent Name Service (ANS), backed by Cisco, Cloudflare, and GoDaddy, anchors agent identity to DNS — the globally distributed infrastructure that already processes over 100 million queries per second. An agent's identity is tied to the domain of the organisation that operates it. No proprietary registry. No centralised control. Verifiable by anyone.

This solves the naming and discovery problem cleanly. DNS is the right anchor — global, neutral, proven at scale.

But DNS answers a registration-time question: who does this agent claim to represent? It does not answer a runtime question: what is this agent doing right now, and can I verify it?

In RATS (RFC 9334) terms, ANS provides the Attester's claimed identity. It does not provide the Verifier's attestation of the Attester's current state, nor the Relying Party's basis for trust. Identity at registration time is not the same as verified behaviour at runtime. The naming layer is necessary. It is not sufficient.

Layer 2 — Protocol: How does the agent communicate?

Two open protocols now govern how agents interact with the world. MCP (Model Context Protocol), created by Anthropic and now governed by the Linux Foundation's Agentic AI Foundation, handles agent-to-tool communication. A2A (Agent2Agent Protocol), from Google, handles agent-to-agent communication across organisational boundaries.

Both are now production infrastructure. MCP crossed 97 million monthly SDK downloads by early 2026. The protocol layer is real and it is moving fast.

What the protocol layer governs is the channel — the structure and format of communication between agents and the systems they interact with. What it does not govern is whether the communication was authorised, what the agent actually did as a result, or whether any record of that action is trustworthy.

A well-formed MCP call and an unauthorised MCP call look identical at the protocol layer. The channel is not the control.

Layer 3 — Governance: Did the agent produce good output?

Qodo AI's work in this space represents the most mature production deployment of what they call a control plane for agentic systems — specifically in the software development lifecycle. The architecture separates a context plane (where engineering standards, review criteria, and team-specific constraints live in a form that tools can consume) from a verification layer (where those standards are applied to what agents actually produce).

The genuine novelty in Qodo's June 2026 release is the Rules Miner: rather than requiring teams to articulate standards before enforcement begins, it discovers coding patterns from existing codebase behaviour and PR history, then surfaces them as enforceable rules. Standards that engineers have consistently applied become rules the organisation can enforce and measure. This inverts the governance bootstrapping problem in a meaningful way.

But the governance layer has a structural limitation that Qodo's own writing acknowledges in the question they posed publicly: when Claude Code reviews its own PR, who reviews Claude?

The verification layer in this architecture is itself an LLM-based review agent checking LLM-generated code. If the review agent shares the same model family, the same prompt injection surface, or the same probabilistic failure modes as the coding agent it evaluates, the enforcement lives inside the same failure domain as what it enforces. That is the CCF violation in software form. The governance layer provides meaningful quality assurance. It does not provide structural independence.

Layer 4 — Accountability: Can I prove what the agent did?

This is where the most technically precise work in the space is happening. The Agent Action Capsule project (Action State Group, IETF draft July 2026) applies SCITT (Supply Chain Integrity, Transparency and Trust, RFC 9943) to agent action records.

The central insight in this work is a legal-technical distinction that matters enormously: the EU AI Act can require logs to exist (Article 12), but it cannot require them to be trustworthy. A log is only as good as the party that keeps it. The operator who ran the action is not a disinterested witness — even an immutable log can be incomplete, cherry-picked, or constructed after the fact.

The fix is anchoring. Each action produces a COSE-signed capsule committed by a shared subject digest. That digest is registered to an independent, append-only transparency log — SCITT. The transparency service issues a receipt: cryptographic proof that the record was registered at a given time, verifiable by any party who trusts the log but neither the agent nor the operator.

This is the move that converts a self-attested log — a claim — into independently verifiable evidence.

The architecture composes four independently verifiable questions over each action: CAN (was the agent permitted to act?), WHO (which named human authorised this exact action?), WHAT (what did the agent actually do, byte-stable?), and AUDIT (did the runtime enforce correctly, in causal order?). No slot is a required root of trust for another. The WHO slot is the direct technical implementation of EU AI Act Article 14's human oversight requirement. The SCITT anchoring is the disinterested-witness implementation of Article 12.

The transparency log pattern here is not new — it is the same pattern that Certificate Transparency (RFC 6962) proved at internet scale for TLS certificates in 2013, that Sigstore/Rekor extended to software supply chains, and that SCITT now generalises to arbitrary statement types. The data structure in all three is identical: an append-only Merkle tree whose root is held by a party independent of the one producing the records. Any modification to any prior entry invalidates every subsequent hash and is immediately detectable.

This is also structurally equivalent to what the TPM does for boot measurement. Each extend operation feeds the PCR:

PCR_new = Hash(PCR_old ∥ measurement)

Each SCITT append feeds the Merkle tree. The accumulator in both cases is held outside the recording component's control. The pattern is the same. The substrate differs.

The gap every software layer shares

Here is what the accountability layer's own security documentation acknowledges explicitly: the log is tamper-evident, not tamper-proof.

Tamper-evident means any modification after the fact is detectable. Tamper-proof means modification is impossible. No software-layer log achieves tamper-proof. A compromised agent runtime that controls the network stack between itself and the transparency service can suppress the anchoring call before it leaves the machine. The window is narrow and detectable after the fact — but it is not architecturally impossible in the way the TPM's PCR suppression is.

This is the "refuses to record" attack: a compromised runtime that simply does not emit records. Every layer from ANS through SCITT is outside this runtime's failure domain for verification — but the recording obligation itself still depends on the runtime's cooperation.

The RATS framework names this boundary precisely. The Attester (the agent runtime) produces evidence. The Verifier (the transparency log) checks it. The Relying Party (the regulator, auditor, counterparty) makes a trust decision. Each role is distinct. The weakness in the current stack is that the Attester — the recording component — is software that can be compromised. A compromised Attester that withholds evidence defeats verification regardless of how independent the Verifier is.

Layer 5 — The hardware root: closing the gap

The TPM makes PCR suppression architecturally impossible because the register lives inside hardware that the measured software cannot reach. The extend operation is irrevocable within a boot session without a physical reset. This is not a policy constraint. It is a physical boundary.

The same move applied to agent action recording is what Arm CCA (Confidential Compute Architecture) Realm isolation provides. An agent runtime executing inside a CCA Realm inherits hardware isolation guarantees that prevent normal-world software from modifying or suppressing Realm state. If the recording obligation is implemented inside the Realm — if the AUDIT slot's extend operation fires inside the hardware boundary — the "refuses to record" attack becomes architecturally impossible rather than policy-prohibited.

The principle is the same one that appears in TrustZone, SMMU Stage-2 translation, AMD RMP page ownership, and Intel TDX: serious isolation mechanisms always place enforcement where the constrained software cannot reach it. The hardware root is not a new idea. Applying it to the agent accountability recording obligation is.

This is not yet implemented in any production system as of July 2026. The research direction (AgenTEE, arxiv 2026) confirms the architectural argument. The production path — CCA Realm isolation with SCITT anchoring of Realm-internal audit events — is the open engineering problem.

The complete vertical

Five layers. Each necessary. None sufficient alone.

CCA Realm / TPM            Hardware-enforced recording
                           Tamper-proof boundary
                           "Refuses to record" made impossible
         ↓
SCITT / Action State       Tamper-evident accountability
                           Disinterested-witness verification
                           EU AI Act Article 12/14 compliance
         ↓
Qodo / SDLC governance     Code quality and standards enforcement
                           Context plane + verification layer
                           Intra-organisational scope
         ↓
MCP / A2A                  Protocol governance
                           Structured agent communication
                           Cross-organisational reach
         ↓
ANS / DNS                  Identity naming and discovery
                           Registration-time verification
                           Internet-scale neutrality

The gap between each layer and the one above it is precisely the enforcement independence gap. ANS knows who the agent claims to be but not what it does. MCP/A2A knows what was communicated but not whether it was authorised. Qodo knows whether the output was good but shares the failure domain of what it evaluates. SCITT knows what was recorded but depends on the runtime's cooperation with recording. Only hardware enforcement moves the recording obligation outside the failure domain of the agent itself.

An invitation

I am not writing this as a prescription. The five layers described here represent real production systems built by engineers who know their domain deeply. The accountability and governance work happening at the SCITT and IETF layer is genuinely novel. The protocol standardisation happening at AAIF is the right architecture for agent communication. Each layer solves a real problem the layer below it cannot solve alone.

What I am offering is the analytical frame my background gives me: the RATS role separation (Attester / Verifier / Relying Party) as a tool for evaluating where each layer's enforcement boundary actually sits, and the hardware independence principle as the criterion for identifying which boundaries are structural versus policy-enforced.

The engineers building the accountability layer are working toward the right answer. The engineers building hardware isolation mechanisms — CCA, TDX, SEV-SNP — are solving what is now also an agent accountability problem, whether they know it yet or not.

The interesting work happens at the intersection. Both communities have something the other needs.

If you are working on any layer of this stack — identity, protocol, governance, accountability, or hardware isolation — I would genuinely like to hear what you are seeing from your side of the fence. The comments are open.

Lei Zhou is a systems architect and platform security practitioner. He designs and builds sovereign AI infrastructure and hardware-rooted security systems.

GitHub: github.com/zlhk100 · LinkedIn: linkedin.com/in/leizhou

This article is part of the Below the API series — things you only see when you look below the API layer.

Related library entry: use-cases/ai-agent-security.md