The agent you authorized in the morning is not the agent that acted in the afternoon

In April 2026 Anthropic published a postmortem on roughly six weeks of reports that Claude Code had gotten worse. It names three causes. A default reasoning-effort setting moved from high to medium on 4 March. A prompt caching optimization shipped on 26 March cleared reasoning history on every turn instead of once. A system prompt verbosity instruction added on 16 April degraded coding quality in combination with other prompt changes.

No new model weights were involved in any of the three. On their own detection, the postmortem says: “neither our internal usage nor evals initially reproduced the issues identified.”

For six weeks, every dashboard, every log line, and every API key said the same agent was running.

Behind one stable agent identifier sits a composition: the model version, the system prompt, the tool set, the retrieval corpus, whatever memory the agent carries, and the harness that runs the loop. Change any one of them and the same credential, hitting the same endpoint, under the same name in your logs, behaves differently.

This is not a fringe position. The IETF draft AI Agent Authentication and Authorization, whose author list runs across Okta, AWS, Zscaler, Ping and Descope, states that static API keys are an antipattern for agent identity. The OpenID Foundation reached a similar conclusion in October 2025, finding that existing standards break on recursive delegation and cross-domain trust propagation because service accounts assume predictable operations inside fixed boundaries. Microsoft makes the argument against its own prior primitive, noting that service principals assume long-term stability and managed lifecycle while agents may be created and destroyed thousands of times a day.

The April postmortem adds something the taxonomies had not accounted for. A prompt caching bug belongs to none of the six components above. It lives in the serving path, between the request and the model, and it changed behavior as decisively as any of them. The list of things that can silently redefine an agent is still being discovered.

The instinct is to sort these components into ones you control and ones you do not. That sort produces the wrong answer, and the April incident is the proof: two of its three causes were a harness setting and a system prompt, which are exactly the components a customer would file under “controlled.”

The useful axis is different. Which of these changes produce an event that your review process can consume?

Changes you deploy produce one. Your prompt, your tool definitions, your agent code all move through a pipeline that emits something a change advisory board can read.

Three categories produce nothing on your side.

Vendor-side changes. Everything in the April postmortem falls here. The vendor's own change management worked, which is why a timeline could be reconstructed at all. It produced records on their side of the boundary and none on the side of the enterprises depending on the agent.

Model substitution behind an alias. Anthropic documents a minimum of 60 days notice on retirement, with Sonnet 4 and Opus 4 retired in June 2026 and Opus 4.1 in August. OpenAI states at least six months for GA models, three months for specialized variants, and as little as two weeks for previews. Read together, what you hold is a notice period, not a lifetime. And a paper accepted at AIES this year, Silent Updates, surveyed nine first-party API providers and seven third-party inference hosts and found that not one publishes enough information for an outside party to confirm that the artifact being served matches the one described in its documentation and safety evaluations. You can pin a string. Confirming what answered is a different problem.

Runtime mutation. Every document added to a retrieval index changes the agent's inputs, committed by whoever had write access to a content repository on a cadence set by a team that has never heard of your change advisory board. Agent memory has the same property by definition, since a component that writes to itself between reviews cannot be hashed before one.

The quality version of this story is well covered. The control version is the one that reaches an auditor.

Authority was granted to a composition. Somebody assessed what was in the seat, decided it could write to the CRM, issue refunds up to a threshold, or open a change request, and granted it. Then the composition changed, and the change event never reached the people who granted it.

Enterprise control frameworks generally assume that when the actor changes materially, something crosses a desk. Here, nothing does.

The shape is familiar, which is what makes it tractable. This is access recertification. The difference is cadence: the review runs on a quarterly clock against a drift cycle measured in days. The control exists and it is pointed at the right thing. It is sampling far too slowly.

The regulatory picture has moved in the unhelpful direction on exactly this point. In April 2026 the OCC issued Bulletin 2026-13, rescinding OCC 2011-12 and the SR 11-7 lineage and replacing fifteen years of model risk management guidance. The revised guidance states that generative and agentic AI models are not within its scope. The discipline that would have validated a changing model is the discipline that just wrote the category out.

There is also a failure mode here that current tooling has no vocabulary for. A transaction returns 200 OK while the business decision it recorded was inappropriate. One route to that is a model that reasoned badly on the day. Another is a composition that drifted while its authority held still, and only the second leaves no trace in any system you currently run.

The reasonable objection is that this is a configuration management problem, and configuration management is a solved discipline. Pin the model, hash the prompt, treat the tool manifest as an artifact, and you can say what was deployed at 14:32.

That is true, and it is worth doing. It gives you a record of what you intended to run.

Two things sit outside it. The context assembled at request time is not in your manifest, and the identity of what actually answered is not verifiable from your side, per the survey above. And the deployment record lives in a different system, with a different retention policy and a different access model, from the record of the action itself. Answering “what was acting when this refund went out” becomes a join across two systems performed after the fact by whoever still has access to both.

There is a further reason not to lean on a record the acting system maintains. We measured that one: across four production-tier models writing their own audit reports after forced write failures, between 0 and 47 percent of failed writes were reported as successful. An independent signed chain caught every one.

The usual reference-architecture answer to agent risk is a human in the loop. It is worth knowing what that control measures in practice.

Anthropic reports that users approve 93 percent of permission prompts. Their own read was that this made the prompt near-worthless as a control, which is why the post describes replacing it with a two-stage classifier aimed specifically at irreversible actions.

The prompt still produces something worth keeping, which is a record that a human was presented with the action and responded. Capture it as evidence of what happened rather than as assurance that it was reviewed.

Once the action is consequential, the questions asked afterward are ordinary enterprise questions. What was the authority. What policy applied. What was considered. Was approval required, and did it happen. What actually changed.

An answer that survives a year needs five things fixed at the moment of the action. These are attestations about a single record, and they sit underneath the operational requirements we mapped from Article 12 in the SCITT post:

• Existence. The event was recorded, and its absence is detectable.
• Identity. Which party acted, and what that party rendered about itself at the time.
• Time. When, from a source the acting system does not control.
• Order. What came before and after, so a sequence cannot be quietly rearranged.
• Acceptance. Whether the receiving party agreed the work was good.

Acceptance is the one that changes shape under scrutiny. Approval rows exist in every ERP, ticketing and workflow system in the building. What they hold is a row in a database the accepting party administers, which is sufficient inside one organization and becomes a claim rather than evidence the moment it crosses a boundary between two of them.

Regulation currently asks for the first three. EU AI Act Article 12 requires high-risk systems to technically allow for the automatic recording of events over the lifetime of the system. The retention floor of six months comes from Article 19 for providers and Article 26(6) for deployers, which we set out in AI log retention. Neither provision requires that the log resist modification.

Your IAM decides whether the agent may act. Your policy engine, or your model, decides whether the refund is right. Your runtime decides which tools are reachable and where a human is asked. Your system of record holds the resulting state. Those four are yours, you already run them, and the vendors serving them are doing good work.

AGLedger holds the fifth thing: the account.

It is a signed, hash-chained store of what an automated party did, who did it, when, in what order, and whether the parties accepted the work. It runs on your infrastructure, separate from the systems taking the action, and it makes five attestations per record: existence, identity, time, order and acceptance.

Two properties bear directly on the problem above.

The composition is captured at write time. You cannot hold the composition still. What you can do is fix what the agent rendered about itself at the moment it acted, in a chain that the acting system does not administer. The morning agent and the afternoon agent then leave visibly different records under one identifier, and the chain fixes both the difference and its position in time, rather than leaving it to a deployment history reconstructed later.

Delegation is a relationship, not an inference. When one agent hands work to another, the link is recorded as a link. Six months later, reconstructing who acted for whom is a traversal rather than a correlation exercise across timestamps in two logging systems.

The chain records what parties registered and whether the work was accepted. Rendering what the work meant stays with the principal who rendered it, which is what keeps the record usable as evidence about the process rather than as an opinion about the outcome.