Do Cerebras Audit Logs record every inference request?

Cerebras documents Request Logs as the surface for individual API calls. The separate Audit Logs tab covers console actions such as adding members, managing billing, and changing organization settings. Use Request IDs and request filters for inference investigations. Use Audit Log payloads for administrative change history.

Can an API credential identify the employee behind a request?

A Cerebras API credential authenticates the credential and belongs to one project on paid accounts. A shared application credential identifies that workload to Cerebras. The application must preserve the employee or agent identity that initiated each call and bind it to the provider Request ID through a correlation record.

What should a SIEM ingest from Cerebras?

Start with the Request Logs CSV needed for the investigation and the relevant console Audit Log payloads available to admins. Preserve UTC timestamps, Request IDs, project context, filters, and export custody. Add application identity and routed policy decisions as separate sources. Define retention and collection frequency against the console capabilities and your own evidence requirements.

Does archiving a project remove its history?

Cerebras states that archiving a project preserves usage logs for auditing. It also invalidates all API credentials in that project and revokes member access. Record the archive event and the replacement project or credential when a workload moves, since request attribution will cross that administrative boundary.

Where does DeepInspect fit with Cerebras logs?

DeepInspect applies only to authenticated HTTP model calls that the customer deliberately routes through its proxy. Cerebras Request Logs and console Audit Logs remain provider telemetry. Application authentication, project administration, secret rotation, and direct calls that bypass the proxy retain their existing owners.

Cerebras Inference Audit Logs Separate Requests From Console Actions

Cerebras Inference Cloud puts two records under its Logs page. Request Logs describe API calls. Audit Logs describe actions inside the Cloud Console. That split gives operations teams useful evidence, provided the control design keeps provider telemetry separate from the authenticated person or agent behind a model request.

TL;DR

Cerebras Request Logs can be filtered by model, API credential, date range, or HTTP status code, and the current view can be exported as CSV.
Console Audit Logs cover organization settings as well as member and billing changes. Only admins can view them.
Projects bind credentials, members, quotas, and usage analytics to a workload boundary, but a project credential still identifies a credential rather than the application user behind each call.
A complete request record needs caller identity and policy context captured on a deliberately routed authenticated HTTP model call.

Cerebras exposes two different log surfaces

The Cerebras Usage and Monitoring documentation separates the Logs page into Request Logs and Audit Logs. Request Logs support filters for model, API credential, date range, and HTTP status code. A status chart shows errors over time. Each failed-call investigation can use a Request ID, and the filtered view can be downloaded as CSV.

Audit Logs answer an account-administration question. Cerebras lists organization-setting changes alongside member additions and billing management as examples. Admin users can open payload details for an entry, while other roles lack access to this tab.

I would reject any control description that calls both tabs one audit trail. An exported Request Logs row and a console payload can refer to the same project while proving different events. The first records provider-facing traffic. The second records administrative activity. Keeping those records separate makes an incident timeline clearer.

Request Logs support provider-side investigation

Start an investigation with the Request ID. Support can use it to locate a failed call, while the model, credential, status, and UTC timestamp narrow the affected workload. A CSV export also gives a security team a stable artifact to correlate with application logs and gateway records. The useful visual is a single row showing the Request ID beside a 401 or 429, with the project and deployment record open in adjacent panes.

The documented filters can isolate calls made with one API credential or sent to one model during a bounded period. They also expose error patterns through HTTP status codes.

The published Request Logs contract lists model, API credential, date, HTTP status, and Request ID. Authenticated human or agent identity remains a separate evidence requirement. Policy evidence must also preserve its version and decision details, including prompt classification and authorization outcome. The same distinction appears in the Mistral audit logs analysis, where credential history and inference evidence serve different reviews.

Console Audit Logs establish administrative change history

Cerebras Audit Logs cover actions taken in the console. A member addition can explain who gained access to a project. A settings change can identify when an organization configuration moved. Billing actions establish a separate administrative timeline. Payload details give the reviewer more context for each event, and admin-only visibility limits who can inspect that history.

Use this stream to test change management. Pull entries for member assignments and organization-setting changes during the incident window. Include an API credential action when present. Preserve the UTC timestamp and payload with the reviewer who exported it. Then compare those events with the relevant Request IDs.

This stream should retain its own control owner. Cloud administrators govern membership and settings. Application and security teams own the identity binding and policy applied to a model request. Mixing those owners in one evidence statement makes a console change look like proof that a specific user was authorized to send specific data.

Projects improve workload attribution

Cerebras Projects group API credentials, members, rate limits, usage, and analytics within an organization. Every API credential belongs to exactly one project. Credentials in that project share its rate limits, and switching console context filters pages such as API Keys, Limits, Analytics, Members, Audit Logs, and Settings.

That structure supports a clean workload map. A production service can use a project distinct from testing, with separate members and a separate credential. The request record can then point to a narrower administrative boundary than the whole organization. Project archives also preserve usage logs for auditing while invalidating the project's credentials and revoking member access.

A project narrows the administrative boundary, while the calling application still has to carry the authenticated principal behind each model request if a reviewer needs person-level or agent-level accountability. One production credential shared by three services collapses those services into one provider identity. Create narrower projects or credentials where operational attribution requires them, then preserve the application identity separately.

API credentials authenticate the workload to Cerebras

The Cerebras API credential guide describes credentials as static secrets sent with every request. Paid accounts create credentials inside a selected project, which attaches project rate limits and usage tracking. These credentials have no automatic expiry. Rotation requires creating a replacement and updating the application before deleting the old credential. Deletion immediately causes applications using the retired credential to receive 401 Unauthorized responses.

At the HTTP boundary, the Cerebras authentication guide places the credential in the Authorization: Bearer header on a request to the model API. That authenticates the credential Cerebras issued. It gives the provider a project-linked unit for metering and request investigation under the project's limits.

Preserve the user or agent principal and role before the outbound call. Bind that context to the provider Request ID and the project credential reference without copying the secret into logs. Credential rotation evidence belongs beside this map because a deleted credential and its replacement create two provider identities for one continuing workload.

An evidence map assigns each question to one record

Build the review around questions rather than a generic requirement to retain logs:

Which provider request failed? Use the Cerebras Request ID, UTC timestamp, model, project-linked API credential reference, and HTTP status.
Which console action changed access or settings? Use the admin-only Audit Log entry and its payload details.
Which workload owned the credential and quota? Use the project membership and limits configuration, including the credential assignment.
Which person or agent initiated the model call? Use the application's authenticated identity record and correlation identifier.
Which policy governed the prompt? Use the routed policy version and decision details, including content classification and outcome.
Which evidence left the provider console? Preserve the CSV export, export time, filters, reviewer, and protected storage destination.

A useful acceptance test creates one permitted request and one denied request through the production path. Retrieve both application correlation IDs, then locate the provider entries by time and Request ID. Change a project setting through an approved admin account and retrieve that separate Audit Log payload. The final packet should show two model-call records and one console-action record rather than presenting three events as interchangeable.

The AI gateway observability guide explains why engineering telemetry and audit evidence need distinct consumers and retention rules. For integrity requirements, signed audit logs for AI requests covers the write path and verification contract.

DeepInspect

DeepInspect sits on the deliberately routed HTTP path between an authenticated user or agent and the Cerebras model endpoint. The calling application supplies verified identity context. DeepInspect evaluates that context with the request content and active policy before forwarding an allowed call under the Cerebras credential.

Each routed decision can retain the principal, role, content classification, destination model, policy version, and outcome beside a correlation identifier. The Cerebras Request ID then links provider telemetry to that independent request-path record. Console administration and credential lifecycle stay with Cerebras and the customer's cloud administrators. Direct provider calls remain outside DeepInspect's visibility, so network and credential controls must enforce the approved route.

Book a technical deep dive at deepinspect.ai.