Who Did That? Why Every AI Event Needs a User Attached

When an auditor, a regulator, or your own incident-response team asks "which user caused this LLM call?", most AI stacks have no answer. The call went out with a shared API key; the logs, if any, say the application did it. That answer fails audits that traditional software passed decades ago — and it fails them at exactly the moment AI usage is exploding: Gartner expects more than 80% of enterprises to have generative-AI applications in production by 2026.

The requirement is not new; it is the oldest control in the book, applied to a new surface:

• HIPAA — the Security Rule's very first technical safeguard is unique user identification (45 CFR §164.312(a)(2)(i)), followed by audit controls (§164.312(b)): record and examine activity in systems holding ePHI. If an agent can read a patient record, "the chatbot did it" is not an acceptable log line.
• Defense & government — NIST SP 800-171 requires that audit logs make actions "traceable to individual users" so they can be held accountable — a control every CMMC assessment checks. FedRAMP's AU control family asks the same of cloud services.
• EU — the EU AI Act requires lifetime event logging for high-risk systems (Article 12) and requires deployers to retain those logs; GDPR's accountability and records-of-processing duties (Art. 5(2), Art. 30) assume you can say who processed what. Financial entities get the same demand from DORA.

One line at the entry point

InferenceFort attaches identity where the request enters, and every governed event downstream inherits it automatically:

import inferencefort
inferencefort.set_context(
    user="alice@acme.com",      # the human (or service) accountable
    agent_id="support-bot",     # which agent acted
    thread_id="conv_8842",      # which conversation
)

Identity rides in async-safe context (contextvars in Python, AsyncLocalStorage in Node), so a server handling a thousand concurrent users never cross-attributes: each request's calls carry that request's user, even through parallel agent branches. There is deliberately no process-global fallback that concurrent users could collapse into.

What lands on every event

Each LLM call and each tool call becomes an audit event carrying: the user, the agent and executing graph node, the end-customer (for multi-tenant platforms), the model, the resolved destination endpoint (the compliance receipt that the call went where policy says it may go — the control GDPR data-transfer rules care about), the decision with its reason, token usage and cost, and the trace linkage that stitches a multi-step, multi-agent run into one causal chain.

That combination turns four painful questions into queries:

• Incident response — "show every event where PHI was detected, by user, in the last 30 days" is a filter, not a forensics project.
• Cost accountability — spend per user, per agent, per customer, from the same attributed events that drive enforcement.
• Access review — a deactivated user's calls are blocked by the identity gate, and the attempt itself is an attributed audit event.
• Regulator evidence — export the event stream and you have the Article 12 / §164.312(b) record, not a reconstruction.

No anonymous calls

Attribution only works if it cannot be skipped. InferenceFort's identity gate can require a user on every call — a request with no set_context identity is refused before the prompt leaves the process, with a clear developer-facing reason. The strictness is configurable, but the default posture for regulated deployments is simple: if we can't say who, it doesn't run. The IBM Cost of a Data Breach report keeps finding that breaches involving ungoverned, unattributed AI usage cost more and take longer to contain — attribution is the difference between an audit trail and an archaeology dig.

For how attribution composes with the rest of the audit story — retention, tamper-evidence, per-customer isolation — see Building Complete Audit Trails for AI Agents.