Agents and Audit Trails: A Growing Problem
After Enron and Worldcom used shady accounting practices to hide debt and overstate earnings in the early 2000s, it became clear that the United States needed some extra federal laws regarding financial reporting. The Sarbanes-Oxley (SOX) Act was created in 2002 to, among other things, ensure payments and financial actions each came with their own digital audit trails.
Audit trails are step-by-step chronological records that show who did what, when, how, and often why. If a payment was made or an account was created, this evidence must exist somewhere within the system that was used. The problem is that SOX is 24 years old, and the financial software in place at the time was prehistoric compared to what we have today. The drafters of SOX also didn't plan for AI.
SOX binds public issuers, not private startups. If you're private, none of it applies to you yet. The expectations arrive early anyway, through your auditors, your investors, and anyone who might eventually acquire you.
Today's AI agents can autonomously detect suspicious payments, send money, assist with reconciliation, and even make purchases. Each of these actions needs evidence to create an audit trail, both for the sake of data security compliance and the company's own processes. Even if the agent makes better decisions than the employees that came before it, it will still fail an audit if no one can explain why.
8 Questions Every Audit Trail Has to Answer
An audit trail is an evidence chain built for an independent reviewer, and in turn, it needs to answer eight questions. The framing below is ours, not any standard body's. If you want something citable to check against, it maps closely to the documentation and traceability expectations in NIST's AI Risk Management Framework and ISO/IEC 42001.
- What happened, including the resulting state change
- Who or what initiated it (human, service account, agent)
- When it happened, with timestamps and time zones
- Why it happened: the policy, rule, or approval that authorized the path
- With what authority: roles, permission scopes, delegated approvals
- Using what data: inputs, sources, version IDs, transformations
- With what controls: checks performed, exceptions raised, overrides granted
- Where the output went: downstream systems, payments, filings
If you can't answer all eight questions about a financial action your AI agent took, you only have partial telemetry, not an audit trail. While humans may be able to cobble together evidence in a pinch, decision rationale that isn’t recorded on the spot by an agent is essentially lost forever.
Is it possible for an agent to answer all eight consistently? Yes, but you can’t always count on it.
Why a Chat Transcript Is Not an Audit Trail
One of the biggest obstacles to consistent audit trails is the probabilistic models that AI agents are built on. They’re non-deterministic, and the same agent won’t necessarily take the same path twice. So, when an auditor tries to ask an agent why it bought the item it did and whether it can reproduce the path it took, that agent may not be able to.
You might have the full chat transcript, but that doesn't cover the eight questions that make up the evidence chain. You'll need a structured decision record that includes the rule that fired, the threshold evaluated, the policy version in effect at the time, and the tool version that executed. You don't need to rerun the model. You do need to prove what the system decided and on what basis.
When an Approval Isn't Evidence
Another key step to developing an audit trail is understanding the approval. While agentic setups almost always come with approvals in some form, the necessary context isn't always present. If the authorization for a $9,000 purchase exists as a Slack message with no durable link to the transaction record, the trail runs out of breadcrumbs. An approval that says "yes" without capturing the proposed payload, the supporting calculation, and the approver's role doesn't fully work as defensible evidence.
While these problems may be noticed by external auditors, they ultimately stay within the bounds of your company. Agentic AI compliance issues can become a bigger deal when they run up against nationwide frameworks or international regulations.
What SOC 2 Requires of an AI Agent
SOC 2 is an AICPA attestation framework. It isn't a regulation and it isn't a certification. It evaluates controls against five trust services categories: security, availability, processing integrity, confidentiality, and privacy. Only security is mandatory in every report, which is worth knowing when you review a vendor's SOC 2. A clean Type II can exclude processing integrity entirely.
Processing integrity is the category that matters most for agentic purchasing. It asks whether system processing is complete, valid, accurate, timely, and authorized. Nothing about it is payment-specific, but payments are where a failure costs you money.
The security criteria assume that every actor in a system has an identity, a defined role, and specified permissions. An agent operating under a shared service credential breaks that assumption immediately. Worse, if that same agent can propose a purchase, approve it, and execute it, you've essentially thrown the segregation of duties out the window.
To match the framework’s processing integrity criteria in particular, your agent’s outputs need to be completely visible, including retries and partial failures. If an agent retries a payment API three times and only succeeds on the third try, you have to be able to make sure there weren’t any duplicate payments executed or money moved during the failed attempts.
Multi-agent setups make this harder, not easier. Every handoff is a place where evidence gets dropped. If one agent gathers the vendor quotes and another executes the payment, your record has to show the link between the two, not just the two events sitting separately in a log.
Overall, to stay SOC 2 compliant, your oversight mechanisms and security controls need to extend to your AI agents. Since the requirements for creating a clean audit trail also include establishing extra oversight and controls, working towards one can help you with the other.
5 Things to Get Right for Agentic AI SOC 2 Compliance
This is our checklist rather than a list published by the AICPA. As you plan out your AI agent's pathing logic and controls, cover each of the following five bases.
- Attribution: Who initiated a financial action, who reviewed it, and who approved it. The answer to these questions can’t be “the agent did it”. Your agent’s actions, tool invocations, and data access requests should be cryptographically tied back to a human decision-maker..
- Evidence: The context and policy that supported the decision. This means the data snapshot the agent read, the version of the policy in force, and any metrics that determined the path of actions should always be accessible. Since AI doesn’t need to guess at what it’s doing, it’s the user’s responsibility to configure auditable workflows up front.
- Action lineage: Every tool call and side effect, including the retries. For each request, AI agents perform actions like reading code and performing research for context. Those tasks should be possible to record. While evidence is more like motivation, action lineage relates to the tools the AI calls upon to complete the goal.
- Control enforcement outside the model: Permissions, thresholds, segregation of duties, and idempotency. Importantly, these need to be enforced by programming, not remembered by the agent. It’s like the difference between putting a leash on your dog and verbally telling it to stay within a ten foot radius. Auditors will want to see a leash.
- Reconstruction: Enough versioned data to reconstruct an event months later without exposing sensitive information to the reviewer. In order to keep that kind of data safe, you’ll want to turn personally identifiable information (PII) into references and hashes, since it’s a liability to have credit card information and SSNs sitting in audit trails.
While some agents carry all five of these attributes, many don’t. It can be easy to forget a few when your AI agent is built for lower-risk tasks like arranging calendars, monitoring consumer trends, and coding website widgets. You absolutely cannot forget a few if your agent works with money and makes purchases.
How Twin Is Built for Auditability
Slash comes with an AI financial assistant named Twin, which works in Slack against live account data. Twin can make purchases, send payments, create and freeze corporate cards, project cash flows, and much more.¹ It's designed so that finance teams can produce the evidence the five items above call for.
- Clear, auditable records: User requests and tool activity can be logged in full.
- Consistent context: Approvals, exceptions, and completion notices can remain in the same thread as the work, along with the reasoning and evidence behind each decision.
- Extra safeguards for high-risk actions: Enforceable approval gates, scoped permissions, and tool- or workflow-level policy checks can be added when necessary.
- Sandboxed execution: Work can run in isolated environments, reducing the risk of data exposure and far-reaching mistakes.
Twin’s scoped access, isolated execution, monitored integrations, change controls, and auditable activity records are built to help keep operations SOC 2 compliant. If you're trying to execute financial tasks with an AI agent without breaking compliance rules or abandoning audit trails, reach out to Slash to find out how Twin fits into your finance stack.
Apply in less than 10 minutes today
Join the 10,000+ businesses already using Slash.
