Audit Logs and Approvals for AI Agents

An AI agent that can read data and take actions is a new kind of actor inside your systems. When something goes wrong, or when an auditor asks, you need to answer three questions: what did the agent do, why did it do it, and who allowed it. Teams that add logging and approvals late usually find that the data they need was never captured. This article lists what to build in from the start.

Start with the questions you will be asked

• What exactly did the agent do on this date, for this customer or record?
• What information did it see, and which model and instructions were in use?
• Was a person involved, and who approved the action?
• Can you show that the record has not been altered since?

Design your logs to answer these directly, rather than hoping to reconstruct the answer from scattered application logs.

What to record

For every run, capture:

• The trigger: which webhook, schedule or API event started it, and who or what sent it.
• The version of the agent workflow, the instructions and the model used.
• The context the agent received, with sensitive fields redacted or tokenised where policy requires.
• Every tool call: which tool, the inputs, the output and the time taken.
• Every decision that needed approval, including who approved or rejected it and when.
• The final result and its status, including errors and retries.

Give every run a unique ID and link all of these events to it, so that one query returns the full story.

Make the record trustworthy

• Write logs to append-only storage and restrict who can delete or edit them.
• Add tamper evidence, such as hash chaining or periodic signed checkpoints, if your compliance regime requires it.
• Set retention periods that match your legal obligations, and apply the same rules to redacted and unredacted copies.
• Keep personal data out of logs where you can. Log identifiers rather than full records when that is enough.

Approvals: put a person where the risk is

Not every action needs a human. Approvals cost time, so use them where the consequences justify it:

• Actions that move money, change customer records, send external messages or delete data.
• Actions above a threshold, such as an amount, a number of records or a confidence score.
• Anything the agent has never done before.

A good approval request shows the proposed action, the reason, the data it is based on and what happens if it is rejected. Set timeouts and an escalation path, so that a request nobody answers neither blocks the workflow forever nor proceeds silently.

Least privilege for tools and data

Give each agent only the tools and data it needs for its job, and use separate service accounts per workflow. Role-based access should control who can build, edit, run and approve, and those roles should be separate: the person who writes a workflow should not be the only person who can approve its riskiest actions.

Test and review the behaviour

• Keep a set of realistic test cases and run them whenever you change instructions, tools or models.
• Sample real runs regularly and have a person review them.
• Alert on unusual patterns: sudden spikes in tool calls, repeated failures or actions outside normal hours.

Where to begin

• Decide the questions your audit trail must answer.
• Define which actions need approval, and who approves them.
• Turn on run-level logging and role-based access before the first pilot goes live.

Governance and auditability are built into every NARIRO agent rather than added afterwards. If you want to talk through a rollout in a regulated environment, contact our team.