Part of our guide to Sovereign AI in Australia: a practical guide for operators
On this page · 8 sections
- Why a chat transcript is not an audit trail
- The fields every AI agent audit trail should record
- Protecting the trail from the agent itself
- How long to keep agent records
- Using the trail every week, not just in emergencies
- A playbook for a suspected account compromise
- When detailed logging is overkill
- Frequently asked questions
When an AI agent does work for your business, you need a record you could hand to a client, an insurer or a regulator that explains exactly what happened. That record is the audit trail. At minimum it captures, for every action: the instruction and who gave it, what the agent read, what it proposed, who approved it, what actually changed, and when. If you can't reconstruct an action from the trail without asking the agent, the trail isn't finished.
This is one of three controls at the centre of our guide to sovereign AI for Australian operators, alongside narrow access and approval gates. Access limits reduce what can go wrong. The trail tells you what did.
Why a chat transcript is not an audit trail
The conversation where you asked an agent to do something is useful context, but it falls short in three ways. It records what was said, not what was done: the agent saying 'I've updated the record' is a claim, not evidence. It is usually editable or deletable by the same system that did the work. And it mixes many tasks together, so finding every action that touched one client's file means scrolling.
The Australian Signals Directorate's advisory on agentic AI harnesses sets a clear bar: record prompts, responses, tool invocations, approvals, actions, security events and configuration changes, and protect, retain, review and independently monitor those logs. Its joint guidance, Careful adoption of agentic AI services, names accountability risk, the difficulty of tracing decisions and assigning responsibility, as one of five categories of agentic AI risk.
The fields every AI agent audit trail should record
Use this as a checklist when you evaluate a platform, or as a schema if you are building your own logging.
| Field | What it captures | Example |
|---|---|---|
| Requested by | The person whose instruction started the work | Owner, via Telegram |
| Instruction | The request as given, or a reference to it | 'Chase invoices more than 30 days overdue' |
| Agent | Which agent or sub-agent acted, and its role | Accounts agent |
| Read | Which records, files or messages the agent accessed | Xero aged receivables report; 6 contact records |
| Proposed | What the agent drafted or recommended | 6 reminder emails |
| Approved by / when | Who approved each item, and what they saw | Owner approved 5, edited 1, at 9:14 am |
| Changed or sent | The actual effect: messages sent, records changed, with before and after | 5 emails sent; 1 CRM note added per contact |
| Integration and scope | Which connection was used, with what permission | Microsoft 365 mail, send after approval |
| Timestamp | When each step happened, in one time zone | 2026-11-03 09:14 AEDT |
| Outcome or error | Whether it worked, and any failure | 1 bounce: address no longer valid |
Two additions earn their place for anything sensitive: the model path used for the step (for example whether an Australian-hosted model handled it), and any rule the agent saved to memory as a result. Memory changes are where a manipulated instruction can hide, which is why they belong in the record; our article on prompt injection through email explains how.
What not to log
- Passwords, API keys, tokens and one-time codes. If a secret appears in a log, treat it as exposed and rotate it.
- Full card numbers or bank login details.
- More personal information than you need to reconstruct the action. A reference to a record is often better than a copy of it.
Keeping secrets out of the trail starts with keeping them out of prompts; least-privilege access for AI agents covers that.
Protecting the trail from the agent itself
An audit trail the agent can edit is a diary, not evidence. ASD's guidance recommends isolating agents so they have no write access to logs, and quarantining any request to delete logs or audit records until a human has reviewed it. For a small business, that translates into three checks on any platform:
- Agents can write to the log only by acting, never by editing past entries.
- Deleting or shortening logs requires a person with admin rights, and is itself logged.
- You can export the log yourself, in a format you can open without the vendor's help.
How long to keep agent records
There's no single retention period for AI logs. Two pressures pull in opposite directions. You want records long enough to investigate a complaint, a dispute or a suspected breach. But if you are covered by the Privacy Act, APP 11 also expects you to take reasonable steps to destroy or de-identify personal information you no longer need. Our Privacy Act and AI tools guide covers which businesses that applies to.
A practical approach: keep the action record (who, what, approved, changed) for as long as you keep the underlying business record it relates to, because they are part of the same story. Keep bulky detail, such as full prompts and model responses, for a shorter period that covers your realistic investigation window. Check any record-keeping obligations specific to your industry; they take precedence. This is general information, not legal advice.
Using the trail every week, not just in emergencies
A trail nobody reads catches nothing. Ten minutes a week is enough for most small businesses:
- Scan for actions outside the usual pattern: new recipients, a jump in volume, access to folders or pipelines an agent doesn't normally touch.
- Check rejected and edited drafts. They show where agents misunderstand your rules, which is cheaper to fix than a sent mistake.
- Look for new rules saved to agent memory and confirm you meant them.
- Note anything that should become a standing rule or an access change.
Better still, have the agents summarise exceptions for you each day so the weekly scan is short. We describe that in the daily exception report. In Fulcrum Cortex, agents also write notes and next actions into the CRM as they work, so people and agents see the same history on each contact; the CRM page shows how that looks.
A playbook for a suspected account compromise
If you suspect an email, CRM or agent account has been compromised, or an agent has been manipulated into acting against you, the trail is what turns panic into a list of tasks. Write this down now, while nothing is wrong.
- Contain. Pause the affected agents and revoke their integrations. Change the password and sign out all sessions on the affected account, with multi-factor authentication turned on.
- Preserve. Export the audit trail for the affected period before anything else changes. Don't let anyone, human or agent, 'tidy up'.
- Scope. Use the trail to list every record the agent or account read, every message sent and every change made since the earliest suspicious event.
- Assess. If personal information may have been exposed and you are covered by the Notifiable Data Breaches scheme, the OAIC's NDB guidance requires reasonable steps to assess within 30 days, and notification as soon as practicable if it is an eligible breach.
- Fix the cause. Usually an over-broad permission, a missing approval gate or a reused password. Change that before you reconnect anything.
- Reconnect narrowly. Bring agents back on read-only first, and review the trail daily for a fortnight.
When detailed logging is overkill
Not every agent action needs the full schema. An agent that drafts social media captions from your own notes, with nothing sent until you post it yourself, needs a light record at most. Spend the effort where agents touch client data, money or outgoing communication. The rule of thumb: the more an action would hurt if it were wrong, the more you should be able to prove what happened.
One customer's description sums up the standard to aim for. Tony Lorenzo of Elite Partners Real Estate says of his agent: 'She drafts the emails and SMS messages, remembers my rules and logs everything. I give the OK before anything goes out.' Individual results vary. If you'd like to see how agent work is recorded and approved in practice, the platform page walks through it.
Frequently asked questions
What should an AI agent log?
For each action: who asked, the instruction, which agent acted, what it read, what it proposed, who approved it, what actually changed or was sent, the integration used and a timestamp. Don't log passwords, keys or more personal information than you need.
How long should I keep AI agent logs?
Keep the core action record for as long as the business record it relates to, and bulky detail such as full prompts for a shorter investigation window. If you're covered by the Privacy Act, APP 11 expects you to destroy or de-identify personal information you no longer need. Check any industry-specific record-keeping rules.
Can an AI agent delete its own logs?
It shouldn't be able to. ASD guidance recommends that agents have no write access to logs and that requests to delete audit records are quarantined until a human reviews them. Check this before you adopt a platform.
What do I do if I think my AI agent was manipulated?
Pause the agent and revoke its integrations, export the audit trail, then use it to list everything it read, sent or changed. If personal information may have been exposed, assess whether it is a notifiable data breach within 30 days.
Sources
- Agentic AI harnesses · Australian Signals Directorate
- Careful adoption of agentic AI services · ASD's ACSC and partner agencies
- Chapter 11: APP 11 Security of personal information · OAIC
- Part 4: Notifiable Data Breach (NDB) Scheme · OAIC
General information only, not legal, financial or professional advice. Check the source for your circumstances.



