How Do You Audit What an AI Agent Did in SAP?

To audit what an AI agent did in SAP, give every agent its own SAP user ID, rely on SAP's native change documents for the what, and store the agent's decision trace (inputs, tool calls, confidence, and the version of the policy it applied) next to each document for the why. Neither A2A nor MCP produces that trail for you; a June 2026 gap analysis by Richard Kang and Yudho Diponegoro on arXiv scores audit/replay as Absent in A2A v1.0.1 and only Partial in MCP v1.1.

Why this question is landing on CIO desks now

Two developments made this a 2026 board topic. First, A2A reached its stable 1.0 specification and, per the Linux Foundation's April 2026 press release, counts more than 150 supporting organizations including SAP, AWS, Microsoft, and Google, with native support in Azure AI Foundry and Amazon Bedrock AgentCore Runtime.

Second, SAP itself is shipping agents that act inside procurement. SAPinsider reports an 11-assistant Joule rollout across SAP Ariba: five live in June 2026, six more planned for September, with SAP's Sapphire 2026 Innovation News Guide listing the Buying and Receiving Assistants among the September group. Once buyers' and suppliers' agents both create transactions, "who did what, and why" stops being hypothetical.

What A2A and MCP actually give you

Identity and plumbing, not accountability. A2A 1.0 added Signed Agent Cards for cryptographic identity verification, which the Linux Foundation lists as a delivered enterprise requirement; that solves "is this really the agent it claims to be." MCP defines how an agent reaches tools and data. Neither was designed to answer an auditor.

Kang and Diponegoro's paper, Governance Gaps in Agent Interoperability Protocols, scores five protocols on six governance dimensions (membership, deliberation, voting, dissent, human escalation, audit/replay). Both A2A v1.0.1 and MCP v1.1 score 1 out of 12. On the two dimensions an SAP auditor cares about most, the findings are specific: human escalation is Absent in every protocol analyzed, and A2A's Traceability extension "adds correlation IDs for distributed tracing but does not define tamper-evident logs or replay semantics." MCP's Elicitation feature requests human input mid-task, which the authors classify as input solicitation, not governance escalation.

Their conclusion: governance is a missing architectural layer above these protocols, not a missing feature inside them. Expecting A2A to produce your audit trail is like expecting the postal service to keep a copy of every letter.

The four things an SAP agent audit trail needs

1. A dedicated SAP user ID per agent

SAP's audit substrate (change documents CDHDR/CDPOS, the Security Audit Log, created-by fields) keys off the user ID. If an agent posts under a shared service account or a human's credentials, the trail is destroyed before it starts. One agent, one user ID, one role, scoped to the BAPIs that agent may call. Filtering VA05 on that user then lists every document the agent touched.

2. SAP's own change documents for the what

Do not build a parallel ledger. Change documents are retained under your existing policy and trusted by your external auditors. Route agent writes through standard BAPIs so those change documents are actually produced, never through direct table updates.

3. A stored decision trace for the why

This is the layer the protocols do not provide. For every SAP document an agent creates or changes, persist the original input (the customer PO PDF, the email, the A2A task message), the model and prompt version, every tool call and its result, the simulate-before-create output, the confidence score, and the policy version in force, linked to the SAP document number. When an auditor asks why an order carries a 12 percent discount, you open one record and show the price-list lookup, the contract clause the agent matched, and the human who approved the exception.

In SayfeAI's easyOrder deployments this trace is written before the BAPI commit for every order; it is why our aggregate production numbers (98,989+ orders, 95 percent touchless, 99.2 percent accuracy across three or more customers) carry a paper trail.

4. An explicit escalation rule, enforced outside the model

No protocol encodes human escalation, so define it yourself and enforce it in code, not in the prompt: orders above a value threshold, new ship-to addresses, price deviations from contract, fields below a confidence floor. The agent parks the document; a named human releases it. The trace records both.

Where the trail lives is an audit question too

If the agent runs in a vendor's cloud, the decision trace sits in the vendor's log store under the vendor's retention policy. Self-hosting on-premise or in your own AWS account keeps the trace inside the same audit boundary as SAP itself. That is not a criticism of Joule or BTP; it is about where your evidence sits when a SOX checklist asks for it.

For clarity: SayfeAI (sayfe.ai) is a self-hosted agentic AI platform for mid-market SAP, separate from Sayfe.ai (sayfeai.com), an OpenAI partner that deploys ChatGPT Business for small businesses.

Frequently asked questions

Do I need a separate audit tool for AI agents, or does SAP's Security Audit Log cover it?

SAP's audit log and change documents cover the what, provided each agent has its own user ID and writes through standard BAPIs. They do not cover the why: the inputs, tool calls, and reasoning behind the write. You need a decision-trace store for that, linked by document number; most mid-market teams keep it in a database they already run.

If A2A adds Signed Agent Cards, isn't identity solved?

Between agents, largely yes. Inside SAP, no: SAP does not read Agent Cards, it reads user IDs. You still map each agent to a scoped SAP user and role, and treat the Agent Card as the credential that authorizes the mapping, not as the audit record.

Can we replay an agent's decision six months later?

Only if you stored the model version, prompt, policy version, and exact tool outputs at the time; models and price lists both change. Kang and Diponegoro define audit/replay as "deterministic reconstruction of the decision process," which message-traffic logs alone cannot deliver.