Skip to main content

AI agents change your records too — who signed off?

· 4 min read
Ilgiz Khusnullin
Founder, Attestsys

Ask how change accountability works in most engineering organizations and the answer rests on one foundation: personalized logins. Every change traces to an account, every account belongs to a person, and the separation of privileges does the rest. It's a good model. It held up for decades.

It assumes every actor is a human. That assumption is now quietly false.

The new actors in your workspace​

Today a Jira ticket can be created, transitioned, edited, and closed without a human touching it: automation rules, integration bots, CI pipelines updating issues on deploy — and increasingly, AI agents acting on natural-language instructions with broad permissions and, as one engineer memorably put it to us, "usually the best of intentions and sometimes questionable intelligence."

When we talk to practitioners about incident timelines, the agent stories come up unprompted — and they come up angry. An "AI changed production" incident isn't just an outage; it's an accountability puzzle. The questions stack up fast:

  • Whose identity did the agent act under? Its own service account, or a human's delegated session?
  • Who instructed it, and what exactly was the instruction?
  • What did it actually do — not what the prompt asked for, but the changes that landed?
  • Was there a sign-off — and does "there was a sign-off" survive the follow-up question, "signed off by whom, on what, exactly when?"

The personalized-logins model answers none of these by itself. An agent acting through a delegated token looks like the human in the access log. A bot account tells you a bot did it — not which workflow, triggered by whom. And when the post-incident review needs a timeline, "the automation did something around 14:00" is the new "just after 10."

Accountability needs a record that doesn't care who's asking​

The fix isn't banning automation — it's recording changes in a way that holds up regardless of what kind of actor made them:

  • Capture every change as an event, at event time — not reconstructed later from mutable state. If an agent transitions an issue at 14:02:31, that fact is recorded at 14:02:31.
  • Bind the acting identity into the record. Human, automation rule, or agent service account — whatever identity performed the change is part of the signed payload. "Who — or what — changed this?" gets one verifiable answer.
  • Sign and chain the records so the timeline you present after the incident is provably the timeline that was recorded during it. This matters more with agents in the loop, not less: when an action is contested ("the agent didn't do that — someone did it manually and blamed the bot"), an editable history settles nothing.
  • Timestamp externally (RFC 3161), because "when" is precisely the field everyone argues about later, and the operator's own clock is the wrong witness.

This is what our Tamper-Evident Audit Log for Jira does for every Jira workflow event: each change — human or automated — becomes a signed, hash-chained, independently timestamped entry, and the whole record exports as a bundle anyone can verify offline in a browser.

The question to ask before you need it​

Agents are coming to every workflow tool — including the ones that hold your change-management records. The time to ask "could we attribute an agent-made change after the fact, to the satisfaction of someone skeptical?" is before the incident, not in the postmortem.

If your current answer is "we'd grep the audit log and hope nobody questions it" — that's the assumption breaking. You can see what an answer with proof attached looks like in two minutes: the free tier records every event with full cryptography intact, and the sample bundle + offline verifier on our site show exactly what you'd hand to the skeptic.