An auxData JWT set is a request field that carries multiple named JSON Web Tokens alongside a policy decision request. Each token keeps its own keyset and claims, so the engine can verify identities separately. This is useful when a request involves more than one trust boundary, such as a gateway identity and an end user identity.
Expanded Definition
AuxData JWT Set refers to a policy decision request pattern where multiple JSON Web Tokens are submitted together as auxiliary identity inputs, rather than forcing one token to represent every actor, hop, or trust boundary. In NHI and agentic AI environments, this distinction matters when a gateway, workload, and end user each contribute a separate identity signal that must be evaluated independently.
Each JWT in the set should be verified against its own issuer, audience, expiry, and key material. That separation aligns with the JWT model defined in RFC 7519, but the exact auxData pattern itself is implementation-specific and usage in the industry is still evolving. In practice, teams use it to preserve trust boundaries instead of collapsing them into one overloaded bearer token. This is especially relevant in decision engines that must combine machine identity, delegated user context, and policy metadata without assuming those claims share the same assurance level.
The most common misapplication is treating the auxData set as a single composite identity, which occurs when teams skip per-token validation and let one valid JWT implicitly authenticate all attached claims.
Examples and Use Cases
Implementing AuxData JWT Set rigorously often introduces integration complexity, because every token adds validation, logging, and lifecycle handling overhead that must be balanced against stronger separation of duties.
- A service gateway sends its own workload JWT while attaching a user-delegation JWT so the policy engine can distinguish transport authority from end-user intent.
- An AI agent submits one token for the agent runtime and a second token for the human approver, allowing the decision point to evaluate both identities before releasing a high-risk action.
- A cross-domain API request includes one JWT from an internal identity provider and another from a partner federation, reducing the risk of over-trusting a single upstream assertion.
- An access broker forwards a device-attestation JWT alongside an application token so the engine can consider device trust without merging it into the application principal.
For broader NHI context, the Ultimate Guide to NHIs — Key Research and Survey Results explains why layered identity visibility is necessary across service accounts and delegated credentials. The same separation principle appears in RFC 7519, where claim integrity depends on the issuer and signing context of each JWT, not on surrounding application logic.
Why It Matters in NHI Security
AuxData JWT Set matters because NHI failures often come from overbroad trust, not simply from missing authentication. If a policy engine cannot distinguish between gateway identity, workload identity, and user identity, it may authorize actions using the strongest token in the set while ignoring the weakest boundary. That creates hidden privilege inflation, weak auditability, and unclear accountability when an autonomous system acts on behalf of multiple principals.
This becomes especially important in environments where secrets, tokens, and service accounts are already difficult to govern. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, which means identity inputs are often poorly tracked before they ever reach policy enforcement. A multi-token request model can improve precision, but only if each JWT is validated, logged, and bound to a clear trust purpose. That requirement also fits the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, where authentication, provenance, and least privilege must be enforced at the system boundary.
Organisations typically encounter the risk only after a policy bypass or privilege abuse incident, at which point AuxData JWT Set 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 SP 800-63, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers identity trust boundaries and validation weaknesses in NHI request flows. |
| OWASP Agentic AI Top 10 | AIC-03 | Agentic systems often carry multiple identity assertions in one action request. |
| NIST SP 800-63 | IAL2 | Identity assurance depends on how each assertion is issued and bound to a subject. |
| NIST Zero Trust (SP 800-207) | ID | Zero Trust requires per-request evaluation of identity and context, not token aggregation. |
| NIST CSF 2.0 | PR.AC-1 | Access control requires identity proofing and authorization aligned to each request source. |
Validate each JWT independently and map every attached identity to its own trust boundary.
