Why ordinary application logs are not enough

A local AI agent rarely stops at a single model request. It searches a RAG knowledge base, calls a CRM or ERP system, creates a file, requests approval, and retries an operation after an error. When the outcome is wrong, management needs more than an answer to “what did the model say?” They need to know which data the agent saw, which action was authorized, and who approved the result.

The simplest approach is to log everything: the system prompt, conversation, retrieved passages, tool arguments, and system responses. In a protected environment, this is a dangerous architecture. The observability stack quickly becomes a duplicate store of commercial documents, personal data, access tokens, and internal instructions. Access to that store is often broader than access to the source systems, while retention is longer.

OpenTelemetry explicitly warns that instructions, inputs, and outputs can be both large and sensitive. Its current GenAI conventions do not recommend capturing that content by default. OWASP separately advises against directly recording access tokens, passwords, encryption keys, connection strings, and sensitive personal data.

The practical conclusion is that a good agent audit is not a full transcript of its work. It is a provable chain of events with the minimum necessary references to source data.

Separate tracing from auditing

The two records serve different purposes.

  • Operational tracing helps engineers find a slow request, retry loop, or integration failure. It contains a `trace_id`, durations, error codes, operation names, token counts, and technical metrics.
  • The audit journal establishes who initiated an action, which policy applied, which objects were affected, whether approval was required, and how the operation ended.

The same `trace_id` can link both layers, but access rights and retention periods should differ. Support staff may see an aggregated trace with no business content. Events involving legally or financially significant actions should be available only to the limited group responsible for security and process control.

Do not make a SIEM, APM system, or developer dashboard the sole evidence store. Operational data is optimized for troubleshooting and may be sampled. Audit records require predictable completeness for selected events and controlled deletion.

A minimum event schema

For a small or medium-sized business, the right starting point is a shared schema rather than a logging platform. A significant step usually needs only these fields:

  • precise UTC timestamp, `trace_id`, run identifier, and parent-step identifier;
  • initiator type: employee, service, schedule, or another agent;
  • role or service identifier without unnecessary personal data;
  • versions of the agent, model, system instruction, access policy, and tool schema;
  • operation type: retrieval, generation, tool call, approval request, execution, or rollback;
  • identifiers and data classes of affected objects;
  • retrieved document identifiers, versions, and relevance scores, but not the passages themselves;
  • tool name, authorized resource, and normalized action type;
  • policy decision: allowed, denied, or approval required;
  • approval identifier and the approver’s role;
  • idempotency key for an external change;
  • result code, error type, duration, and processing volume;
  • hash of a normalized input or output artifact when integrity must be demonstrated.

Operation and status names should have low cardinality. Instead of placing a customer name in the event, store an internal identifier and consult the master system only during an authorized investigation.

What should stay out of ordinary telemetry

Exclude these by default:

  • full prompts and model responses;
  • retrieved RAG passages;
  • email, contract, invoice, and attachment contents;
  • passwords, tokens, API keys, cookies, and connection strings;
  • arbitrary HTTP headers and request bodies;
  • exact personal data when a pseudonym or identifier is sufficient;
  • hidden model reasoning and private system instructions.

Masking after export to a collector is too late: the secret has already left the application. Sensitive-field filtering should run inside the agent process or at the nearest trusted gateway before telemetry is exported.

Regular expressions help with known formats but are not a complete control. Use field allowlists, typed schemas, and validation for every tool’s arguments. Recording five predefined attributes is safer than trying to sanitize arbitrary JSON after an event has occurred.

Architecture of a safe evidence trail

A practical design has six parts.

1. The agent gateway assigns a run identifier and propagates trace context across the model, RAG layer, and tools. W3C Trace Context defines a portable format for linking operations across services.
2. Each significant step creates a structured span or event: model request, retrieval, tool call, approval, and execution.
3. A telemetry policy allows only approved attributes. Message content is disabled, while secrets and personal fields are discarded before the collector.
4. The collector separates flows: technical traces go to the observability system, while mandatory business events go to the protected audit journal.
5. The journal uses immutable or tightly controlled storage with separate roles, access logging, retention rules, and verifiable deletion.
6. A separate evidence vault handles rare investigations. Full artifacts enter it only under an explicit policy, are encrypted, have a short lifetime, and are connected to the trace by a reference rather than a copy.

OpenTelemetry provides a useful vocabulary for GenAI operations, but those conventions are still evolving. Keep the mapping from internal fields to `gen_ai.*` in one versioned adapter. A standards change will then not require rewriting the agent’s business logic.

Example: an agent prepares a payment order

Suppose an agent receives an invoice by email, checks the supplier against a contract, creates a payment draft, and routes it to a financial controller.

The safe audit record contains:

  • identifiers for the email, invoice, contract, and supplier;
  • versions of the validation rules and extraction model;
  • the result of bank-detail matching;
  • the amount as a classified field or range, depending on policy;
  • evidence that a draft was created, but no banking token;
  • the controller’s decision and approval time;
  • the submission idempotency key and payment-system response;
  • a hash of the final document.

If the payment goes to the wrong recipient, this chain is enough to locate the failure: extraction, matching, policy, approval, or execution. The full conversation is not always necessary. If it is required, the trail points to the protected original in the email or document system, which retains its own access controls.

Making the record provable

The journal must distinguish an original event from a later correction. Do not edit rows in place; append a correcting event that references its predecessor. Critical processes may add sequence numbers, signed batches, or a hash chain. These mechanisms do not replace backups or access control, but they help reveal a gap or alteration.

Synchronize service clocks and store both event time and receipt time. This matters for asynchronous queues because a tool response may arrive later and in another process.

Test completeness separately. If a mandatory audit event cannot be recorded, a financially or legally significant action should stop or enter a predefined safe mode. “Continue without an audit record” must be a conscious business decision, not a library default.

Volume and economics

Cost depends less on the number of model requests than on event count, field size, indexes, retention, and the number of copies.

Consider a model calculation: 30,000 runs per month, 12 events per run, and about 0.6 KB of structured data per event produce roughly 216 MB of raw journal data. Indexes, replication, and service fields add to that number. If every step instead stores 20 KB of full content, raw records alone grow to about 7.2 GB before indexes and backups.

This is not a price forecast; it illustrates the effect. Use your own formula:

`runs × events × average size × retention × copy factor`.

Save money by omitting unnecessary content, using different retention periods, and moving rare full artifacts to a separate lower-cost tier—not by sampling mandatory audit events.

A ten-day pilot

For the first stage, choose one process with an external action, such as creating a ticket, changing a customer record, or preparing a payment.

  • Write down five questions an investigation must answer.
  • Approve 10–15 event types and their allowed fields.
  • Link the model, RAG layer, tool gateway, and executor with one `trace_id`.
  • Disable content capture and add tests for tokens, personal data, and document text.
  • Rehearse controlled failures: policy denial, retry, timeout, and rollback.
  • Ask an independent employee to reconstruct the action chain using only the journal.

A useful readiness criterion is that, within 15 minutes, the reviewer can explain who authorized the action, why it was permitted, which versions participated, and which object changed—without opening the agent’s full conversation.

The management takeaway

Do not buy “complete observability” before defining the minimum evidence. First establish the audit-event schema, journal owner, access rules, and retention periods. Then use one process to verify that the journal actually supports an investigation without duplicating sensitive data.

A local environment reduces the risk of sending information to an external provider, but it does not prevent leakage into your own telemetry. A secure AI agent leaves enough evidence for accountability—and not enough to turn the journal into a new source of compromise.