Add in-flight PII checks for traces using a fast model

[marcusschiesser]

Problem

AgentPond can ingest traces that may contain personally identifiable information in prompts, outputs, tool arguments, metadata, or span attributes. Today, PII handling is not called out as an in-flight trace guardrail. Users need a way to detect and optionally block, redact, or flag sensitive trace data before it is persisted or forwarded.

Reference: https://x.com/MaziyarPanahi/status/2073383825669849118

Proposal

Add an in-flight PII check path for traces that uses a fast, low-latency model/classifier suitable for request-time decisions.

Suggested behavior:

• Inspect trace payloads before storage/export, including span inputs, outputs, attributes, events, metadata, and tool payloads.
• Use a fast model/classifier for PII detection so the check can run inline without materially slowing ingestion.
• Return structured findings with field path, PII category, confidence, and matched/redacted preview where safe.
• Support configurable policy modes: off, log, redact, and block.
• Support allowlists/denylists for known safe keys or fields that must always be checked.
• Emit metrics/logs for detection count, latency, action taken, and failures.
• Fail according to configuration, for example fail-open by default with an option for fail-closed in regulated deployments.

Acceptance Criteria

• Users can enable in-flight PII checks for traces through documented configuration.
• Trace ingestion applies the configured action before persistence/export.
• PII findings are represented in a typed internal structure and are test-covered.
• Redaction preserves trace shape while replacing sensitive values consistently.
• Blocking returns a clear error that does not echo sensitive input.
• Latency and model/classifier failures are observable.
• skills/agentpond/SKILL.md and skills/agentpond/references/cli.md are updated if the implementation adds commands, flags, prompts, environment variables, or storage setup.
• A changeset is added for the user-facing behavior change.

[marcusschiesser]

A concrete concern surfaced while adding AgentPond tracing to Vercel AI SDK applications: enabling AI SDK telemetry records input and output values by default, and a private object store controls access but does not provide data minimization, redaction, or retention.

Reference discussion: keinsaasforever/better-chatbot#387 (comment)
Vercel telemetry behavior: https://ai-sdk.dev/docs/ai-sdk-core/telemetry

I suggest extending this issue beyond model/classifier-based detection with deterministic controls that run before serialization and persistence:

• Add an exporter/ingestion content policy such as metadata-only and full, with content capture requiring an explicit choice.
• Apply attribute allowlisting and content-attribute denylisting across resource attributes, span attributes, events, prompt/message fields, outputs, tool arguments, tool results, and error payloads.
• Support a synchronous redaction hook before any object-store write; classifier-based PII detection can augment this, but should not be the only guardrail.
• When correlation is needed without retaining content, support keyed HMAC fingerprints rather than plain hashes, since predictable or low-entropy content is vulnerable to dictionary matching.
• Add retention enforcement: object-store deletion support plus a command/policy such as prune --older-than, with shorter retention available for content-bearing traces.
• Make fail-open/fail-closed behavior explicit and observable, including counters for redacted, blocked, and policy-failure spans.
• Add exporter-level tests that assert forbidden content attributes are absent after sanitization while model, tool name, token usage, timing, status, and error-class metadata remain available.

The source-side AI SDK controls (recordInputs and recordOutputs) should still be documented and set deliberately, but exporter-level enforcement is important because other OpenTelemetry/OpenInference instrumentors can emit sensitive fields independently.