Keep a Record of Every Agent Action

An agent calls issue_refund and the customer gets their money. Later, finance asks why the refund was allowed, but the run's success message only says the tool worked. Can you tell which permission covered the payment?

The evidence has to come from the run itself. By the time someone asks about the refund, the agent may have changed versions and the customer's record may have been updated again.

Follow the action back to its request

Here's a fictional entry, with short values to show how the pieces connect:

{
  "run_id": "run_7f3a",
  "agent": "refund-agent v2.3",
  "request_ref": "protected/request_7f3a",
  "tool": "issue_refund",
  "arguments_ref": "protected/args_7f3a",
  "result": {"status": "succeeded", "amount": "USD 25"},
  "before": {"refund_status": "requested"},
  "after": {"refund_status": "refunded"},
  "approved_by": "finance_approver",
  "started_at": "2026-10-26T10:14:02Z",
  "finished_at": "2026-10-26T10:14:03Z"
}

The run ID connects this event to earlier calls, while the before-and-after values preserve what changed after the live record moves on. The approval and request references explain which authority covered the action; timestamps put it in sequence, and the agent version identifies what was running.

For an action covered by standing permission, the entry would identify that permission in place of approved_by. The arguments themselves sit at the protected reference. Their content belongs under the same privacy controls as the original request.

Each action gets its own entry. If the run also calls update_crm_record, its record shows which field changed and what it was before. That lets finance separate the payment from any later update to the customer's details.

Put sensitive content behind tighter access

The refund request might contain personal information. Tool arguments can carry it into the payment system, and the result can contain more. Copying the full exchange into general logs spreads that information to everyone who can search them.

Limit access. A separate store with tighter permissions lets the action log hold references to sensitive content. Someone checking the payment can request the relevant evidence without giving everyone reading operational logs the customer's conversation.

The OpenTelemetry GenAI conventions described by Greptime define an invoke_agent span and an execute_tool span, with the tool name in the latter's name. Message content capture is off by default; tool arguments and results are recorded only when privacy policy permits. The conventions were still in Development status as of May 2026, so field names may change.

The example uses harmless fictional values. In a real entry, a before-and-after field can contain personal data too. So the choice between storing a value and storing a protected reference applies to changed records as well as conversations.

Give the agent permission to append

If the credentials used to issue the refund also let the agent rewrite its log, the evidence can change along with the action. An append-only store or a separate writer gives the agent a way to add events while keeping past entries outside its edit permissions.

Writing in Help Net Security, João Marques, who founded the agent audit-trail company Asqav, suggests signing each action with a key the agent doesn't hold. The Act doesn't prescribe a format or field list, so the method is the team's choice.

An auditor will ask how you know nobody edited the log while the agent ran. Have that answer before exporting it.

Decide how long the evidence stays

The same byline describes a six-month minimum for retaining logs under the AI Act's retention provisions, with sector rules able to require longer. The automatic-logging duty concerns high-risk systems. FPF's implementation timeline puts the Annex III high-risk date at December 2, 2027.

Retention has to cover the protected content as well as the references in the action log. If the conversation has already been deleted, a surviving request ID can't explain why the action was taken.