Audit Logs

Viewing Audit Logs

Every action in Runlayer is logged for security and compliance:

Navigate to Audit Logs in the sidebar
Filter by:
- Date range
- Action type (created, deleted, accessed, etc.)
- User
- Resource (specific MCP server)
- Plugin (plugin lifecycle and plugin-proxied tool calls)
- Client (MCP client application, e.g. Cursor, Claude Desktop)
- Correlation ID
- Request ID
Click on any log entry to see full details

What Gets Logged

MCP server creation, configuration, and deletion
Skill creation, update, and deletion
Plugin creation, update, and deletion
Access requests and approvals
Policy changes
User authentication events
Tool calls and API requests (including skill and plugin proxy calls) — tool call events include ToolGuard scan metadata (scanner name, score, duration) when security scanners are active
Agent run lifecycle (start, success, failure) — including source, model, and duration
Agent artifact lifecycle (creation, update, deletion)
Agent account lifecycle (creation, credential rotation, deletion)
OAuth token refresh events (upstream success/failure, client-side failures)
Security violations and risk assessments

All logs are tamper-proof and retained for compliance purposes.

Prompts and model reasoning are not part of audit logs. They are captured in Sessions, which are short-term operational monitoring data built from client hooks and agent telemetry. Audit Logs remain the long-term system of record for tool calls, policy decisions, security events, and administrative activity.

Need to query or bulk-export audit logs programmatically? Use the Runlayer MCP audit log tools — including export_audit_logs for JSON/CSV exports with no 90-day hot-window restriction.

Retention

Audit logs are retained in two tiers:

Hot window (90 days by default) — recent events live in the database and power the in-app viewer, filters, and CLI queries.
S3 archive — events older than the hot window are archived to S3 rather than deleted, and remain available through the Runlayer MCP export_audit_logs tool, which is not subject to the hot-window restriction.

On self-hosted deployments the hot window is configurable via the audit_log_archive_hot_window_days Terraform variable (default 90). For retention fully under your own control, enable SIEM Export — every event is delivered to S3 in near real-time, and you set the lifecycle policy on the destination.

Sensitive Connector Redaction

Connectors that handle highly sensitive data (e.g. HR systems, financial databases) can be marked as sensitive by a Super Admin. When enabled, tool call arguments, results, errors, and security scan details are automatically redacted from audit log entries for that connector.

What gets redacted

Event type	Redacted fields
Tool calls and resource access	`args`, `result`, `error`
Security violations and warnings	`scan_input`, `area_of_concern`, `detected_items`

Metadata such as tool name, server name, timestamps, and actor information remain visible so admins can still see who called what and when — just not the payload contents.

Enabling sensitive mode

Navigate to the connector’s settings (Super Admin only)
Enable Sensitive audit log
Optionally select viewer roles that should see unredacted data
Save — redaction takes effect immediately for all future and existing log entries

Redaction is applied at read time, not at write time. The underlying audit log data is unchanged. If you later disable sensitive mode or add a viewer role, previously redacted entries become visible again.

Querying from the CLI

The uvx runlayer logs command lets you query audit logs from the terminal. By default it shows your own events from the last 7 days.

uvx runlayer logs

Options

Flag	Description
`--type, -t`	Filter by action type(s). Comma-separated or use shortcuts: `auth`, `tools`, `security`, `servers`, `agents`
`--server-id`	Filter by MCP server UUID
`--agent-id`	Filter by agent account UUID
`--client-name`	Filter by client name in event details
`--user-id`	Filter by user ID (admin only, defaults to self)
`--all`	Show all users’ logs (admin only)
`--start`	Start time (ISO 8601). Default: 7 days ago
`--end`	End time (ISO 8601). Default: now
`--limit, -n`	Max events to return (default 50, max 2000)
`--json`	Output raw JSON for scripting

Examples

# View security events from the last 7 days
uvx runlayer logs --type security

# View tool calls for a specific server
uvx runlayer logs --type tools --server-id <uuid>

# View all auth events as JSON
uvx runlayer logs -t auth --json

# View all users' events (admin only)
uvx runlayer logs --all --type tools

# View events in a specific time range
uvx runlayer logs --start 2026-03-20T00:00:00Z --end 2026-03-27T00:00:00Z

When the result set is larger than --limit, the CLI prints a next-page command you can copy-paste to continue paginating.

SIEM Export (S3)

Runlayer can continuously export audit logs to S3 for ingestion into your SIEM (e.g. CrowdStrike NG-SIEM, Splunk, Sentinel). Once enabled, every audit event is written as a gzip-compressed JSON file in near real-time.

How it works

Runlayer supports two S3 delivery patterns:

Runlayer-owned bucket — Runlayer writes audit log objects to an S3 bucket in the AWS account that hosts your Runlayer instance. Your team provides an IAM role ARN, and Runlayer grants that role read/list access so your SIEM pipeline can pull objects from the bucket.
Customer-owned bucket — your team provides a destination S3 bucket and prefix that you control. You grant the Runlayer export role write access to that bucket/prefix, and Runlayer writes audit log objects directly there.

In both patterns, each audit log is enqueued to an internal outbox and asynchronously exported as a .json.gz file. Most SIEMs support S3 as a native log source.

Runlayer does not need to assume a customer-owned IAM role for either pattern. In the Runlayer-owned bucket pattern, your role reads from the Runlayer export bucket. In the customer-owned bucket pattern, the Runlayer export role writes directly to your bucket.

S3 object layout

Objects are written with a Hive-style date partition prefix. The default prefix is audit-logs/:

audit-logs/year=2026/month=04/day=08/<audit_log_id>.json.gz

If a tool call produced a large result payload, it is stored alongside the main event:

audit-logs/year=2026/month=04/day=08/payloads/<audit_log_id>-result.json

For customer-owned bucket delivery, your Runlayer team can configure a custom prefix, such as:

runlayer/audit-logs/year=2026/month=04/day=08/<audit_log_id>.json.gz

Payload schema

Each exported file contains a single JSON object:

{
  "schema_version": 1,
  "audit_log_id": "uuid",
  "timestamp": "2026-04-08T12:00:00+00:00",
  "action_type": "TOOL_CALL_SUCCESS",
  "actor_id": "uuid",
  "actor_type": "user",
  "resource_type": "server",
  "resource_id": "uuid",
  "resource_name": "my-connector",
  "details": { ... }
}

Getting started

To enable SIEM export for your organization, contact your Runlayer account team. You will need to:

Choose a delivery pattern: Runlayer-owned bucket with pull-based ingestion, or customer-owned bucket with direct delivery.
For Runlayer-owned bucket delivery, provide the IAM role ARN your SIEM pipeline will use to read/list exported objects.
For customer-owned bucket delivery, provide the bucket name and prefix, and grant the Runlayer export role s3:PutObject, s3:AbortMultipartUpload, and s3:PutObjectTagging on that prefix.
If your bucket uses SSE-KMS, grant the Runlayer export role the required KMS permissions for writes.

The S3 export is independent of the in-app audit log viewer and the CSV/JSON download export. All three can be used simultaneously.

CrowdStrike NG-SIEM, Splunk, and most major SIEMs support S3 as a native data source. Use your SIEM’s S3 connector and point it at the bucket to start ingesting Runlayer audit events.

Scope and destinations

SIEM export covers audit logs only. Session data (prompts, reasoning, session timelines) is not exported to S3 or SIEMs — sessions are short-term operational data reviewed in the Runlayer app.
S3 is the delivery mechanism. There is no direct Runlayer-to-Datadog (or other SIEM) integration; any SIEM that can ingest logs from S3 can consume the export. The Datadog MCP connector available in Runlayer is for proxying Datadog tool calls through the gateway — it is not a log export destination.

Sessions

Monitor agent activity in real time

Enable

Control

Self-Hosted Deployment

Operations

Cookbook

Integrations

Connectors

Resources

Viewing Audit Logs

What Gets Logged

Retention

Sensitive Connector Redaction

What gets redacted

Enabling sensitive mode

Querying from the CLI

Options

Examples

SIEM Export (S3)

How it works

S3 object layout

Payload schema

Getting started

Scope and destinations

Sessions

​Viewing Audit Logs

​What Gets Logged

​Retention

​Sensitive Connector Redaction

​What gets redacted

​Enabling sensitive mode

​Querying from the CLI

​Options

​Examples

​SIEM Export (S3)

​How it works

​S3 object layout

​Payload schema

​Getting started

​Scope and destinations

​Related Resources

Sessions

Viewing Audit Logs

What Gets Logged

Retention

Sensitive Connector Redaction

What gets redacted

Enabling sensitive mode

Querying from the CLI

Options

Examples

SIEM Export (S3)

How it works

S3 object layout

Payload schema

Getting started

Scope and destinations

Related Resources