Audit Logs

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 {job="satellite telemetry"} | json | audit="true"index=satellite index audit=trueaudit\ 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 requirements to 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 configuration enable 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 authentication description 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 activity description 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" } }