Agent-First Data v0.8: Redaction Became a Policy

The _secret suffix is the best default because it makes the data self-labeling: api_key_secret tells the agent what not to expose.

But real systems are not always clean. A legacy API may return password. A third-party payload may use token. A trace may need redaction while a trusted internal response needs raw values. A nested object may contain both public and secret fields.

Agent-First Data v0.8 kept the suffix rule and added explicit redaction policy for the cases where naming alone is not enough.

The default: suffixes still carry the meaning

The recommended shape remains simple:

{"api_key_secret":"sk-123","duration_ms":12}

AFDATA formatters redact api_key_secret, preserve duration_ms in JSON, and format it for YAML or plain output.

That is still the happy path. If you control the field name, use _secret.

The hard case: legacy names cannot always be renamed

Some payloads arrive with fields the tool author cannot change:

{"credentials":{"password":"hunter2","token":"abc"}}

Renaming those fields before every log line is brittle. The v0.8 redaction options let a tool mark exact legacy field names as secret at serialization time:

let options = RedactionOptions {
    policy: None,
    secret_names: vec!["password".into(), "token".into()],
};
let line = output_json_with_options(&value, &options);

The matching is intentionally exact. There is no substring match, regex, glob, case folding, or hyphen/underscore normalization. That keeps redaction behavior predictable enough for an agent and auditable enough for a maintainer.

The policy: choose where redaction applies

The v0.8 API exposes redaction policies:

• RedactionTraceOnly redacts inside top-level trace.
• RedactionNone leaves values unchanged.
• RedactionStrict replaces the entire secret subtree with ***.
• the default policy recursively redacts _secret fields and listed secret names.

This separates two questions that used to be mixed together: which field names are secret, and which part of the payload should be redacted.

The raw path: redacted values are useful outside CLI output

Not every AFDATA value is printed by output_json, output_yaml, or output_plain. HTTP services, MCP tools, and SSE streams may hand JSON directly to a framework.

The v0.8 line added redacted-value helpers so programs can produce a JSON-safe copy before the framework serializes it:

let safe = redacted_value_with_options(&value, &options);

That makes redaction available even when the final transport is not a CLI formatter.

The agent rule: redaction should be explicit enough to reason about

Agents are bad at guessing whether token, key, secretValue, or credential is safe. Humans are bad at auditing fuzzy secret detectors.

AFDATA’s direction is explicitness:

• prefer _secret in new field names
• use exact secret_names for legacy field names
• choose a redaction policy deliberately
• keep formatter behavior deterministic across languages

The outcome is boring in the right way: the same payload redacts the same way in Rust, Go, Python, and TypeScript, and an agent can explain why.