Windsurf Audit Logs: Reading the Current Devin API Evidence

The old Windsurf documentation now resolves into Cognition's Devin documentation. Current enterprise audit retrieval is documented as GET /v3/enterprise/audit-logs in Devin API v3. Cognition still uses "Legacy Windsurf Enterprise" for a specific CLI authentication and billing path, so an investigator needs to verify which tenant and contract expose which evidence surface. I want to keep the terminology precise, then walk through authentication and time windows. I will also cover pagination and actor fields, followed by the record that remains separate at the routed AI request boundary.

TL;DR

• Current Cognition documentation places enterprise audit retrieval in Devin API v3, while "Legacy Windsurf Enterprise" remains a qualified legacy path.
• The v3 endpoint uses service-user authentication with enterprise-level ManageEnterpriseSettings permission.
• Time filters use Unix seconds in UTC, and a bounded export must account for cursor pagination plus the documented interval rules.
• Vendor events establish platform activity; a separate inline record proves which policy governed a routed AI HTTP request.

The first evidence check is product identity

Cognition's legacy Windsurf Enterprise authentication page describes how Devin CLI can use Windsurf Enterprise authentication and credits, with dashboard access under that legacy arrangement. The page gives the old name a narrow current meaning. It does not turn every current Devin endpoint into a Windsurf-specific API.

An evidence request should therefore begin with four identifiers: Cognition enterprise tenant and product surface; API version and authentication type. Preserve the contract label too. A security team migrating a legacy Windsurf Enterprise account may have records from Devin Desktop and Devin CLI, plus enterprise administration records with different access paths. Calling the combined set "Windsurf audit logs" can hide a missing source.

I would reject an audit package whose cover page lists only a brand name. Versioned endpoints and tenant identifiers belong beside the collection timestamp. That is the difference between repeatable evidence and a screenshot that becomes untraceable after the next documentation rename.

Devin API v3 defines the current collection path

The Devin API v3 enterprise audit operation requires a service user with enterprise-level ManageEnterpriseSettings permission. That detail separates collection authority from an ordinary user session. Create a dedicated collector identity and scope it to the documented permission. Protect its credential and record every use in the evidence runbook.

The endpoint accepts time_after and time_before as Unix timestamps in seconds interpreted in UTC. Supplying time_before also requires time_after, and the requested interval is capped at 100 days. The first parameter defaults to 100 records and accepts up to 200. Results use cursor pagination and support ascending or descending order plus action filtering.

Those mechanics produce concrete failure modes. A script can silently collect only the first page. Millisecond timestamps can be passed as seconds and create an empty interval. Local timezone conversion can shift an incident boundary. Store the exact request parameters and page cursors beside the exported JSON. Include the response count and UTC conversion, along with the retrieval time.

Actor fields and actions shape the investigation

The documented v3 response includes an audit-log ID and action; creation time and organization ID; user identity fields and service-user identity fields; and an open-ended data object. The schema can attribute an event to user or service-user context when those fields are populated. An investigator should preserve null values rather than replacing them with a guessed actor.

Cognition's action enumeration spans administrative and identity events. It also covers integrations and sessions; secrets and MCP; security profiles and automations; and AI guardrails. The page specifically says ai_guardrail_violation is recorded when a configured guardrail triggers. Action filtering can narrow a collection, though the first preservation pass should remain broad enough to retain surrounding account and configuration activity.

Picture two JSON objects pinned side by side: one names a human user, while the next contains only a service-user identifier and a flexible data object. The empty human field is evidence about attribution depth. It should drive correlation with SSO and endpoint records, plus session and repository records, rather than an invented identity.

API v2 and v3 authentication must stay separate

Cognition also maintains Devin API v2 audit-log documentation. The v2 path uses an enterprise-admin personal API key. Version 3 uses service-user authentication and RBAC. Mixing those instructions can leave an exporter broken or place a personal credential in a scheduled collection job.

Inventory every collector by endpoint version and credential owner; permission and storage destination; and rotation procedure. Test the expected denial case with a service user lacking ManageEnterpriseSettings. Then run a complete bounded collection across enough records to force more than one cursor page. Hash or sign the saved export under the organization's evidence procedure and retain the original response envelope.

The API gives post-event platform evidence. It records supported actions after they occur. Retention and availability for the tenant should be confirmed with Cognition because the public operation page defines the query interface and schema rather than a universal contractual retention promise.

Request-policy evidence is a different record

A vendor audit event can establish that an enterprise actor changed a setting or started a session. It can also show that the actor touched an integration or triggered a configured guardrail. It may still lack the policy decision made by an external gateway before one HTTP request reached an LLM. That second record needs the originating principal and any relay identity. It also needs the model route and prompt classification; policy version and outcome; timestamp and correlation ID.

The field set mirrors AI audit-log schema design. Vendor event and gateway decision should retain their separate record IDs. Correlation joins them during an investigation without pretending they describe the same control.

DeepInspect sees only routed AI HTTP traffic. SSO and SCIM changes remain outside that boundary, along with account provisioning and IDE settings. Local terminal activity and repository administration also remain outside it, as do proprietary Devin session events. The vendor API is the right source for supported Cognition platform events. A request gateway contributes evidence only for the HTTP calls deliberately sent through it.

A collection drill exposes evidence gaps

Choose a non-production tenant and create one approved administrative event plus one service-user event. Add one configured guardrail test. Record UTC start and end times. Retrieve the interval through v3, force cursor pagination with a small first value, and repeat the export in both sort orders. Confirm IDs remain stable and the total set matches.

Next, run one customer-controlled model request through the organization's gateway using a synthetic marker such as AUDIT-2026-09-08-041. Collect the vendor events and the gateway decision. The signed audit record pattern should preserve the latter independently. Put API request parameters and cursors in one case folder. Add the raw responses and hashes, followed by the policy record and timezone conversion.

The drill should end with a gap statement. Name every event that stayed inside Devin or Devin Desktop and every routed HTTP request that crossed the external gateway. This boundary statement is more useful than claiming one log source covered the whole agent session.

DeepInspect

This is the gap DeepInspect closes for deliberately routed AI HTTP calls. DeepInspect evaluates application-supplied identity and role, plus prompt classification and destination. It also evaluates versioned policy before forwarding permitted traffic to an LLM endpoint. It creates a signed, tamper-evident decision record for each request it inspects.

Cognition's audit API remains the source for enterprise and identity events; integration and session events; secret and MCP events; security-profile and automation events; and guardrail events. DeepInspect adds the independent allow or block record, including redact when applicable, on the routed request path, with a correlation value that an investigator can join to vendor and application evidence. Book a technical deep dive at deepinspect.ai.