Who Actually Did That? Identity-Based Attestation for Autonomous AI Agents
Who Actually Did That? Identity-Based Attestation for Autonomous AI Agents
Shaun Archer
8/21/202610 min read
Somewhere in your environment right now, a non-human identity is doing something a human used to do. Approving a pull request. Drafting a customer email. Filing a ticket. Calling an internal API to close out a workflow. Service accounts, CI/CD pipelines and integration tokens have quietly outnumbered human identities in most enterprises for years now. What's different this time round is that a growing share of them aren't deterministic scripts any more. They're agents - LLM-driven actors that decide what to do, rather than just executing what they were told to do.
That breaks an assumption security teams have leaned on for a long time: that an identity's actions are a decent proxy for intent. A service account calling an API is doing exactly what its code says, no more, no less. An agent calling the same API got there through a chain of reasoning that might not be reproducible, might vary run to run, and might have been nudged along by a prompt injection, a poisoned document, or a tool response that lied to it. "The agent did it" is not an answer when something breaks. You need to know which agent, which session, acting on whose authority, doing what task - and, ideally, whether whatever it produced can still be traced back to it later, even if someone's tried to scrub that context out.
The word everyone reaches for here is non-repudiation. Before bolting it onto agents, it's worth asking what that word actually means and where it came from.
Non-repudiation isn't new. It's old.
People talk about non-repudiation like it's something cryptography invented. It isn't. It's a much older idea, and it comes from law and trade, not computing.
"Repudiation" is a contract-law term - one party denying they ever agreed to something. Merchants and courts have been dealing with this for as long as trade has existed. A wax seal on a letter, a witnessed signature on a bill of exchange, a notary's stamp on a deed: all of it exists to make it hard for one side to later say "that wasn't me" or "I never agreed to that." Roman law had the signum. Medieval commerce ran on notarisation and personal seals for exactly this reason - a trading relationship falls apart the moment either party can plausibly deny what they committed to. None of that needed a computer. It needed a mechanism, physical or social, that made denial expensive.
What changed with computing was the mechanism, not the concept. Public-key cryptography - Diffie–Hellman in 1976, RSA a year later - gave the digital world its version of a seal: a signature only one private key could have produced, verifiable by anyone holding the matching public key. That's what let the security world formalise non-repudiation as a named, engineerable property rather than a general expectation from contract law. It got written into ISO/IEC 7498-2 in 1989, the OSI Security Architecture standard, which named non-repudiation alongside authentication, access control, confidentiality and integrity as one of five core security services - generating and keeping evidence so a party can't later deny having done something.
So attesting the actions of an AI agent isn't a new discipline. It's an old idea - don't let someone deny what they did - applied to an actor that didn't exist when the idea was first written down, digitally or otherwise. The tools are new. The problem has been solved before, many times, in many forms.
The watermarking angle
Hot in the news this week is text watermarking.
The earliest well-known approach, the green-list/red-list token-biasing scheme from Kirchenbauer and colleagues, works because language generation has slack in it. At almost every step, several different next tokens would be equally good. The model has enormous freedom to phrase the same thing several different ways. Watermarking uses a secret key to bias sampling toward one subset of those otherwise-equivalent tokens. No individual word looks off. But run a statistical test with the key over a long enough passage and the bias shows up clearly.
Google DeepMind's SynthID-text, published in Nature in 2024 and now built into Gemini, is the production version of the same idea, done better. Instead of a plain green/red split, it uses tournament sampling - a multi-stage, key-seeded scoring process that nudges the model toward certain token choices across many rounds, without ever forcing a bad one. Reads no differently to a human. Doesn't hurt output quality. But it leaves a statistical fingerprint spread across the whole passage rather than sitting in one spot. Same underlying trick as the original scheme, refined enough to run at Gemini's scale.
And it's a probabilistic signal, not a guarantee. SynthID-text holds up fine against cropping, light edits, mild paraphrasing. Google's own testing shows detection confidence drops off hard once text gets heavily rewritten or translated. Strong signal. Not tamper-proof.
That fragility isn't confined to text, either. On the image and video side, where SynthID also operates, researchers have repeatedly shown that diffusion models can be used to strip the watermark out entirely. A regeneration attack runs a watermarked image back through a diffusion model, which reconstructs the content from a noised version of it - the picture survives, but the precise pixel-level pattern the watermark depended on doesn't. Zhao and colleagues demonstrated this against several invisible-watermarking schemes back in 2023, and the same basic trick - diffusion-based regeneration or editing - keeps showing up in 2025 and 2026 research as one of the more reliable ways to defeat "robust" watermarks. It's the same underlying problem as paraphrasing text: a second generative model reconstructs the same meaning through a different pass, and the fingerprint doesn't survive the trip. Separate work using pure frequency-domain analysis, no diffusion model involved, claims to have reverse-engineered and stripped SynthID's image watermark outright, and a black-box attack called UnMarker reported removing SynthID watermarks from close to 79% of test images, though Google disputes that figure. None of this makes watermarking worthless. It does mean "probabilistic signal, not a guarantee" isn't just a hedge - it's already being demonstrated in practice, on the very scheme this article is using as the state of the art.
Push the idea one step further and it starts to look relevant to the agent problem. If an agent's outputs - drafted emails, generated code, tickets, summaries - come from an LLM that already watermarks at the token level, every artefact the agent produces inherits that signal for free. You don't build anything extra to get it.
For free is doing a lot of heavy lifting in that sentence. It doesn't hold up once you look at who's actually holding the key.
Who actually holds the key
Whoever pitches watermarking as a non-repudiation tool for enterprise agents tends not to dwell on this bit: the secret key isn't yours. It's the model provider's.
With SynthID-text, Google generates and holds the private key server-side. You can't run detection yourself against your own agent's output - you have to ask Google. Google's own public verification portal has only just started rolling out, and even that's staged: journalists, media organisations and researchers got early access first, off a waitlist, with wider access still to follow. Other providers are adopting the scheme too - OpenAI for images through ChatGPT and its API, Nvidia and ElevenLabs for their own media - but verification still runs through Google's infrastructure or its partnership with a third-party firm, GetReal Security. Same pattern everywhere: whoever generates the content holds the key, and whoever wants to check it has to ask permission.
That's a defensible security decision on its own terms - a public key would let anyone strip or forge the watermark, which defeats the point. But it also means the watermark isn't an instrument you actually control, even though you're the one paying for the model. You can't independently verify your own agent's output was watermarked. You're dependent on the provider's detection service, its terms, its pricing, its willingness to answer your question at all. And these schemes are built to prove "this came from Model X," not "this came from Enterprise Y's agent, session, or account" - so even where detection is available, it doesn't give you the fine-grained attribution an actual incident review needs.
What it does give the provider is something considerably more useful to them than to you: a way to police AI-generated content at the platform level, tick regulatory boxes on AI-content labelling, protect brand reputation, and - increasingly concretely - a product to sell. That's a fine business to be in if you're the provider. It is not the same thing as giving the enterprise customer non-repudiation over content that, once they've paid to generate it, arguably ought to be their own intellectual property. In practice, the watermark hands the paying customer nothing they can actually use. It hands the provider a monetisable control point sitting on top of output the customer already paid to own. You bought the output. You didn't get the key.
And this isn't hypothetical any more. Google is already building the Content Detection API into Google Cloud's Gemini Enterprise Agent Platform - a paid, enterprise-tier product, currently in preview with partners including Shutterstock, Snap, Fox Sport and Canva. That's the monetisation model taking shape in real time: detection as a metered cloud API, sold to the platforms and marketplaces that need to screen content at scale, not handed out as a free courtesy to whoever generated the content in the first place. And notice the scope of it - Google is positioning the detector to flag content made by other popular models too, not just its own. That's not a customer service. That's a toll booth on AI-generated content generally, with Google standing at the gate regardless of whose model produced the thing being checked. Whatever you think of the feature, it's a business model for the provider first, and something else - if anything - for you.
That's the whole problem with treating watermarking and identity attestation as equal partners in solving the agent accountability problem. They're not peers. You own one outright. You're borrowing the other, on the provider's terms, for as long as the provider finds it useful to let you - and, as of this year, for as much as the provider decides to charge for the privilege.
Where the watermarking idea runs out - and why you still need attestation
Set the key problem aside for a second. Most of what an agent actually does isn't text anyway. An agent approving a refund, rotating a credential, editing an IAM policy, triggering a wire transfer isn't producing a document with slack you can bias. It's calling an API. There's no "equally good alternative phrasing" for an API call - it either fires or it doesn't. The redundancy that makes text watermarking possible mostly doesn't exist in the action space of an agent working against real systems. And even where it did, you still wouldn't hold the key to it.
This is the actual gap identity-based attestation closes - not by hiding a signal inside the action, but by cryptographically binding every action to a verifiable identity the moment it happens, and, where policy allows, gating the action on that identity being valid before it's allowed to run at all. Instead of "can we detect who did this after the fact," it's "can we prove who did this at the moment it happened, in a way nobody can forge or later deny." And crucially: it's a mechanism you own end to end.
What an identity fabric actually gets you
The practical version of this is what people are starting to call an identity fabric for non-human identities - a layer that issues, scopes, rotates and verifies credentials for every machine and agent actor you run, and that every downstream system trusts as the source of truth for who's acting and what they're allowed to do.
A decent NHI identity fabric for agents gets you a few concrete things. Each agent instance gets its own short-lived cryptographic identity - a SPIFFE/SPIRE-style workload identity, a scoped OAuth client, an mTLS cert - instead of a shared API key sitting in a config file somewhere. Every action carries a signed claim that's more than "agent X": which session, which task or prompt hash triggered it, which human (if any) it's acting on delegated authority from, which model version made the call. Credentials are scoped tight and expire fast, so a compromised or manipulated agent can't quietly build up standing access. And every attested action lands in a tamper-evident log - hash-chained, so a record can't be edited or deleted without breaking the chain and announcing that it happened.
It's the same toolkit behind commit signing, workload identity for microservices, supply-chain attestation - Sigstore, cosign, C2PA credentials for media - so there's nothing exotic about any of it. What's new is pointing it at entities that make autonomous decisions instead of running fixed code paths. And it's a toolkit you own and operate: your keys, your policy engine, your audit chain, verifiable without depending on a model vendor's goodwill.
Combine them - but know which one's actually yours
There's still real value in running both together, as long as you're honest about which one is doing the load-bearing work. A watermark, where it survives, ties a piece of content back to the model and session that produced it - a decent corroborating signal, provider-controlled, useful when it's there but not something to build your primary chain of custody on. Identity attestation, running underneath and fully in your control, ties every action the agent took - including sending or filing whatever it drafted - back to a cryptographic identity you issued, scoped and logged yourself.
Treat the two as equals and you've built a non-repudiation strategy with a single point of failure sitting outside your organisation. Treat the watermark as an occasional bonus from the model layer, and your own identity fabric as the thing that actually has to hold up in an investigation, and the combination earns its keep: corroborating evidence when the provider happens to hand you some, and a complete evidentiary chain you own regardless of whether they do.
One prediction from my end - it's likely that in some way, shape or form LLM providers will find a way of monetising this.
Why this is worth sorting out before it's forced on you
Auditors are already extending the same change-attribution and access-review questions they've long asked of human admins to service accounts and agents. "The AI did it" isn't going to satisfy an incident review any more than "the script did it" satisfies one today. Insider-risk and DLP teams, who've spent years building behavioural baselines for human identities, are realising agents need the same treatment - an agent suddenly touching data or systems outside its normal pattern is a signal, but only if your identity fabric is granular enough to say which agent, which session, which delegated authority sits behind the anomaly.
The organisations getting ahead of this aren't bolting logging on after an incident, and they're not assuming a model provider's watermark will cover them when the questions start. They're treating every autonomous agent as a first-class identity from day one - its own credentials, least privilege, attested at every action - and treating any inherited watermark from the model layer as exactly what it is: a courtesy signal owned by someone else, not a substitute for owning your own evidence. Non-repudiation isn't a new problem. For enterprises running agents, the old lesson still holds: if you don't hold the seal yourself, you don't really have one.