Prove what the agent did: why witnessed audit is becoming table stakes

Why agents move this from nice-to-have to load-bearing

Audit logs are not new. What is new is a non-human actor taking consequential actions inside your environment, on its own initiative, at machine speed.

When a person changes an IAM policy, there is a chain you can follow: a login, a session, a ticket, a human you can ask. When an agent changes an IAM policy, the chain only exists if the agent was built to leave one. The default is silence. The action happens, the state changes, and unless the system was designed to witness itself, the only record is the downstream effect, which is exactly the "observable but incoherent" gap Microsoft names.

This is the part teams underestimate. You can bolt monitoring onto a human workflow after the fact, because humans are slow and leave fingerprints. You cannot bolt it onto an agent after the fact, because by the time you are reconstructing, the agent has already done the thing, and if it did not record its own reasoning and its own action at the moment it acted, that information is gone. The forensic account has to be a design property of the agent, not a logging layer downstream of it.

What "defensible" actually requires

The two memos, taken together, describe a posture in three parts. This is how we build agents that take real actions, and it is the bar we think any production agent should clear.

1. Witnessed action, recorded at the moment it happens

Every action the agent takes gets written down by the agent, as it takes it: what it did, to what, and the evidence it acted on. Not a log scraped from the cloud provider afterward, which tells you the state changed but not why the agent believed it should. A witnessed record is the agent's own account, captured at the moment of action, which is the only point where the reasoning still exists.

2. Grounded in citable evidence, not vibes

A record that says "the agent tightened this policy" is weak. A record that says "the agent tightened this policy because these three principals had unused admin grants, here are the API calls that prove it" is something you can stand behind in an investigation or an audit. Grounding is what turns a log line into evidence. It is also what keeps the agent honest in the first place: an action that cannot cite its basis is an action that should not happen.

3. Customer-owned logs, in the customer's environment

The record has to live where the customer controls it, not in a vendor's account the customer cannot subpoena or retain on its own schedule. M-26-14's whole premise is that the organization owns its forensic posture. An agent whose audit trail is locked inside a SaaS vendor's tenant fails that premise on day one. The agent should run in the customer's environment and write its witnessed record to logs the customer owns.

What this article is not

• Not legal or compliance advice on M-26-14. We are reading it as a signal about where the bar is heading, not telling you how to achieve agency compliance. If you are a federal agency, read the memo and the forthcoming CISA reference architecture directly.
• Not a claim that we are a SIEM. Witnessed audit is a property of how an agent acts, not a replacement for your logging and detection stack. The two sit next to each other.
• Not a takedown of the sources. The Microsoft forensics method is genuinely useful, and the reading of the OMB memo is a fair summary of a real mandate. We are building on both, not correcting them.
• Not a promise that logging makes an agent safe. A perfect audit trail of a reckless action is still a reckless action. Witnessed audit pairs with fail-closed gating and least-privilege scope; it does not substitute for them.

One-sentence takeaway

When software starts taking actions on its own, the question that defines a defensible system stops being "was it protected" and becomes "can you prove what it did," and that account has to be designed into the agent, grounded in evidence, and owned by you.