Audit Log Integration Guide

Overview

Axle can deliver an audit log of your organization's activity on the Axle platform to your own security tooling, such as a SIEM. The log records who signed in and out, what your users did in the Axle web app, every call made with your API keys, every tool your team's AI assistants called through the Axle MCP server, and every change made to your configuration and alerts.

Getting Started

The audit log is enabled for each organization by the Axle team. There is no setting to turn it on yourself.

To get started, contact your Axle account representative. They will work with your security team to agree on where the log is delivered and to confirm that the first events arrive.

Have the following ready:

• The tool that will receive the log, for example Splunk.
• A technical contact on your security team.
• Whether you need the log for your production organization, a test organization, or both.

What's Recorded

Each record describes one event. The event_type field says which kind it is.

Some actions produce more than one event. For example, setting an alert's disposition from an AI assistant records an EVENT_TYPE_MCP_TOOL_CALL for the tool call and an EVENT_TYPE_CONFIG_CHANGED for the change it made.

What's not recorded

The log records that something happened, who did it and where from. It doesn't copy your data:

• API requests record the method and path only. Query strings and request and response bodies are never recorded.
• MCP tool calls record the tool name only, not the arguments the assistant sent or the data it received.
• Changes made by AI assistants record identifiers and values like a disposition or a flag color. Note text, feedback reasoning, rerun reasons, support ticket text and uploaded entity details (names, dates of birth, emails, phone numbers) are never recorded.
• Secrets are never recorded. That includes API keys, webhook signing secrets, session tokens and webhook URLs, which can contain credentials.
• Failed sign-ins for unknown email addresses aren't recorded, because they don't belong to any organization.
• Activity by Axle personnel isn't included in your log.

Record Format

Delivery envelope

Each record is a delivery envelope with the event inside it, at jsonPayload.customer_audit_event. Point your field extractions there, for example jsonPayload.customer_audit_event.actor.email.

{
  "jsonPayload": {
    "customer_audit_event": {
      "event_id": "00000000-0000-4000-8000-000000000001",
      "event_type": "EVENT_TYPE_API_REQUEST"
    },
    "message": "customer audit event"
  },
  "insertId": "73dryk2dibo3701s",
  "timestamp": "2026-10-20T17:04:05.125Z"
}

The envelope has more fields than this example shows. They describe how Axle's systems delivered the record and aren't part of the audit log: ignore them, and don't depend on their names or values, which can change without notice. jsonPayload.message is always customer audit event. Use occurred_at inside the event, not the envelope's timestamp, as the time the event happened.

The rest of this guide shows only the contents of jsonPayload.

The event

Here is a public API call made with an API key:

{
  "customer_audit_event": {
    "event_id": "00000000-0000-4000-8000-000000000001",
    "event_type": "EVENT_TYPE_API_REQUEST",
    "org_id": "c1aeec53-6137-4f08-ba2d-616a4d8311ae",
    "actor": {
      "type": "ACTOR_TYPE_API_KEY",
      "id": "5e2f9a14-8c3b-4d7e-a1f0-6b9c2d4e8a37"
    },
    "outcome": "OUTCOME_SUCCESS",
    "occurred_at": "2026-10-20T17:04:05.123Z",
    "source_service": "api-service",
    "client_ip": "203.0.113.7",
    "api_request": {
      "method": "POST",
      "path": "/api/v1/alerts",
      "status_code": 201,
      "duration_ms": 184
    }
  }
}

Empty fields are left out. A field with no value is left out of the record rather than sent as an empty string or zero. For example, a sign-out has no detail object. Treat a missing field as empty.

Common fields

Every event has these fields.

Each event type also carries one detail object, described in Event Details.

Actor

• ACTOR_TYPE_USER is a person using the Axle web app, including the in-app assistant.
• ACTOR_TYPE_API_KEY is a request authenticated with one of your API keys. It is attributed to the key, not to the person who created it.
• ACTOR_TYPE_OAUTH_CLIENT is an application acting for a user, such as an AI assistant connected through the Axle MCP server. email is the user it acts for.

Outcome

OUTCOME_DENIED can point to misuse. OUTCOME_ERROR usually doesn't, so an Axle outage won't look like an attack in your log.

Client IP

client_ip is the address that connected to Axle's network edge. Addresses a client claims for itself in request headers such as X-Forwarded-For or X-Real-IP are ignored, so the value can't be spoofed that way. If the client connects through a proxy or VPN, the address is the proxy's.

Event Details

Sign-in and sign-out

EVENT_TYPE_LOGIN_SUCCEEDED and EVENT_TYPE_LOGIN_FAILED carry a login object. EVENT_TYPE_LOGOUT carries no detail object.

Sign-ins are recorded against the user's home organization.

{
  "customer_audit_event": {
    "event_id": "00000000-0000-4000-8000-000000000005",
    "event_type": "EVENT_TYPE_LOGIN_FAILED",
    "org_id": "c1aeec53-6137-4f08-ba2d-616a4d8311ae",
    "actor": { "type": "ACTOR_TYPE_USER", "email": "[email protected]" },
    "outcome": "OUTCOME_DENIED",
    "occurred_at": "2026-10-20T17:04:05.123Z",
    "source_service": "portal-api",
    "client_ip": "203.0.113.7",
    "login": { "method": "passwordless", "failure_reason": "invalid_code" }
  }
}

Web app activity

EVENT_TYPE_PORTAL_REQUEST carries a portal_request object.

The web app also calls the Axle API, which appears as EVENT_TYPE_API_REQUEST with an ACTOR_TYPE_USER actor. Moving between pages isn't recorded on its own, but the data each page loads is.

API requests

EVENT_TYPE_API_REQUEST carries an api_request object.

Requests rejected before they are authenticated, such as a request with an invalid API key, can't be attributed to an organization, so they aren't recorded.

MCP tool calls

EVENT_TYPE_MCP_TOOL_CALL carries an mcp_tool_call object.

outcome is OUTCOME_DENIED when the tool refused the call, for example for a missing permission, and OUTCOME_ERROR when it failed unexpectedly.

{
  "customer_audit_event": {
    "event_id": "00000000-0000-4000-8000-000000000008",
    "event_type": "EVENT_TYPE_MCP_TOOL_CALL",
    "org_id": "c1aeec53-6137-4f08-ba2d-616a4d8311ae",
    "actor": { "type": "ACTOR_TYPE_OAUTH_CLIENT", "email": "[email protected]" },
    "outcome": "OUTCOME_SUCCESS",
    "occurred_at": "2026-10-20T17:04:05.123Z",
    "source_service": "api-service",
    "client_ip": "203.0.113.7",
    "mcp_tool_call": { "tool": "get_alert", "client_id": "mcp-client-0042", "duration_ms": 731 }
  }
}

Configuration and alert changes

EVENT_TYPE_CONFIG_CHANGED carries a config_change object.

A change that affects several alerts at once, such as a bulk disposition, records one event per alert.

Alert IDs and entity IDs are the IDs you gave Axle when you submitted the alert.

{
  "customer_audit_event": {
    "event_id": "00000000-0000-4000-8000-000000000007",
    "event_type": "EVENT_TYPE_CONFIG_CHANGED",
    "org_id": "c1aeec53-6137-4f08-ba2d-616a4d8311ae",
    "actor": { "type": "ACTOR_TYPE_USER", "email": "[email protected]" },
    "outcome": "OUTCOME_SUCCESS",
    "occurred_at": "2026-10-20T17:04:05.123Z",
    "source_service": "api-service",
    "client_ip": "203.0.113.7",
    "config_change": {
      "action_type": "webhook_toggled",
      "setting_name": "webhook:3f6a2c1e-9b8d-4e7f-a5c4-1d2e3f4a5b6c",
      "old_value": "is_active:True",
      "new_value": "is_active:False"
    }
  }
}

Working with the Log

• Remove duplicates by event_id. A record can occasionally be delivered more than once. A repeated event_id is the same event.
• Order by occurred_at. Records aren't guaranteed to arrive in the order the events happened. Configure your SIEM to take each event's time from jsonPayload.customer_audit_event.occurred_at.
• Expect records in batches. Records are delivered in batches, usually within about an hour of the event. A batch can contain events from earlier periods that arrived late.
• Expect new values. New event types, action types and fields may be added over time. Ignore values you don't recognize rather than rejecting the record. Existing fields won't be renamed or removed without notice.
• Expect volume to follow usage. The web app records an event for each action it performs, including the regular refreshes some pages make while open, so an active user can produce many events per minute.

FAQ

Does the log include other organizations' activity?
No. Your log contains only events for your organization.

Can I enable the log, or change what it includes, myself?
No. The log is set up by the Axle team. Contact your Axle representative to enable it, change where it's delivered or ask about its contents.

Why is a user's sign-in missing from my log?
Sign-ins are recorded against the user's home organization. If that is a different Axle organization, the sign-in is recorded there.

Why don't I see failed sign-ins for an email address?
Failed sign-ins are recorded only for email addresses that belong to a user in your organization.

Are changes made by an AI assistant recorded?
Yes, whether they're made in the Axle web app's built-in assistant or through the Axle MCP server. The actor is the user the assistant acted for.

Who do I contact with questions?
Your Axle account representative.