Change Attribution and Accountability for AI-Generated Code

CEO Sundar Pichai says AI now writes three-quarters of the code committed at Google. That figure sat just over 25% in October 2024, climbed to roughly half by late 2025, and hit 75% by April 2026. Compress that trajectory into eighteen months and the result is a handoff, not a gradual shift in tooling, and most engineering organizations haven't updated their governance to reflect it.

The adoption numbers outside Google confirm the pattern. JetBrains research found 90% of professional developers using AI coding agents at least weekly, with 68% using them daily. That's the default mode of writing software at most engineering organizations with more than a handful of people, not an experiment anyone is still running trials on.

Trust hasn't kept pace with adoption. Developer confidence in AI accuracy dropped from 40% to 29% year over year even as usage climbed to 80%, in the same research window. Mass adoption and mounting skepticism are happening inside the same organizations, often among the same developers who use these tools daily and trust them less each month. Volume is up. Scrutiny is not, and that gap, the widening distance between how much code agents produce and how much of it anyone can account for, is the actual subject here.

Why accountability doesn't automatically follow from authorship

The formal answer to "who owns this code when it breaks" hasn't changed. It's the engineer who merged it. That answer made sense when the engineer who merged the code also wrote most of it, understood its logic because they'd built it line by line, and could explain any part of it under questioning. It makes far less sense when that engineer's actual contribution was reading a diff for ninety seconds and clicking approve, which is now the norm rather than the exception at plenty of shops.

The accountability gap in one sentence: code nobody fully read got signed off by someone who trusted the diff because the alternative was falling behind on delivery. Most teams adopted AI coding tools faster than they updated the review gates, provenance records, and audit evidence meant to catch problems before they ship. Agents generate diffs faster than any human reviewer can meaningfully assess, and that forces a choice nobody wants to make out loud: either review becomes the bottleneck that slows delivery back to human speed, or it becomes a formality that doesn't catch anything. Most teams have picked the second option without admitting it. Approval latency stays flat. Real scrutiny drops, quietly, without a single alarm going off.

Agent-authored code fails differently than human-authored code does. Agents introduce subtle logic errors that survive a superficial glance because the code looks idiomatic and properly formatted. They generate security vulnerabilities by pattern-matching against training data with no semantic grasp of the system they're modifying. They hallucinate dependencies that don't exist, or that resolve to something other than what was intended. A merge-time sign-off was designed to check a human's reasoning, not audit a statistical model's output, so it catches none of this.

Research has found that AI can increase delivery throughput while simultaneously being associated with greater delivery instability. Call it what it is: an amplifier, not an improvement. It makes good practices faster and bad practices faster in equal measure, and which one an organization gets depends entirely on its governance.

Two distinct gaps hide inside this problem, and conflating them is how teams end up solving the wrong one. Attribution asks what changed and why. Accountability asks who answers for it. Attribution is a data and infrastructure problem. Accountability is a policy and ownership problem, and treating them as one and the same is the more common mistake. Fix the first without touching the second and the result is a beautifully logged system that nobody is actually responsible for.

What changes when agents run long, multi-step workflows autonomously

The shift underway isn't about better autocomplete. Teams used to ask AI to finish a line or suggest a function. Now they assign whole issues: implement this migration, refactor this module, generate this test suite. That's delegation, and treating it as a bigger version of autocomplete leads teams to underbuild governance.

An agent differs from a smarter autocomplete in one specific way: sustained execution. That lets it run across a long, multi-step workflow, call tools, read what those tools return, and adjust course based on what it finds, all without a human in the loop at every step. A single prompt like "add user authentication with JWT tokens" can touch a User model, new auth routes, password hashing logic, JWT configuration, and a database migration, spread across half a dozen files and more than one system. One triggering instruction, many downstream decisions, and nobody watched most of them happen in real time.

Research on agent performance points to a last-mile problem. Agents resolve the large majority of well-specified requirements efficiently and without incident; the edge cases, the failure modes, and the domain-specific correctness questions still require review by a human expert who can catch errors the agent cannot recognize on its own. That oversight needs to sit at the right point in the workflow, not arrive as a rubber stamp at merge time. Benchmark results back the first half of that claim: leading systems now resolve roughly 80% of SWE-bench Verified tasks, up from the 13.86% early agentic systems managed in 2024. But a benchmark measures whether code solves a defined problem. It says nothing about whether that code is safe to run against production data, and production safety is what governance actually has to answer for. No benchmark score substitutes for it.

Governance built for human pull requests assumes a person made every decision embedded in that diff, one line at a time, and could explain the reasoning behind each one. Governance for agents has to capture the chain of reasoning, the sequence of tool calls, and the intermediate states the agent passed through on its way to the final PR. Without that chain, a reviewer isn't reviewing a decision. A reviewer is reviewing an outcome and guessing at the decision behind it, and that guesswork is a formality wearing review's clothes.

The components of a usable attribution record

Agent observability means capturing every step an agent takes on the way to a change, including the diff it lands on. That includes which tool it selected, what arguments it passed to that tool, what the model said at each turn, what it read from and wrote to memory, and which branch it took when more than one path was available. The final diff is the least informative artifact in that whole sequence, since it shows the destination with no record of the route.

A properly built audit trail is a comprehensive, ordered record of every input, every LLM call, every tool execution, and the final output. That record is the chain of custody connecting a bug found in production back to a specific trigger and a specific upstream decision. Without it, debugging a production incident caused by agent-written code means reconstructing intent after the fact, which is close to impossible once the context window that produced the change has closed.

A usable provenance record needs five things, at minimum, for every AI-generated change: the governing specification version the agent worked against, the model and provider that generated the output, the prompt or task description that triggered the work, the human who accepted the output, and the tests it passed before shipping. If any one of these is dropped, the record stops being usable evidence, even if it remains technically complete data.

Borrowing a concept from supply chain security, a component inventory for AI systems tracks the models, services, and external dependencies touched during a development workflow. It's the same idea applied one layer up, so that when an auditor needs to trace a decision back to a specific system, they can do it instead of shrugging and writing down "the AI did it."

A working attribution system has to eliminate that phrase. Every session needs to trace back to a specific human who initiated it, or a specific automated trigger. Not a category. A name.

The layers of logging need to stay distinct, too, and collapsing them into one blended log is a common mistake. Different layers capture what the model said, what the agent actually executed, and what ultimately landed in the repository, and each answers a different question. Each answers a different question, and no single layer, alone, reconstructs what happened.

Where governance breaks down in agent infrastructure today

Security professionals already flag this as the frontier risk, and the numbers back them up. A Dark Reading poll found 48% of cybersecurity professionals naming agentic AI as the number-one attack vector heading into 2026. Only 21% of executives report complete visibility into agent permissions, tool usage, or data access patterns. Nearly half the security industry worries about the exact thing most leadership teams admit they can't see clearly, and that mismatch is the real story here.

What should keep engineering leaders up at night is an agent making an out-of-scope edit, exploiting a permission boundary nobody thought to close, running an unreviewed database migration, executing an unsafe shell command, or getting the benefit of the doubt from a reviewer who trusted the diff. It's an agent making an out-of-scope edit, exploiting a permission boundary nobody thought to close, running an unreviewed database migration, executing an unsafe shell command, or getting the benefit of the doubt on a pull request that deserved far more scrutiny than it got. Bad code gets caught by tests, most of the time. Bad permissions get caught by nothing, until something breaks, and by then the blast radius is already set.

The OWASP Agentic Top 10 names goal hijacking, tool misuse, privilege abuse, and supply chain vulnerabilities among the leading risks in misconfigured agent infrastructure. The pattern across all four is identical: the attack surface is the tool and skill execution layer, not the language model itself. Teams that worry primarily about the model hallucinating are worrying about the wrong layer, full stop.

The question every organization needs answered, and mostly hasn't, is which agents can modify which repositories, touch which secrets, and spend up to which budget. That 21% visibility figure isn't just a security statistic. Lack of visibility and lack of accountability are the same failure, measured twice from two different angles.

An architectural answer is emerging in response, and it marks a real shift in posture. The Microsoft Agent Governance Toolkit approach, as MLflow has described it, enforces governance decisions deterministically before an action ever reaches the wire. Blocked actions become structurally impossible rather than merely discouraged by a policy someone might ignore under deadline pressure. That's the posture attribution infrastructure needs: not a rule someone might follow, but a constraint the system can't violate no matter how badly a sprint is behind schedule.

What regulatory frameworks now require for AI-generated code

Regulators have started writing rules that assume the gap described above already exists, and they are closing it regardless of whether engineering teams are ready. The EU AI Act imposes risk-tiered obligations with penalties reaching a substantial fixed amount or 7% of global turnover, whichever is larger. For a multi-agent coding pipeline, the layered compliance structure means compliance handled at the model-provider level doesn't discharge the deployer's own obligations. Using a compliant model doesn't make an organization's use of that model compliant, and plenty of legal teams are going to learn that distinction the hard way.

The EU Product Liability Directive has a firm enforcement date in 2026, and that date isn't a soft target. Any application serving European customers, built with AI-generated code and lacking proper governance, faces materially increased legal exposure once that date passes.

Outside the EU, NIST released its Cyber AI Profile in February 2026, addressing AI-specific risks across three areas it calls Secure, Defend, and Thwart. That's the closest US equivalent for teams operating outside EU jurisdiction, though it remains a draft rather than settled law.

Three regulatory paradigms are forming in parallel: the EU's prescriptive, rights-centered model, the US's voluntary federal approach layered under a growing state patchwork that includes California's SB 53, and China's centrally administered framework. None of the three, as of now, treats agentic AI as its own distinct category with tailored rules. Regulation is still catching up to a technology that changed shape faster than the legislative process could track it, and that lag is itself a kind of risk disclosure.

What all three paradigms agree on, in practice, is that documented AI inventories, risk classifications, and model lifecycle controls are expected of organizations deploying this technology, measured through concrete key risk indicators rather than a policy document sitting untouched in a shared drive. Attribution and audit logs are the evidence a team points to when it says oversight actually happened. They are the compliance, not a nice-to-have layered on top of it. They are the compliance.

Translating attribution requirements into engineering configuration

None of this stays abstract once it reaches engineering. The most direct translation treats agent configuration as code: agents defined in version-controlled configuration files, checked into the same repositories as everything else, reviewed and approved through the same process as any other infrastructure change. An agent's permissions shouldn't live as a setting buried in some dashboard. They should be a diff someone actually signed off on.

A working governance layer needs several pieces operating together, including single sign-on, audit logging, repository-level policy, an explicit allowlist of tools the agent can invoke, model routing rules, and a secrets policy governing what credentials the agent can touch. A safety layer supports that setup, with isolated branches for agent work, allowlisted commands, and restricted shell permissions that keep an agent from running anything outside a narrow, pre-approved set of operations.

Credentials deserve particular attention, because this is where attribution most often quietly falls apart. Session-scoped credentials, minted for the duration of a single agent run and revoked the moment it completes, keep every action traceable to one specific session. Long-lived service accounts do the opposite: they blur attribution across dozens or hundreds of agent runs, so that by the time something goes wrong, the credential that touched the system has been reused so many times that tracing it back to a specific trigger is no longer possible. The postmortem stalls out right there.

Budget controls double as attribution signals, which is easy to overlook. Capping spend at the session level, the developer level, and the time-period level means every token an agent consumes is attributable to a named trigger, because the spending record and the change record track the same underlying event. Cost governance and change attribution end up as the same instrument, pointed at two different questions.

Sandboxed execution closes the loop. Isolate each agent run in its own bounded environment, and its tool calls, diffs, and decisions get captured cleanly instead of commingling with other agent activity on shared infrastructure. Shared infrastructure is efficient, sure, but it's also where attribution goes to die: two agents touching the same environment at the same time produce a log nobody can cleanly separate afterward.

CIO.com has described the resulting operating model as "delegate, review, own." Agents handle first-pass execution. Engineers review for correctness, risk, and alignment with intent. Ownership of architecture, trade-offs, and outcomes stays with a human, full stop, regardless of how much of the first draft the agent produced. That clarity about which part of the job belongs to whom is what lets autonomy scale without accountability quietly evaporating.

The gap between prototype and production becomes visible when moving from a local setup to a production environment, where audit trails, scoped credentials, and budget caps must exist and typically do not. An agent running on a laptop, pointed at a local repository, produces none of this: no audit trail, no scoped credentials, no budget cap, nothing to hand a compliance officer six months later when the question comes up. The same agent running against managed infrastructure built with governance in mind produces all three by default, and that difference alone should decide where production work happens.

Attribution in managed cloud platforms versus self-hosted setups

Self-hosting an agent stack sounds straightforward until the bill for doing it properly arrives. It means owning the observability pipeline, the credential rotation system, the sandbox isolation layer, and the audit log infrastructure, on top of running the agents themselves. That's substantial operational overhead that has to exist before any automation value appears, and most organizations underestimate it, because the agent is the visible part of the system and the governance layer around it isn't.

For engineering leaders evaluating vendors, documented security certifications and verifiable institutional backing function as relevant signals, since they indicate process maturity that procurement teams can verify against a standard rather than take on faith.

Whether to run agents isn't really the open question anymore. Every engineering org evaluating this landscape has already answered that, or is about to. The choice that remains is narrower: either the infrastructure running those agents produces the attribution record that governance and compliance actually require, or that record has to be built from scratch and bolted onto agents that were never designed to produce it. Managed platforms make that record the default output of running the system. Self-hosted setups make it a separate project, usually one that gets deprioritized until an incident forces the issue.

This gets harder as agent stacks get more sophisticated. MightyBot's analysis points out that multi-agent workflows increasingly mix models by task, using an expensive, capable model to plan and a cheaper model to execute once the plan is set. That's good economics. It's also a harder attribution problem, because the audit trail now has to track which specific model, from which specific provider, made which specific decision inside a workflow that might touch three or four systems before it's done. "AI did something" was always an insufficient answer, and it gets even less sufficient once "AI" means four different models from different vendors handling different slices of the same task.

The human review practices that attribution infrastructure makes possible

Attribution infrastructure is what keeps humans inside the accountability chain, and what makes their presence there mean something rather than just a formality. A reviewer who can see every tool call an agent made, every intermediate diff it produced along the way, and every branch it took, is exercising real judgment when they approve a change. A reviewer looking only at a final diff, with no visibility into how it got there, is closer to signing a document in a language they don't read.

Agents can take part in this review process themselves: examining proposed changes, flagging suspicious patterns, pointing out likely bugs before a human ever looks at the code, and freeing up human attention for higher-level judgment instead of mechanical line-by-line checking. That only works if the reviewing agent's own actions get logged just as thoroughly as the actions of the agent whose work it's reviewing. An unaudited reviewer is the same problem wearing a different job title, not an improvement over an unaudited author.

The delegate, review, own model implies a structured escalation path: human approval required for anything security-sensitive, anything touching a production deployment, anything that can't be undone once it ships. Attribution logs are what determine, after the fact, whether a given change actually fell into one of those categories, and whether it got the scrutiny that category demanded.

Engineering leaders face real decisions here, and they're policy decisions dressed up as technical ones: which agents get full autonomy, which require a human to confirm before proceeding, and which require sign-off from a specific named person rather than a rubber stamp from whoever's on call. Those policies are worth exactly as much as the audit trail that makes it visible when someone violates them, no more.

Regulators are increasingly going to ask for exactly this, but satisfying a regulator isn't the point. An engineer merging a pull request is putting their name on something, and a signature ought to mean the signer could actually explain what's inside it if asked. Every agent action attributable to a person or a trigger, every diff reviewable after the fact, every credential scoped tightly and revoked on schedule: none of that is bureaucratic overhead bolted onto engineering. An engineer who can stand behind an approval is different from one who's just hoping nobody asks, and that difference is the entire argument.

A team where AI writes most of its production code, without accountability quietly disappearing, looks a particular way: the framework connecting every diff back to the person or trigger that started it gets built into how the agents run from day one, not stitched together after an incident forces the question. That's the only version of this that actually scales. Every other version is a postmortem waiting to happen.