Audit Logs - Resolve AI

Audit Logs is a security feature in Resolve AI that provides a complete, auditable record of activity across the Resolve platform and its execution environment. Audit logs are designed to support security monitoring, compliance and governance, and operational troubleshooting by making it easy to answer questions like:

Who did what, and when?
Which external systems were accessed, and did those calls succeed?
What integration APIs did Resolve use?

Resolve AI produces two kinds of audit logs:

User Access Logs: capture authentication, authorization and user API access requests. These are available through a stream exposed via the Audit Logs API.
Integration Access Logs: capture each API request made to configured integrations on the Resolve Satellite during both autonomous execution and human-in-the-loop investigations and actions.

User Access Logs

User Access Logs capture user activities within the Resolve AI platform. They form part of the unified audit stream and represent the authoritative record of who accessed Resolve and what actions they took. These logs include:

User authentication and logout events
Authorization, role, and group changes
API requests made to Resolve AI
Team configuration changes

User Access Logs are available via the Audit Logs API and are intended primarily for security monitoring and compliance review.

Accessing the User Access Logs using Audit Logs API

Endpoint

GET /audit_logs/:orgId

Base URL: https://api.app0.resolve.ai/audit_logs/:orgId

Authentication To use the Audit Logs API, you must first create an API Token from the Resolve AI web application. This token is used to authenticate your requests.

Navigate to API Tokens in the sidebar: https://app0.resolve.ai/admin/api-tokens.
Click Create API Token.
Provide a name for your token.
Copy and store the token securely - this is the only time you will see it.
Click “I copied the token!” to save and exit.

You must include the token in the Authorization header of your API requests as a Bearer token.

Authorization: Bearer <your_token_here>

Path Parameters orgId (string, required): Your organization’s unique identifier.

Query Parameters

Name	Type	Required	Description
start	string	Optional	ISO8601 date string for start time (e.g., 2025-07-01T00:00:00Z)
end	string	Optional	ISO8601 date string for end time (e.g., 2025-07-07T23:59:59Z)
limit	string	Optional	Max limit 1000

Time Range Rules:

If both start and end are omitted: Defaults to the last 24 hours.
If only start is provided: end defaults to start +1 day.
If only end is provided: start defaults to end -1 day.
Maximum allowed range: 7 days.
start must be before end.

If the request violates these rules, you will receive a 400 Bad Request with an error message.

Error Responses

Status Code	Reason
`400`	Invalid or missing time range, malformed dates, or range exceeds 7 days
`401`	Missing or invalid Bearer token
`404`	Organization not found
`500`	Internal server error or downstream failure

Pagination The Audit Logs API supports pagination based on log timestamps. By default, the API returns up to 1000 records per request. If there are more logs available within the requested time range, an end_before token will be included in the response. You can use this token in a subsequent request to fetch the next page of results.

Default page size: 1000 logs.
Custom limit: You can pass a limit query parameter to request fewer logs (must be between 1 and 1000).
Pagination token: If the result set is exactly equal to the page size, the response will include an end_before timestamp (ISO 8601 string). This represents the timestamp of the last log in the current response minus 1 millisecond.
To fetch the next page, re-issue the request with end=<end_before_value> to get logs before that point in time.

Example Request:

GET /audit_logs/ORG_ABC123?start=2025-07-01T00:00:00Z&end=2025-07-07T00:00:00Z&limit=500

Example Paginated Response:

{
  "logs": [
    { "organization_id": "ORG_ABC123", ... },
    ...
  ],
  "end_before": "2025-07-06T23:59:59.999Z"
}

You can then request the next page:

GET /audit_logs/ORG_ABC123?start=2025-07-01T00:00:00Z&end=2025-07-06T23:59:59.999Z&limit=500

Note: Pagination is based on descending timestamps (newest to oldest). The end parameter is treated as an exclusive upper bound.

Event Schemas Each log entry conforms to one of the following OCSF classes:

Authentication
Authorization
API Activity

These schemas ensure consistent field naming and make downstream analysis easier.

Integration Access Logs

Integration Access Logs capture outbound API requests made by the Resolve Satellite during investigations and actions, including both autonomous execution and human-in-the-loop workflows. This includes calls to monitoring tools, cloud providers, and custom integrations. These logs capture execution-level details such as:

Integration and endpoint accessed
HTTP method and status code
Request and response sizes
Success or failure outcome
Sanitized request and response metadata

Integration Access Logs can be accessed directly from the Resolve Satellite via stdout/stderr or OTLP for real-time, in-environment operational monitoring of integrations executed by the Satellite.

Note: Audit logs never capture authentication secrets or tokens used in request headers.

Accessing the Integration Access Logs from the Resolve Satellite

Use Satellite audit logs when you need to monitor or troubleshoot integration HTTP activity, including failures, request volume, and payload sizes.

Collection Behavior

Logs are emitted as structured JSON
Each Satellite audit log includes audit: true for easy filtering
Logs include standard metadata fields (timestamp, level, message)
Satellite logs can optionally be exported via OTLP for direct ingestion into observability backends

Notable Fields

integrationKey: Integration name (e.g., prometheus, grafana)
method: HTTP method
baseUrl: Request URL without query parameters
statusCode: HTTP status code
result: success or error
requestBodyBytes, responseBodyBytes: Payload sizes

Filtering Examples You can filter Satellite audit logs using the audit: true field. The following are illustrative examples of how you can query audit logs emitted by the Resolve Satellite.

Loki / LogQL
Splunk
Datadog

{job="satellite-telemetry"} | json | audit="true"

index=satellite-index audit=true

audit:true source:satellite-telemetry

Frequently Asked Questions (FAQs)

1. How do I set up OTLP export for Integration Access Logs on the Resolve Satellite?

You can configure the Resolve Satellite to export Integration Access Logs using the OpenTelemetry Protocol (OTLP). This allows you to forward audit logs directly to an observability backend instead of relying on container log collection.RequirementsTo enable OTLP export, both of the following must be set:

An OTLP logging flag (OTLP_LOGGING or OTLP_AND_CONSOLE_LOGGING)
A receiver URL (OTLP_LOGS_RECEIVER_URL)

If either value is missing, OTLP export will not work.ConfigurationEnable OTLP export only:

env:
  - name: OTLP_LOGGING
    value: "true"
  - name: OTLP_LOGS_RECEIVER_URL
    value: "https://your-otlp-endpoint.com"

Enable dual logging (OTLP + stdout/stderr):

env:
  - name: OTLP_AND_CONSOLE_LOGGING
    value: "true"
  - name: OTLP_LOGS_RECEIVER_URL
    value: "https://your-otlp-endpoint.com"

OTLP Endpoint Details

Logs endpoint: {OTLP_LOGS_RECEIVER_URL}/v1/logs
Protocol: OTLP HTTP/JSON
Fallback behavior: — If OTLP_LOGS_RECEIVER_URL is not set, the Satellite falls back to OTLP_RECEIVER_URL — If neither is set, OTLP export is disabled

2. How long are audit logs retained in Resolve AI?

User access logs available via the Audit Logs API are retained for 30 days. Integration access logs are only available directly from the Resolve Satellite via stdout/stderr or OTLP for operational monitoring. For long-term retention, export audit logs to your own logging or SIEM system for storage and analysis.

3. What timestamp format should I expect?

All timestamps are returned in ISO 8601 UTC format.

4. Does the Audit Log API support token rotation?

Yes. API tokens are created and managed through the Resolve UI.

Tokens can be revoked at any time by an admin
New tokens can be created through the UI
Token rotation policies can be implemented according to your organization’s security requirements

5. What is the event schema I should expect for the audit logs?

The Audit Log API output follows the Open Cybersecurity Schema Framework (OCSF) version 1.5.0. Each log entry is structured in accordance with one of the following schema classes.(i) Authentication Logs Class: OCSF AuthenticationDescription: Captures user login and logout events, including success/failure status, protocol used, and device/network metadata.Common Fields:

organization_id: Organization where the event originated
activity_id: Type of authentication action (e.g., logon, logoff)
auth_protocol_id: Auth protocol used (e.g., SAML, OAuth2)
category_uid, class_uid, type_uid: OCSF taxonomy identifiers
status_id: Outcome (success, failure)
user: { name, email }
time: ISO 8601 timestamp of event
service.name: e.g., “Resolve Web App”
http_request: { user_agent, url }
metadata: { product, version }
src_endpoint: { ip, type_id } — Source IP and endpoint type
dst_endpoint: { hostname } — Target host accessed
is_remote: Whether the session was remote

Sample Authentication Log

{
  "organization_id": "ORG_ABC123",
  "activity_id": 1,
  "auth_protocol_id": 3,
  "category_uid": 6,
  "class_uid": 6001,
  "type_uid": 600101,
  "status_id": 1,
  "is_remote": true,
  "time": "2025-07-09T14:22:30.135Z",
  "user": {
    "name": "Alex Morgan",
    "email": "alex@company.com"
  },
  "service": {
    "name": "Resolve Web App"
  },
  "http_request": {
    "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 13_5_2)",
    "url": "<https://app.resolve.ai/login>"
  },
  "metadata": {
    "product": "Resolve Web App",
    "version": "v2.3.1"
  },
  "src_endpoint": {
    "ip": "192.0.2.15",
    "type_id": 2
  },
  "dst_endpoint": {
    "hostname": "resolve.ai"
  }
}

(ii) Authorization Logs Class: OCSF Authorize Session Description: Logs session-level privilege or group assignment actions such as role changes, session establishment, or group binding events.Common Fields:

organization_id: Org associated with the event
activity_id: Authorization-related activity
category_uid, class_uid, type_uid: OCSF classification
status_id: Outcome status (e.g., success, failure)
severity_id: Informational, warning, etc.
event_time: ISO 8601 timestamp
user: { name, email }
groups: Array of assigned groups, if applicable
session.uid: Session identifier (optional)
http_request: { user_agent, url }
metadata: { product, version }
src_endpoint: { ip, type_id }
message: Human-readable explanation or annotation (optional)

Sample Authorization Log

{
  "auditable": true,
  "organization_id": "ORG_ABC123",
  "activity_id": 21,
  "category_uid": 6,
  "class_uid": 6002,
  "type_uid": 600202,
  "status_id": 1,
  "severity_id": 2,
  "event_time": "2025-07-09T15:03:50.541Z",
  "user": {
    "name": "Jordan Lee",
    "email": "jordan@company.com"
  },
  "groups": [
    {
      "name": "admin"
    },
    {
      "name": "editor"
    }
  ],
  "session": {
    "uid": "Ssn-9fa283ca-e441"
  },
  "http_request": {
    "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
    "url": "<https://app.resolve.ai/users/permissions>"
  },
  "metadata": {
    "product": "Resolve Web App",
    "version": "v2.3.1"
  },
  "message": "User added to admin and editor groups",
  "src_endpoint": {
    "ip": "203.0.113.48",
    "type_id": 1
  }
}

(iii) API Activity Logs Class: OCSF API ActivityDescription: Tracks API requests made by users, capturing request and response details, trace identifiers, endpoint activity, and session metadata.Common Fields:

organization_id: Source organization
activity_id: Activity type (e.g., create, read, update, delete)
category_uid, class_uid, type_uid: OCSF identifiers
status_id: Whether the request was successful
severity_id: Severity of the request (typically informational)
time: ISO timestamp of request
message: Custom message (e.g., “User fetched timeline”)
method: HTTP method (GET, POST, etc.)
endpoint: API endpoint accessed
actor: { user, session_uid }
http_request: { url, http_headers } (sensitive values redacted)
http_response: { status_code, http_headers }
src_endpoint: { ip }
dst_endpoint: { hostname, port }
metadata: { product, environment }

Sample API Activity Log

{
  "organization_id": "ORG_ABC123",
  "activity_id": 2,
  "category_uid": 3,
  "class_uid": 6003,
  "type_uid": 600302,
  "status_id": 2,
  "severity_id": 1,
  "time": "2025-07-09T15:30:11.884Z",
  "message": "Timeline data retrieval",
  "method": "GET",
  "endpoint": "/timeline",
  "actor": {
    "user": "Nina Patel",
    "session_uid": "sess_12de98f3fa7"
  },
  "http_request": {
    "url": "/timeline",
    "http_headers": {
      "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 13_5_2)",
      "accept": "*/*",
      "authorization": "REDACTED",
      "x-generated-nonce": "REDACTED"
    }
  },
  "http_response": {
    "status_code": 200,
    "http_headers": {
      "content-type": "application/json",
      "x-remix-response": "yes",
      "set-cookie": "REDACTED"
    }
  },
  "src_endpoint": {
    "ip": "198.51.100.77"
  },
  "dst_endpoint": {
    "hostname": "api.resolve.ai",
    "port": 443
  },
  "metadata": {
    "product": "Resolve Web App",
    "environment": "production"
  }
}

​User Access Logs

​Accessing the User Access Logs using Audit Logs API

​Integration Access Logs

​Accessing the Integration Access Logs from the Resolve Satellite

​Frequently Asked Questions (FAQs)

User Access Logs

Accessing the User Access Logs using Audit Logs API

Integration Access Logs

Accessing the Integration Access Logs from the Resolve Satellite

Frequently Asked Questions (FAQs)