Audit trail for compliance teams: every agent action logged

When AI touches a ledger, the question that decides whether the project lives or dies is not "is the AI smart" but "can we prove what the AI did." Compliance teams have learned to be skeptical of vendor claims about audit trails because too many of them turn out to be a JSON log file in a SaaS bucket the customer cannot easily access. Smart Agents handles audit differently because the extension lives inside Business Central and the audit log is a BC table, written synchronously, owned by the customer.

This post walks through what compliance actually gets, what the schema looks like, and which workflows the audit log makes possible.

THE TABLE

Every tool invocation lands as one row in the SA Tool Call Log table. The fields cover everything a compliance review tends to ask about. The BC user who initiated the chat. The Smart Agent that ran the tool. The Smart Agent Session ID, so you can reconstruct the full conversation that surrounded the action. The tool name and the tool config it referenced. The parameters the agent passed (truncated for very large payloads, with the full payload retrievable from the result-set cache). The data scope touched (which tables, which company, which dimensions). The model tier used. The token counts (input and output, separately). The credit cost. The outcome (success, denied, error). The duration in milliseconds. The timestamp.

This is not a best-effort log file written into a vendor SaaS. It is a BC table, retained for a period the customer configures (default 365 days, max 7 years on the Smart Agent Setup record), and populated synchronously: the SA Tool Call BG Runner writes the audit row before the tool actually executes the action. If the audit write fails, the tool does not execute. That is the same reliability contract as the regular BC change log, which compliance teams accepted years ago.

THE COMPANION TABLE: SA EMAIL LOG

For the email channel, the SA Email Log table records every inbound email the SA Email Handler processed. Sender, subject, mailbox, agent routed to, received timestamp, processed timestamp, draft-reply status, and outcome. This sits alongside the SA Tool Call Log: every email triggers one row in SA Email Log, and the resulting tool calls inside the agent's response trigger their own rows in SA Tool Call Log, linked by the session ID.

For the rare case where compliance asks "who emailed us about the November accrual and what did the agent do with it," the answer is two filtered queries against two BC tables, both viewable inside BC by anyone with the SMART AGENTS ADMIN permission set.

APPLICATION INSIGHTS

The Smart Agent Telemetry codeunit emits the same events to Application Insights so the customer's Azure monitoring stack picks them up alongside the rest of their BC telemetry. The events use stable IDs (SA-0003 for credit reservations, SA-0004 for credit confirmations, SA-0010 for Stripe checkout creations, and similar) and structured properties so an analyst can build dashboards without parsing message strings.

For customers who already pipe BC telemetry to a SIEM, the agent telemetry rides the same pipe. No separate connector to maintain. No vendor-side log retention to negotiate.

FOUR COMPLIANCE WORKFLOWS THE LOG MAKES POSSIBLE

First: the GDPR data-subject request. A customer asks for everything you have on them. You filter SA Tool Call Log by data-scope = customer 10000 and you have every AI-mediated read of that customer's data, with timestamps, users, and tool names. You do the same in the regular BC change log for non-AI access. The two filters together produce a complete picture.

Second: the SOC 2 Type II evidence pull. The auditor asks you to demonstrate that AI cannot post journals to restricted G/L accounts without an authorized user. You show them the autonomy configuration on the agents that have post-journal in their tool scope (the screen lives on the Smart Agent card,). You then filter SA Tool Call Log by tool-name = post-journal and outcome = success and demonstrate that every successful post has a real BC user with the appropriate permission set. The auditor signs off.

Third: the cost investigation. Finance asks why the agent bill spiked in March. You filter SA Tool Call Log by month and group by agent. The view shows the per-agent credit burn. Sort descending and you see the offending agent. Filter to that agent and group by tool. You see the offending tool. Filter to the tool and group by user. You see who is running it the most. The investigation that took half a day in the SaaS-log scenario takes an hour with a few BC list-page filters.

Fourth: the incident review. A customer received an embarrassing email. You filter SA Email Log by sender and date and find the inbound email. You take the session ID and filter SA Tool Call Log to it. You see the agent's reasoning steps as the parameter trail and the result-set cache entries. You can show the team exactly what the agent did and what part of the workflow needs adjustment. No "the AI is a black box" excuse.

WHAT THE LOG IS NOT

The audit log is not a model-output log. It does not store every token of every model response. The reasons are pragmatic (cost, retention, GDPR risk if the agent ever quotes customer PII back) and architectural (the model output is reconstructable from the parameters and the tool results in the result-set cache , which retains responses for a configurable shorter window).

The audit log is also not editable. There is no "redact this row" button by design. Compliance teams asked for that explicitly: an audit log you can edit is not an audit log. The retention setting controls when rows expire, and that setting is configured by an admin who has logged the change in the regular BC change log.

WHO HAS ACCESS

The SA Tool Call Log page (, with the API at) is granted to the SMART AGENTS ADMIN permission set by default. Read-only access can be granted to the SMART AGENTS USER permission set tenant-wide if compliance wants every BC user to be able to see what the agent has been doing on their own behalf.

For an external auditor, the path that works is to grant a temporary BC user account with read access to the audit log pages, scoped to a specific date range with a BC company filter, for the duration of the audit. The auditor uses the same BC client every other auditor uses; no special vendor portal to learn.

WHY THIS MATTERS FOR THE PROJECT

Most AI projects in regulated industries die in compliance review. They die because the answer to "prove what it did" comes back as a SaaS link to a vendor portal the compliance team cannot audit on their own terms, with retention they cannot configure and access they have to negotiate. Smart Agents puts the audit data in a BC table that the customer's compliance team already knows how to query. That single architectural choice is the difference between a pilot that ships and a pilot that gets killed in a steering committee.

For the deeper architecture story, see the related blog post on why Smart Agents lives inside BC. For the autonomy controls that prevent the agent from reaching too far in the first place, see the post on tool autonomy levels. For the user-facing setup, see /docs/admin.