What Audit Trail Does an AI Agent Need to Leave?

An internal auditor asks the operations team a simple question: why did someone restart the nightly payment settlement job at 2:47 a.m.? The scheduler log shows a restart. The ticket says "rerun per AI recommendation." Nobody can say what the AI agent saw, what it was allowed to do, or who approved it.

Short answer: An AI agent should leave an audit trail that lets someone reconstruct the full decision, not just the command. That record should show which agent and which people were involved, what context and evidence informed the recommendation, what authority the agent held, who approved the action, exactly what ran, and what happened afterward.

This article lays out Rocket Software's proposed eight-part framework for that record. It also includes a sample audit record from a real-world style mainframe batch incident that you can adapt for your own environment.
 

What is an AI agent audit trail?

An AI agent audit trail is the evidence that connects an AI agent's recommendation to the authority, approval, action, and outcome behind it. Use this definition as your starting point:

An AI agent audit trail is a time-ordered, tamper-evident record that links an AI agent's identity, the context and decision evidence it used, the recommendation it made, the authority it held, the human approval it received, the authorized action it executed, and the validated outcome. It lets an auditor, operator, or risk team reconstruct who did what, why, and with whose permission.

The key word is links. Most of this information already exists somewhere in your environment. The AI agent audit trail ties it together so nobody has to rebuild the story from five different tools after the fact.
 

Why aren't traditional system logs enough for agentic AI?

Traditional system logs record events. They don't record decisions. A log can show that a user ID issued a command at a specific time. It can't show why an AI agent recommended that command, what evidence supported it, or whether a person with the right role approved it.

System logs are necessary but insufficient. You still need System Management Facilities (SMF) records, job logs, console logs, and security logs, because they prove what happened at the system level. But an AI agent adds a new layer of decision-making between the alert and the command. If your audit trail skips that layer, "the AI did it" becomes the only explanation you can offer.

Here's how the two records differ:

Leaders already treat this gap as a production blocker. In a June 2026 Rocket Software and Hanover Research study of 250 financial services IT leaders, 46% said they need strong governance controls and approval workflows before trusting AI in production for operational diagnostics. Another 43% wanted proven accuracy validated against historical incidents. Respondents also named lack of explainability and auditability among their top concerns about agentic AI in regulated operations.

IDC reports a similar pattern. According to IDC, early adopters of agentic AI consistently cite visibility for compliance and audit requirements as a challenge. IDC also notes that building trust depends on tracking insights, actions, and outcomes through logs, audit trails, and clear policies for human oversight.

Should an AI audit trail capture the agent's reasoning

An AI audit trail should capture the agent's decision evidence and stated justification, not hidden model chain-of-thought. Auditors need to verify what the agent relied on and what it concluded. They don't need, and generally can't reliably obtain, the internal token-by-token process of a large language model.

Focus on what's observable and checkable:

• Inputs: the data sources and records the agent retrieved
• Evidence: the specific signals it cited, such as an error code or a lock wait
• Recommendation: the action it proposed
• Justification: the plain-language explanation it gave the operator
• Uncertainty: what it couldn't confirm, and any conflicting evidence

A reviewer can test this record. They can open the same job log, confirm the same error code, and judge whether the recommendation followed from the evidence. That's a stronger basis for accountability than an opaque reasoning dump.

How should human approval appear in the audit record?

Human approval should appear as a separate, attributable step between the agent's recommendation and the executed action. The record should make the sequence impossible to misread:

1. Agent A recommended a specific action, with evidence attached.
2. Person B approved that exact action, under their own identity and role.
3. Agent A executed the approved action, within its authorized scope.
4. System C recorded the outcome and the validation results.

Each step needs its own identity and timestamp. If Person B approved "restart from STEP040" and the agent ran "restart from STEP010," the record should flag the mismatch automatically.

This sequence also maps to graduated levels of AI authority: Observe, Recommend, Act with Approval, and Act Autonomously. Most consequential production actions belong at Act with Approval. The audit trail proves which level applied to each action.  

What makes an AI audit trail defensible?

A defensible AI audit trail is complete, attributable, and tamper-evident. If someone challenges it six months later, it should hold up without relying on anyone's memory.

Check your audit trail against these criteria:

• Attribution: Every entry ties to a unique agent or human identity, never a shared account.
• Integrity: Records can't be altered without detection. Hashing or signing supports this.
• Immutability: Write the immutable record to storage that agents and operators can't edit or delete.
• Timestamping: Use synchronized, trusted time sources across mainframe, distributed, and cloud systems.
• Scope: The record shows the policy boundary and permissions in force at decision time, not today's settings.
• Traceability: A reviewer can follow one thread from incident to evidence, recommendation, approval, action, and outcome.
• Retention: Keep records according to your applicable legal, regulatory, and organizational requirements.

Retention periods vary by industry, jurisdiction, and record type. Your compliance, legal, and risk teams should set them.

What does an AI audit record look like during a mainframe batch incident?

A useful AI audit record reads like a short, verifiable incident story. Here's how the 2:47 a.m. settlement job restart from the opening scenario should look.

The scenario: The nightly payment settlement job, PAYSETL01, abends in STEP040 with Db2^® SQLCODE -911. An online Customer Information Control System (CICS) transaction ran past its normal window and held locks on the settlement table. An AI agent investigates, identifies the lock conflict, and recommends a restart once the lock holder clears. The on-call operator escalates to the batch operations lead, who approves.

Notice what this record does. An auditor can verify every claim without calling anyone. The operator can see why the agent made its call. The application team gets a clear follow-up rather than a mystery.

Where does Rocket EVA fit?

Rocket^® EVA^™ fits where operations teams need AI-assisted diagnosis that produces evidence a human can review before anything changes in production.

According to IDC, Rocket EVA lets IT operators and developers ask natural language questions and receive recommendations on incident status, dependencies, and root cause correlations across sources such as IBM Db2^®, SMF, TMON/SDSF, and workload manager data. IDC also notes that Rocket EVA integrates with ticketing systems such as Jira, which helps connect a recommendation to the incident record and to how your organization has resolved similar issues before.

That maps directly to the Context, Evidence, and Recommendation elements of the framework. When a recommendation arrives with the supporting signals attached, operators can validate it, and auditors can trace it later. It also helps less-experienced staff work through an investigation while mainframe subject matter experts stay in control of judgment-heavy decisions.

For the Identity, Authority, Human Approval, and Action elements, confirm current capabilities with official Rocket Software documentation. The goal stays the same either way: better diagnosis and governed action on top of the systems you already run, without disrupting the processes your teams trust.