A configuration choice that strips sensitive request and response fields from exported telemetry. It is a practical minimisation control for AI systems where trace usefulness must be balanced against the risk of leaking prompts, completions, or secrets into downstream tools.
Expanded Definition
Request Data Exclusion is a telemetry governance setting that prevents selected request and response fields from being written to exported logs, traces, or analytics pipelines. In AI and agentic systems, that usually means removing prompts, completions, tool inputs, API keys, tokens, and other sensitive content before data leaves the originating service. The goal is not to eliminate observability, but to keep diagnostics useful while reducing the chance that sensitive material is replicated across SIEM, data lake, or third-party monitoring tools.
Unlike broad log masking, this control is typically field-based and deliberate. Teams choose exclusions because the data may be highly variable, language-rich, or unstructured, which makes later redaction unreliable. Guidance varies across vendors, and no single standard governs the exact schema or naming of excluded fields yet. The closest governance anchor is NIST SP 800-53 Rev 5 Security and Privacy Controls, which reinforces data minimisation, logging discipline, and protection of sensitive information. The most common misapplication is treating request data exclusion as equivalent to encryption, which occurs when teams assume sensitive fields are safe simply because the transport or storage layer is encrypted.
Examples and Use Cases
Implementing request data exclusion rigorously often introduces a visibility tradeoff, requiring organisations to weigh faster troubleshooting against reduced access to raw payloads.
- An AI support assistant excludes user prompts and model outputs from exported traces, while retaining timestamps, status codes, and latency metrics for incident analysis.
- A code-generation agent removes source snippets, API tokens, and internal repository paths before forwarding telemetry to a central observability platform.
- A customer service workflow excludes personal data fields such as account numbers, email addresses, and free-text notes before logs are replicated to a security analytics tool.
- An engineering team keeps tool-call metadata but strips arguments that may contain secrets, reducing the chance that credentials spread into downstream systems.
- Security teams align the exclusion policy with internal logging standards and data handling guidance, then validate it against practices described in OWASP Application Security Verification Standard and privacy-oriented logging expectations from the NIST Privacy Framework.
In practice, this control is often used where request payloads are unpredictable or long-lived in observability stores, making post hoc sanitisation too risky or too incomplete.
Why It Matters for Security Teams
Request Data Exclusion matters because telemetry is one of the easiest places for secrets, personal data, and business-sensitive context to spread unintentionally. Once exported, that data can be copied into multiple platforms, retained longer than intended, and exposed to broader operator groups than the original application allowed. For AI systems, the risk is sharper because prompts and completions may include credentials, proprietary instructions, or regulated personal data. Exclusion controls therefore support both security and privacy objectives, especially where logs are used for incident response, fraud review, or model monitoring.
This concept also intersects with identity and NHI governance. When agents, services, or integrations authenticate with tokens and certificates, excluding those values from traces reduces the chance that machine identities leak into logging backends or support tickets. That makes the control relevant to NHI hygiene as well as AI observability. The practical question is whether teams can still diagnose failures without exposing the very material they are trying to protect. Organisations typically encounter the operational cost of weak exclusion only after a log review, breach investigation, or vendor sharing event, at which point request data exclusion becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST AI RMF and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-1 | Supports protection of data at rest, including sensitive telemetry exports. |
| NIST SP 800-53 Rev 5 | AU-3 | Logging controls require audit records to capture useful context without excess sensitive content. |
| NIST AI RMF | AI RMF addresses data governance and monitoring tradeoffs relevant to telemetry minimisation. | |
| OWASP Non-Human Identity Top 10 | NHI guidance addresses machine credentials that may appear in request logs and traces. | |
| NIST SP 800-63 | IAL2 | Identity data handling discipline is relevant when telemetry contains user identifiers or verification data. |
Strip machine secrets from telemetry so NHI credentials are not replicated into downstream tools.
Related resources from NHI Mgmt Group
- How should teams reduce repeated database reads in a single request without risking stale identity data?
- What breaks when a secrets vault trusts request data for identity verification?
- How should privacy teams automate data subject request handling without losing control?
- Who is accountable when an LLM-initiated MCP request causes data exposure?
