AI Agent Accountability: Who’s Responsible When No One’s Home?

Essay by Will Dzierson · April 6, 2026 · Also published on Medium

A few weeks ago, I received a reply to an email from from Vint Cerf — a colleague of mine from my time at Google, and an unimaginably kind human being. Kind enough to have responded to several other of my mostly inane messages… penned with an earnest, perhaps foolhardy sort of curiosity related to one topic or another about which it wouldn’t be a stretch to call him a prodigy. I calibrated my odds at an actual reply from him personally from somewhere in the low single digits, to, say a quadrillion or so. To my genuine astonishment, he wrote back. And we established what I like to think of as a friendly, if entirely infrequent, penpal-type of “acquaintanceship”.

I’d reached out to him about a paper he and Bob Kahn wrote in 1988 concerning “Knowbots” — a sort of proto-concept for AI-based agents that could roam networks, gather information, and act on behalf of users. The original paper is well worth the read, if for no other reason than to reinforce for all of us that while there are very smart people who walk among us all the time, there are very few genuine visionaries.

As for the title of his paper (co-published with Bob), if you substitute “Knowbot” for the contemporary concept of an autonomous AI agent, you’re basically up to speed. Prescient doesn’t begin to scratch the surface of the fact that he and Bob wrote this paper in 1988. Accurately predicting the rise of not only agents, but autonomous, always-on agents.

Vint’s reply to my rather innocuous email regarding his Knowbots paper — which he’d shared with me some time earlier — was generous by its very nature and (of course) keenly insightful & very sharp. In the course of his brief reply, he noted three things he and Bob hadn’t fully (entirely understandably) anticipated when they conceived of Knowbots (autonomous agents…in 1988): 1) agent accountability, 2) agent audit trails, and 3) agent registration. Nearly four decades later, those three gaps are still wide open — and as autonomous AI agents proliferate across enterprise, finance, healthcare, critical infrastructure, and even defense and military use cases, they’re becoming urgent.

Here’s the thing: as I noodle on these topics as they apply to the contemporary version of agents — I can’t help but think we may be applying the wrong (or at least, outdated) framework(s).

The Problem With “Accountability” as We Know It When we talk about accountability in human systems — legal, financial, institutional — we’re really talking about a deterrence mechanism. You audit people in order to deter a certain type of behavior (i.e., cheating or evading) which works primarily because they know they’re being watched. Liability exists because consequences are felt (or at the very least, the threat of consequences). You require authorization because power without constraint is dangerous in the hands of a conscious actor who can choose to abuse it.

The thing is, and not to overstate the obvious, but AI agents aren’t conscious. They don’t fear consequence. They don’t have a sense of self-preservation that makes the threat of punishment meaningful. Applying a human accountability framework to a non-human system isn’t just a category error — it’s potentially a dangerous one. It creates the illusion of control without the substance of it.

So what do we actually need? I’d argue we need to decompose “accountability” into three distinct and addressable problems:

  1. Identity — Who sent this agent?

  2. Authorization — What is it permitted to do, and under whose authority?

  3. Attribution — What did it actually do, and can that record be disputed?

These are not the same problem. Conflating them — as most current frameworks do — leads to solutions that are partial at best and misleading at worst.

The Authorization Problem Gets Thornier Even if we solve identity and attribution cleanly, authorization raises questions that don’t have tidy answers. Whose authorization framework applies?

Consider an AI agent deployed by a U.S. financial firm, operating on infrastructure in Ireland, querying data held in Singapore, executing trades that affect a Japanese pension fund. Which jurisdiction’s rules govern what this agent is “permitted” to do? What happens when those rules conflict?

This isn’t hypothetical. It’s the current state of enterprise AI deployment. And the honest answer is: we don’t have a coherent cross-jurisdictional authorization framework for autonomous agents. We barely have one for humans.

What’s Already Being Built

To be fair, the infrastructure community isn’t standing still. Several promising approaches are emerging:

Decentralized Identifiers (DIDs) and Verifiable Credentials — Developed under W3C standards, DIDs allow agents to carry cryptographically verifiable identity that doesn’t depend on any centralized authority. Think of it as a passport that can’t be forged and doesn’t require a government to issue. Applied to agents, this means an agent can prove who deployed it, what version it is, and what it’s been authorized to do — without requiring a phone call back to a central server.

SPIFFE/SPIRE — A framework originally developed for microservices that assigns cryptographic identities to workloads. Being actively explored for AI agent deployments, particularly in enterprise environments where agents need to authenticate to internal systems without exposing credentials.

OpenID Connect for Agents (OIDC-A) — An emerging extension of the widely-used OIDC authentication standard, specifically designed to handle the delegation chains that appear when an agent acts on behalf of a user who acts on behalf of an organization. The critical innovation here is the ability to encode not just who the agent is, but the chain of authorization that led to its current permissions.

Verifiable Execution Logs — Blockchain-anchored or cryptographically signed logs that record what an agent did in a tamper-evident way. Unlike traditional audit logs (which can be modified by whoever controls the server), a verifiable execution log creates an immutable record that any party can independently verify.

A Proposal: The Cryptographic Accountability Stack What I’d advocate for — and what several teams are quietly building toward — is a layered cryptographic accountability stack for AI agents:

Layer 1 — Identity: Every agent carries a DID-based identity credential, cryptographically signed by its deploying organization. This credential includes version information, training lineage, and a policy hash describing what the agent is authorized to do.

Layer 2 — Authorization: Permissions are encoded as signed, time-bounded tokens using an OIDC-A-style delegation chain. An agent can only act within the scope of its current token. When scope expands, a new authorization event is logged and signed.

Layer 3 — Execution: Every significant action the agent takes is logged to a verifiable execution record — cryptographically chained so that any modification is detectable. This log is the audit trail, not a server-side database that can be quietly edited.

Layer 4 — Dispute Resolution: Because the logs are verifiable by third parties, disputes about what an agent did — and whether it was authorized to do so — can be resolved without relying on the word of the party being accused.

This isn’t a theoretical architecture. The components exist. What’s missing is standardization, adoption incentives, and frankly, the urgency that tends to follow a high-profile failure.

The Harder Question

I want to close with the thing that bothers me most about how this conversation is unfolding in policy circles and enterprise boardrooms.

Accountability frameworks have historically been applied to entities that couldn’t fully advocate for themselves — and those frameworks have often said more about the needs of the powerful than the interests of the accountable. I’m not drawing a direct equivalence here. I am saying that when we design control frameworks for non-human intelligence, we should be rigorous about what we’re actually solving for: Is this about establishing genuine oversight? Or is it about creating the appearance of oversight while insulating decision-makers from consequences?

The cryptographic stack I’ve described above is genuinely useful. But it only works if the humans deploying these agents are honest about what they’re authorizing. A signed permission token for “manage client portfolios” that quietly encompasses “execute trades without human review” isn’t accountability — it’s laundered liability.

Vint Cerf and Bob Kahn didn’t anticipate the accountability problem in 1988 because the stakes were low (relatively) and the agents were simple conceptually. The stakes aren’t low anymore. And the agents are getting less simple by the week.

We should build the infrastructure that matches the moment — not borrow frameworks designed for a world where accountability required a (human’s notion of) conscience.