A user defined header is a per user value passed by the platform to a shared MCP server on each request. It allows one multi user deployment to preserve user specific context without spinning up a separate server instance for every person, provided the server is built to read that header safely.
Expanded Definition
A user defined header is a per-user value injected by the platform into each request sent to a shared MCP server. In practice, it preserves user-specific context while avoiding the cost and operational burden of spinning up a separate server instance for every person.
In NHI and agentic AI deployments, the term usually refers to an application-level context carrier, not an authentication mechanism. That distinction matters: the header may identify a tenant, user, or session context, but it does not by itself prove identity, enforce authorization, or establish trust. Definitions vary across vendors, especially when MCP gateways, reverse proxies, and AI orchestration layers all participate in request handling. A safe implementation treats the value as untrusted input unless it is bound to a verified identity assertion and checked against policy at the server boundary. For adjacent guidance on identity control and lifecycle rigor, see the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0.
The most common misapplication is treating the header as a trust signal, which occurs when downstream services accept it without validation or binding to the authenticated caller.
Examples and Use Cases
Implementing user defined headers rigorously often introduces routing and validation overhead, requiring organisations to weigh shared-server efficiency against stronger request isolation.
- A shared MCP server receives a tenant-scoped header so it can apply the correct workspace policies without cloning the service for every user.
- An AI agent platform forwards a user context header to an MCP tool server so audit logs can attribute tool calls to the initiating user.
- A gateway normalises a per-user header before proxying requests, reducing custom logic inside the server while preserving request context.
- A multi-user automation service uses the header to separate cached results by user, preventing accidental cross-user data exposure.
- During governance review, teams compare header propagation rules with the NIST Cybersecurity Framework 2.0 and the Ultimate Guide to NHIs to confirm that context values are not mistaken for credentials.
Where the industry has not reached consensus is on whether the header should carry only opaque context or also signed identity claims; the safer pattern is to keep those concerns separate unless a control framework explicitly requires otherwise.
Why It Matters in NHI Security
User defined headers become security-relevant when shared infrastructure processes requests on behalf of many users or autonomous agents. If the value is spoofed, reused, or logged without controls, one caller can inherit another caller’s context, which undermines least privilege, audit fidelity, and incident response. In NHI programs, that risk is amplified because service accounts, tool servers, and agent workloads already operate with broad privileges, and context confusion can turn an ordinary request into an unauthorized action path. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which makes context isolation and request binding especially important when multiple users share a backend. Aligning the design with the NIST Cybersecurity Framework 2.0 helps teams map the header to access control, logging, and monitoring requirements rather than treating it as harmless metadata.
Organisations typically encounter the consequences only after a cross-user data exposure or privilege misuse incident, at which point user defined header handling 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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | User-defined headers must not be treated as trusted identity or auth signals. |
| OWASP Agentic AI Top 10 | A-03 | Agentic workflows often pass user context into tools through shared request metadata. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access enforcement apply when shared servers act on per-user context. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires explicit verification instead of trusting request metadata. |
| NIST AI RMF | AI risk governance covers context integrity, logging, and misuse pathways in shared services. |
Map header handling to access-control policy and verify authorization at the server boundary.
Related resources from NHI Mgmt Group
- How should security teams validate row level security controls in analytics platforms that allow user defined filters and subqueries?
- How should security teams validate requests in CI/CD and API workflows instead of trusting the User-Agent header?
- What is the difference between trusting a User-Agent header and verifying request provenance?
- When do service accounts become a higher risk than ordinary user accounts?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
