Metadata-Only AI Tracing: Processing Is Not Storage

“Metadata only” describes a storage choice. It does not tell you whether an evaluation service received the original prompt, whether a judge sent text to a separate model, or whether a saved regression case retained a payload.

That distinction matters when reviewing an agent security or observability integration. A useful review follows the information through processing, capture and deletion instead of relying on a single privacy label.

Draw the processing path first

List the application, Nyraxis API, selected detector or judge, model endpoint, telemetry exporter, alert destination and report recipient. For each hop, record the operator, account owner, purpose, region and contract.

For a direct evaluation, the API needs the submitted text to evaluate it. A selected model-backed detector may send that text to another configured endpoint. Disabling trace capture does not eliminate those operations.

If you use your own model account, identify which organization contracts with that model provider. Private hosting also needs an egress review: a database inside a private network does not establish that all model requests stay there.

Inspect what capture settings actually control

Nyraxis organization settings establish a capture ceiling. A request can restrict capture further, but cannot widen it. Metadata-only records can retain identifiers, timings, model identity, token counts and policy outcome counts while withholding workload content fields.

The Python instrumentation option that suppresses prompt/completion attributes has a different role from direct evaluation. Likewise, no_trace suppresses evaluation trace recording; it does not mean no operational or accounting record exists.

Use the data handling guide for the scope of these controls. Review API responses and application logs separately from stored traces: a caller can still leak sensitive information by logging a response wholesale.

Treat saved tests as another dataset

A regression test needs an input to run again. If you deliberately retain that input, document why, who can access it and how it will be removed. Do not assume a metadata-only trace policy automatically describes every saved case or fixture.

Start with a fictional marker, such as DEMO-ONLY-NEVER-USE, rather than an actual secret. Use reserved test addresses and fictional records for examples.

Test deletion rather than only reading its setting

A retention value is configuration. A completed cleanup is operating evidence.

Create a synthetic old record in an isolated test environment, run the intended cleanup process, and inspect the relevant active records. Review saved cases, audit records, infrastructure logs, backups and previously exported reports separately. Do not change a production clock or insert real customer data to prove deletion.

Agree a backup expiry and restore procedure so that a restored snapshot does not silently reintroduce records that should have expired.

Prepare a procurement packet

Keep a concise record of:

• Processing roles and the applicable agreement.
• Actual provider entities, destinations and any required transfer mechanism.
• Capture settings and permitted changes.
• Access controls and operational responsibilities.
• Active-record, saved-test, log and backup lifetimes.
• Rights-request and incident contacts.
• Synthetic evidence that the configured controls worked.

Our trust center, provider directory and processing-agreement guidance provide starting points. They do not replace a deployment-specific agreement.

For the legal principles behind this engineering review, see the EU GDPR, especially purpose limitation, minimisation and storage limitation. Applicability and contractual requirements depend on the actual processing; this article is an engineering guide rather than a legal opinion.