Skip to main content

Sensitive Field Audit Masking

Evidence boundary: The maintained Golden Path verifies evaluator guidance for an email field and regenerated audit_mask_fields metadata. Rust masking logic has been source-reviewed, but safe-sink output for all value shapes and failure paths has not been executed as maintained evidence.

TeaQL can mark fields at the model level for masking on runtime paths that consume the generated metadata and emit safe audit events. This does not prove that every log, response, export, exception, or custom audit sink is masked.

This is important for privacy and compliance because audit logs are often read by more people and systems than the original business data. A runtime may need to record that a field changed, who changed it, and why, without showing the full password, token, passport number, account number, or personal identifier.

Model-Level Masking​

Use _audit_mask_fields on an entity to declare which fields should be masked when TeaQL builds safe audit events.

Example:

<customer
  _name="Customer"
  name="string()"
  email="string()"
  phone="string()"
  passport_number="string()"
  _audit_mask_fields="email,phone,passport_number" />

The model remains the source of truth. Generated code carries masking metadata for compatible runtime consumers; applications must still verify which sinks use safe events and which paths bypass the generated audit flow.

Generator Evaluation​

TeaQL generation/evaluation can report likely sensitive fields before runtime. In the recorded model change, email produced contact-identifier guidance and the follow-up model declared _audit_mask_fields="email". Treat other keyword, severity, and framework mappings as version-sensitive evaluator behavior: read the complete Markdown report instead of relying on a copied keyword table.

Runtime Behavior​

In the reviewed Rust runtime source, generated entity metadata is carried into the entity descriptor. A compatible safe-audit path reads:

  • _audit_mask_fields: masks configured field values.
  • _audit_value_max_len: limits audit output length when configured.

The safe audit event can still show useful compliance metadata:

  • field name,
  • whether the field was masked,
  • whether the value was truncated,
  • raw value length,
  • output value length,
  • mask reason,
  • truncate reason.

This is the intended safe-event shape. Verify the configured sink and emitted payload before claiming that raw values are absent.

Masking Shape​

The reviewed Rust implementation currently describes this masking shape:

  • Empty values stay empty.
  • Numeric values are fully replaced with *.
  • Short values are fully replaced with *.
  • Longer non-numeric values keep a small prefix and suffix while masking the middle.

Re-check the pinned runtime and test boundary values before depending on the exact output. Masking is not reversible encryption, tokenization, or access control.

What This Protects​

Audit masking helps reduce exposure in:

  • operational audit streams,
  • support-facing audit views,
  • compliance review exports,
  • observability pipelines,
  • event sinks that should not receive raw PII or secrets.

It is especially useful for fields such as:

  • passwords and secrets,
  • API tokens and JWTs,
  • passport or ID-card numbers,
  • payment card references,
  • phone numbers,
  • email addresses,
  • bank account identifiers,
  • health or birth-date fields.

What This Does Not Replace​

Audit masking is not a complete privacy program by itself.

It does not replace:

  • database encryption,
  • column-level database permissions,
  • authorization checks,
  • field-level read policies,
  • consent management,
  • retention and deletion rules,
  • data residency controls,
  • secrets management.

Use it as one layer in a broader privacy architecture: model the sensitive field, restrict who can read it, audit why it was accessed, and mask it when it appears in audit-safe event output.

  1. Mark known sensitive fields with _audit_mask_fields.
  2. Treat evaluator errors as blocking when the current Markdown report says the model is invalid; review warnings and suggestions explicitly.
  3. Review warnings for PII fields before approving the model.
  4. Configure _audit_value_max_len when audit output could contain long free text.
  5. Keep raw evidence and raw sensitive values out of support-facing audit exports.
  6. Do not rely on application developers to manually mask every audit event.
  7. Confirm whether each audit sink receives raw audit events or safe audit events.

Review Checklist​

Before approving a model with personal or sensitive data, check:

  • Are passwords, tokens, government identifiers, card references, and secrets listed in _audit_mask_fields?
  • Are phone, email, address, bank, health, and birth-date fields reviewed?
  • Does generation/evaluation report any privacy masking errors or warnings?
  • Does the runtime route external audit consumers to safe audit events?
  • Are long text fields truncated for audit output when needed?
  • Do compliance exports avoid raw sensitive values unless explicitly authorized?