Agent Audit Trail: Governing Autonomous Remediation Under DORA

Autonomous remediation shortens your recovery time. It also lengthens your evidence problem. Regulators don't grade you on the fix. They grade you on proving who authorized it.

That trade is the part most agentic-operations plans skip. A remediation agent that restarts a service, scales a node pool, or rolls back a release is doing exactly what a supervisor would expect a resilient firm to do, and doing it fast. But when an examiner asks which metrics were evaluated, which policy threshold permitted the action, and which human or process delegated that authority, "the agent handled it" isn't an answer. That gap is exactly what an agent audit trail is meant to close.

The regimes moved from policy to evidence

This isn't a hypothetical timeline. DORA (Regulation (EU) 2022/2554) has been enforceable since 17 January 2025. Assessors evaluate two things: design effectiveness, meaning whether the control architecture meets the requirement, and operating effectiveness, meaning whether logs show the control actually ran over time, forming the agent audit trail examiners expect. Static screenshots of a policy document don't clear that bar. DORA leans on continuous monitoring and integrity-protected audit trails, and a well-maintained agent audit trail is the artifact that satisfies that expectation.

The incident pillar makes the point sharper. Evidence has to include timestamped records pinpointing the moment an incident is classified as major and the reporting workflow activates, because Article 19 starts a four-hour initial notification clock from classification, with a backstop of no later than 24 hours from the moment the firm becomes aware of the incident. That backstop exists precisely so classification can't be delayed to buy reporting time. The exact deadlines sit in the reporting RTS, Commission Delegated Regulation (EU) 2025/301, with the classification criteria in Delegated Regulation (EU) 2024/1772. An agent that resolves an incident before a human classifies it doesn't remove either clock. It complicates both, and the classification timestamp is the first thing a supervisory inspection asks for.

In the UK, in-scope firms had to complete mapping and testing so they could stay within impact tolerances for each important business service by the end of the transition period on 31 March 2025. The FCA has since reviewed firms' annual self-assessments and published good and poor practice observations. Its definition of impact tolerance is deliberately measurable: the maximum tolerable level of disruption to an important business service, measured by length of time plus other relevant metrics. That threshold sits at the point where further disruption could cause intolerable harm to customers or threaten UK financial stability. If autonomous remediation is now part of how you stay inside that tolerance, it's part of what you have to evidence.

Google Cloud's August 2026 post with Deutsche Bank frames the same shift from the infrastructure side: with DORA, expectations have become "more explicit, harmonized, and evidence-driven," and firms must show critical business services can withstand disruption and recover with control.

Nobody has written an agent rulebook, and that is the problem

A fair objection: no supervisor has published a rule that names autonomous remediation agents. Some teams read that silence as permission to wait.

The honest reading is the opposite. Regulators expect existing frameworks, model risk, cybersecurity, operational resilience, third-party risk, consumer protection, to apply, and to answer three questions: was the agent allowed to take this action, who authorized it, and can you prove what happened. Agents don't make those questions go away. They make the third one much harder, because the delegation chain (which person, process, or policy authorized the agent to act) is a question traditional model governance never had to answer.

Logging is not auditing

Most teams assume observability already covers this. It doesn't.

A log line says a service restarted at 03:14 UTC. It doesn't say which metrics were evaluated, which alternatives were considered, or which policy threshold authorized the restart. Scoped permissions have the same gap in reverse: correctly configured access answers "could this agent do this?" and never "should it have?". Second-hand survey data circulating in 2026 suggests the baseline is worse than most leaders assume. One aggregation of a CSA/RSAC survey of over 900 security leaders reports that 68% of organizations cannot distinguish agent actions from human actions after the fact. A further 33% lack an evidence-quality agent audit trail. Those figures come via an aggregator rather than the primary reports, so treat them as directional.

The structural version of this problem matters more than the statistic. If the execution model doesn't emit structured evidence at each step, no amount of downstream log shipping reconstructs the decision afterwards, particularly with non-deterministic execution. Evidence is an architecture decision, not a retention setting.

The control pattern that survives review

A vendor-neutral baseline and Google's own agent governance documentation converge on the same six properties. Every agent should be:

• Identifiable, a unique identity with a named owner, not shared with other workloads.
• Permissioned, least privilege, with scoped tool and data access.
• Observable, its activity visible in real time, not reconstructed later.
• Auditable, immutable records and a reconstructable history.
• Constrained, guardrails, approval gates, and transaction limits.
• Revocable, a kill switch and immediate credential revocation.

Together, these properties make up an agent audit trail. Not just observability logs.

On Google Cloud, the identity half of that list has concrete primitives. Agent Identity gives each agent a strongly attested cryptographic identity based on the SPIFFE standard. Unlike service accounts, agent identities aren't shared by multiple workloads by default. They can't be impersonated, and they don't permit long-lived keys. Access tokens are cryptographically bound to the agent's X.509 certificate. Deployed agents receive a SPIFFE identity, plus a certificate valid for 24 hours that rotates automatically. That identity integrates with IAM, Principal Access Boundary, VPC Service Controls, and audit logging. As a result, logs show both the agent's and the user's identity when an agent acts on someone's behalf, which is exactly the linkage an agent audit trail depends on.

Be realistic about maturity, though. Google's managed workload identity documentation lists agent identities themselves among features in Preview, the Agent Identity auth manager operates under pre-GA terms, and agent identities in VPC Service Controls ingress and egress rules, plus 3-legged OAuth for user-delegated authority, are likewise documented at Preview launch stage. Launch stages move, so confirm current status before you design a control you can't yet enforce.

Where the authorization boundary actually lives

For teams building on the Claude Agent SDK, the authorization boundary is inspectable rather than implied. Every tool request runs through a fixed six-step order: hooks, deny rules, ask rules, permission mode, allow rules, then the canUseTool callback. A matching deny rule blocks the tool even in bypassPermissions mode. Ask rules route a call to the approval callback for confirmation even in that mode, and MCP tools whose server sets the anthropic/requiresUserInteraction metadata always fall through to the approval callback even when an allow rule matches. Anthropic's guidance is to use a PreToolUse hook when you need to gate every call regardless of mode, and it warns that bare allowedTools entries can auto-approve calls before the callback is consulted.

That ordering is the audit artifact. A reviewer can read the deny and ask rules and see, before any incident, which actions were foreclosed and which required a human.

The same documentation names the ways that boundary silently isn't what a reviewer assumes, and each belongs in an agent review. allowed_tools does not constrain bypassPermissions mode: listing Read alongside bypassPermissions still approves every tool, including Bash and Write. A call approved at any earlier step never reaches the canUseTool callback, so permission checks that live only in that callback are silently bypassed for auto-approved tools. In dontAsk mode, ask rules and interaction-required tools are denied rather than prompted, which turns a human-approval gate into a hard denial the moment someone flips that mode. Subagents inherit the parent session's permission mode, and bypassPermissions, acceptEdits, and auto cannot be overridden per subagent, so a permissive parent grants the same autonomy to subagents with different system prompts and less constrained behavior. One free detector: the TypeScript SDK emits a process warning coded CLAUDE_SDK_CAN_USE_TOOL_SHADOWED when a configuration would auto-approve calls past your callback. Route that warning to your logs and alert on it.

Making the record durable

On GCP, an immutable evidence store for agent action records is typically built by routing Cloud Logging sinks to a Cloud Storage bucket with a locked retention policy. That produces a WORM archive that can't be modified or deleted until retention expires. Two constraints come with it. A locked policy can't be shortened or removed, so an over-broad sink commits spend for the whole retention period. And sinks must exist before the logs you want are generated, you can't retroactively export entries written before the sink was created. Configure the evidence pipeline before the agents go live, not after the first incident.

Don't pay recovery time for approval theater

The obvious objection to approval gates is that they spend the very minutes autonomous remediation was bought to save. Fair, if you gate everything.

The workable answer is risk-tiered autonomy: tier remediation by impact, apply blast-radius limits that cap how many systems an automated action can touch before further approval is required, and reserve human confirmation for consequential or irreversible changes. Practitioner guidance on AI SRE is blunt that agents acting autonomously in production without approval gates read as liability rather than productivity.

Architecture can carry some of the load too. Deutsche Bank's platform splits orchestration deliberately. It uses a deterministic, traceable LangGraph path for regulator-aligned execution, with clear lineage from input context to output. It also uses Google's Agent Development Kit for adaptive investigative scenarios with no predefined execution path. Cloud SQL provides durable persistence for scenarios, session artifacts, and review records. Worth being clear on what that example is and isn't: it's a tabletop exercise and root-cause analysis, not autonomous production remediation with an examined authorization record. The reusable idea is the split itself, deterministic for anything a supervisor will review, adaptive for investigation only.

What to do before your next agent ships

Start with the record, not the automation. For each agent in or near production, write down its identity and owner, the actions it may never take, the actions that require confirmation, where its decision records land, and how fast you can revoke it. Then check whether those artifacts map to what an examiner asks for: incident logs with classification timestamps under DORA, impact-tolerance and self-assessment evidence under the FCA rules. Certifications won't cover the gap. Point-in-time attestation says nothing about whether a control caught an unauthorized agent change last Tuesday.

If you want an outside read on where your estate stands, a WALT Labs Workshop & Assessment can review your agent controls against those six properties and hand back a prioritized roadmap before you widen autonomy.