Your AI Gateway Can Name the User. Decide What That Log Is For
By Greg Nowak. Last updated 2026-08-31.
Adding a verified identity to an AI Gateway log makes the data far more useful. A sudden increase in spend can be traced to an account. A risky prompt is no longer an anonymous event. The business can compare the activity with that account's usual behaviour and decide whether someone needs to investigate, limit access or block the request.
There is a catch. A gateway that records identities, prompts, responses and costs can quickly become a searchable store of sensitive operational data. Before collecting more, the organisation needs to be clear about what the logs are for, who can inspect them and when they should be deleted.
What identity adds to the gateway
Cloudflare's identity-aware AI Gateway with Access entered open beta in August 2026, while User Insights became generally available. Access can put an AI Gateway custom domain behind identity-provider authentication and attach the verified Access subject to each request as cf.user_id. This value is the subject from the JWT, not the person's email address.
Administrators can use it to filter logs, analytics and spend by authenticated user. User Insights also establishes behavioural baselines for people and agents, then highlights sessions that differ from an account's own history. That distinction matters. A scheduled service and a frequent human user may both generate heavy traffic without sharing anything like the same normal pattern.
An anomaly is still only a reason to look closer. Cloudflare says User Insights neither determines intent nor blocks an account. Unusual activity could point to compromised credentials, a faulty agent, an inefficient workflow or perfectly legitimate work. The alert narrows the search; an agreed investigation process determines what happens next.
People are only part of the identity model
The cf.user_id field has a clear boundary. It is added when a request reaches an Access-protected custom domain with a valid user subject. Requests authenticated with service tokens do not carry the field because they do not represent an individual Access user.
Reports therefore need to distinguish between people and automation. Human activity can be attributed to a verified Access subject. Services, agents and integrations need separate, stable identifiers, documented owners and a credential lifecycle. Treating every actor as a generic user may make a dashboard look tidy, but it leaves automated activity poorly accounted for.
The route matters as much as the identity. Requests to an Access-protected custom domain must satisfy its Access policy, so existing integrations may need updating. Traffic sent to Cloudflare's default gateway endpoint is outside that Access configuration. A route map showing which applications must use which endpoint is part of the control itself.
Start with the decision, not the data
Gateway logs can support cost allocation, security investigations, acceptable-use enforcement, troubleshooting and service improvement. Each purpose calls for a different mix of fields, content access and retention.
Cost management, for example, may need the identity, model, token usage and application metadata without giving teams routine access to full prompts. A content-safety review may need the relevant prompt and response, but only for flagged interactions. An incident investigation may require a broader timeline spanning identity, application, network and tool activity.
The Cloud Security Alliance makes the same practical point at a wider level. Network traffic, API calls and system events should be viewed alongside agent-level evidence such as decision chains, tool invocations and outputs. Gateway identity alone cannot explain everything an AI system did. Network telemetry may confirm that an API call happened while revealing little about whether it came from an employee, an agent or a compromised account.
| Question to settle | Operational decision | What should exist |
|---|---|---|
| Who made the request? | Separate verified people from services and agents. | Access subjects for people; owned identifiers and credentials for automation. |
| Why keep the event? | Name the cost, security, support or compliance decision it supports. | A documented purpose and the minimum fields required for it. |
| Who can read the content? | Limit prompt and response access to defined roles and cases. | An access procedure, review trail and escalation criteria. |
| What follows a signal? | Choose whether to observe, review, block or use a cheaper model. | A guardrail action, spend rule, alert owner and response playbook. |
| How long is it useful? | Set retention for each purpose instead of keeping everything indefinitely. | A retention schedule, exception process and deletion check. |
| What happens when access ends? | Remove human access and rotate or retire automation credentials. | An offboarding checklist tied to identity and service ownership. |
Match the control to the consequence
The 2026 Netskope report shows how patchy AI visibility remains. Only 6% of surveyed organisations reported complete visibility into AI use; 94% described some degree of gap. Many teams also could not reliably tell personal AI accounts from corporate ones. This is an argument for clearer routes, account distinctions and activity monitoring, not for storing every prompt by default.
Once routes and identities are defined, Cloudflare offers several places to intervene. Guardrails can inspect prompts and model responses across providers. Depending on the configuration, they can flag content for review or block it before the workflow continues. The right action depends on the application. A false positive in an internal writing tool is inconvenient; the same mistake in a customer-facing service can interrupt a live transaction.
Spend limits provide a separate financial control. They can be scoped by model, provider or metadata, including cf.user_id for authenticated people. Reaching a limit normally causes requests to be rejected with a 429 response. A dynamic route can instead send the traffic to a cheaper fallback model.
Teams should set expectations around those limits. Cloudflare documents that enforcement is eventually consistent, so concurrent requests can briefly take spending beyond the threshold. Its cost tracking is also a best-effort estimate; the provider's bill remains authoritative. A limit is therefore a useful operating boundary, not an exact accounting ceiling.
Write the investigation procedure before alerts arrive
Every signal needs an owner. That person or team should know what context they may inspect, how to check whether the activity was expected and what action they are authorised to take. The procedure should also define when to open a security case, when to involve a manager or system owner, and which evidence must be preserved.
The first checks can be very concrete. Did the request use an approved route? Was the actor a person or a service? Did the model, timing, cost or content differ from that identity's normal activity? Was the prompt flagged, the response, or both? If the interaction triggered tools or changed another system, the investigation will also need evidence from that system.
Offboarding needs equal care. Removing an employee from Access addresses their human authentication, but it does not retire service tokens, embedded credentials or agents they once owned. Each non-human identity should have a named business owner, a technical owner and a documented action for the point when either relationship ends.
A workable order of implementation
Begin by inventorying the AI applications, gateway routes, providers, human groups, services and agents in use. Mark the workflows that may handle sensitive information and those able to change external systems. The Cloud Security Alliance recommends using more than one discovery mechanism because sanctioned applications show only part of the environment.
Then put approved human routes behind Access and confirm that attribution works. Give services their own identities instead of accepting a missing cf.user_id as an unavoidable blind spot. For each logging purpose, choose the minimum data needed, assign access roles and set a retention period.
Behavioural alerts, per-user budgets and guardrail actions come next. Test the awkward cases: a blocked request, a breached budget, a departing employee and an agent whose behaviour changes unexpectedly. Document the routes, controls and procedures so a new owner can understand how the system is supposed to work.
The gateway's ability to name a user is only the starting point. Useful governance comes from knowing why that identity was recorded, who is allowed to act on it, how long the evidence remains useful and what the organisation will do when the log shows something unusual.
Related on GrN.dk
- Cloudflare AI Gateway Brings LLM Budgets Into the Request Path
- Agentic AI: What It Is, How It Works, and When to Use It
- Cloudflare Service Keys: Audit Old Automation Before September 30
Need help with this kind of work?
Plan your governed AI gateway Get in touch with Greg.