Identity context
Identity context is the bundle of verified subject attributes that travels with each AI request and informs the policy decision. The bundle includes the subject identifier (the user principal, the workload identifier, or the agent identity), the verification method (OIDC token, mutual-TLS certificate, signed workload assertion), the directory roles the subject holds at request time, and the request attributes that depend on identity (the calling application, the originating tenant, the delegated scope). EU AI Act Article 12 requires identification of the natural persons involved in the decision; identity context is the data structure that makes the requirement satisfiable per request.
How identity context is established before the policy decision
The gateway terminates the inbound connection, verifies the identity assertion against the identity provider's trust anchor, and resolves the subject to the directory record. The resolution step pulls the role memberships, the tenant attribution, and any custom attributes the policy needs (clearance level, BAA-coverage flag, geographic restriction). The resolved bundle is the identity context the policy decision point reads. The bundle is short-lived; it carries the verification timestamp and an explicit expiry, which keeps a long-running session from running on a stale identity claim past the directory's revocation moment.
Why identity context travels into the audit record
A per-decision audit record without identity context fails Article 12's identification clause and Fannie Mae LL-2026-04's per-decision evidence requirement. The audit writer takes the same identity context the policy decision point used, hashes it (or stores it directly when retention rules permit), and binds the hash to the audit entry. The regulator's question "who issued this request and how was the identity verified?" gets answered from the audit record itself, not from a reconstruction across access logs the application no lon
Related reading
- Identity-Aware AI Gateway Architecture: How Inline Enforcement Binds Decisions to Users and Agents
An identity-aware AI gateway sits at the AI request boundary, attaches verified identity context to every model API call, evaluates per-route and per-role policies, and commits a per-decision audit record before the model response returns to the calling application. The architecture closes the post-authentication gap that most enterprise AI deployments have inherited from the credential-pooling pattern used by SDKs and proxy frameworks. This piece walks through the architectural building blocks, the call path, the audit primitives, and where the identity-aware gateway sits relative to existing IAM, API gateway, and DLP infrastructure.
- AI Agent Authorization: NIST Pillar 2 at the Request Boundary
AI agent authorization is the per-request decision about whether a specific caller, against a specific resource, under a specific policy, is allowed to act. NIST calls it delegated authority. Most enterprise AI deployments solve authentication and skip authorization.
- Tamper-Evident Audit Logs for AI: What Cryptographic Integrity Brings to Compliance Records
Tamper-evident audit logs make any post-hoc modification of a record detectable through cryptographic integrity. For AI compliance records, the property closes the self-attestation gap that application-controlled logs cannot. The technique combines per-record signing, hash chaining, and external anchoring. EU AI Act Article 12, Fannie Mae LL-2026-04, HIPAA, DORA, and NIST AI RMF all expect records that an auditor can rely on as evidence. Application logs that the application can modify do not meet that standard. This piece walks through the cryptographic mechanisms, the operational characteristics, and the architectural placement.