A full audit trail of every LLM request
Every call through NetBird is tied to the caller, group, model, and policy that allowed it, making it easy to trace who accessed what and when.
What every log entry captures
Access already runs through NetBird, so the record is a byproduct of the request instead of something you wire up separately.
Every request, attributed
Each log entry identifies the caller and authorizing IdP group, instead of giving the whole team one anonymous identity through a shared API key.
Outcomes with reasons
Allowed calls and denials appear in the same log, with clear reasons that distinguish policy blocks from exhausted budgets.
Request-level detail
Logs capture the provider, the exact model ID, input and output tokens, cost, latency, and HTTP status.
Seamless SIEM integrations
Stream events to Datadog, S3, Data Firehose, or your any SCIM platform via HTTP.
How it works
Connect your identity provider
NetBird syncs users and groups from Okta, Entra ID, Google Workspace, JumpCloud, or any SCIM provider. Those identity groups are recorded with each request, so calls can be attributed to the right teams and individuals without maintaining a separate list of key owners.
Put your providers behind NetBird
When connected to NetBird, register each provider with its upstream URL and key. NetBird stores the key, so users and agents access the provider through your endpoint without holding credentials themselves.
Every call is logged with its outcome
Every request is checked against your policies and logged with its outcome. Each entry includes the method and path, a shared session ID for related calls, and the provider’s response.
Investigate in place, or ship it out
Filter by user, agent, model, or prompt text, and switch between single requests and whole sessions when you need the shape of a run. For anything longer-lived, stream events to Datadog, Amazon S3, Data Firehose, or your own HTTP endpoint.
Give security a full, attributable record of every AI request.
Get Started FreeFrequently asked questions
What does NetBird's audit log capture for AI requests?
Each entry records the caller (a user's email or an agent's name), their IdP group, the provider and exact model ID, input and output tokens, cost, latency, HTTP status, and the policy that matched. Opening an entry also shows the request method and path, a session ID, and the completion the provider returned.
Is every AI request logged, or only denied ones?
Every request. Traffic reaches a provider through NetBird, so allowed and denied calls are written to the same log. There is no separate logging step to switch on.
Are prompts and completions stored?
Log entries can include the completion returned by the provider, and search covers prompt text. That is useful during an investigation, but it also means the log itself holds sensitive content, so scope access to it the same way you would any system carrying customer or employee data.
Can I export the audit log to my SIEM?
Yes. Event streaming sends audit and traffic events to Datadog, Amazon S3, Amazon Data Firehose, or a custom HTTP endpoint, so the records land wherever you already run detections and dashboards.
How long is audit log data retained?
Retention is configurable rather than a fixed default. Teams with multi-year obligations usually stream events into storage they control, such as an S3 bucket, and let that bucket's lifecycle policy govern how long the data lives.
Can I tell which region served a request?
The log stores the provider and the model ID exactly as they were called. When the provider puts the region in the model ID, as Amazon Bedrock does with identifiers like eu.anthropic.claude-opus-5, the region is visible per request. Providers that take the region outside the model ID, such as Vertex AI, won't show it in that field, so scope those by the endpoint each policy is allowed to reach.
Does audit logging require a gateway like LiteLLM?
No. Logging sits on the NetBird policy layer, so it behaves the same whether calls go straight to a provider or through a gateway you already run in front of them.
How is this different from cost attribution?
Both read the same log. Cost reporting leans on the token and dollar columns grouped by team. A security review leans on the decision, status, and reason columns for a single caller or session.