Audit AI Tool Calls Without Secrets

When an agent changes a record, the team needs to answer who asked, which tool ran, and whether it succeeded. A full transcript is often unnecessary and can copy secrets or customer data into a second store. Design a narrow tool-call event that explains the decision without retaining raw arguments.

OWASP's logging guidance emphasizes useful security events and protection of sensitive data. For agent tools, separate the model's proposal from the server's authorization decision and the actual downstream effect. A successful tool response does not prove that the external service accepted a change.

Minimal event schema

Set retention by investigation need and data policy. Protect audit access separately from ordinary application access. A user who can run a tool should not automatically edit its event record. Use a monotonic event sequence or durable append-only store where appropriate, but do not claim tamper-proof logging without a verified design.

Redaction test

Create a synthetic credential marker and place it in a tool argument, an upstream error, and a tool result. Exercise an allowed call and a denied call. Search the audit sink, application logs, traces, and alerts for the marker. None should contain it. Verify that the remaining event still lets a reviewer distinguish the denied request from a downstream failure.

Check failure paths too. Exceptions and retries often use different logging helpers. Record both a positive business effect and a rejected action in the test evidence. If redaction removes all context, replace raw fields with stable safe identifiers rather than turning logging off. Review the schema when a new tool class is added. A log is evidence of observed behavior, not proof that an agent had authority to act.