Skip to main content

Viewing Audit Logs

Audit Logs Every action in Runlayer is logged for security and compliance:
  1. Navigate to Audit Logs in the sidebar
  2. 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)
  3. 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.
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.

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 typeRedacted fields
Tool calls and resource accessargs, result, error
Security violations and warningsscan_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

  1. Navigate to the connector’s settings (Super Admin only)
  2. Enable Sensitive audit log
  3. Optionally select viewer roles that should see unredacted data
  4. 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

FlagDescription
--type, -tFilter by action type(s). Comma-separated or use shortcuts: auth, tools, security, servers, agents
--server-idFilter by MCP server UUID
--agent-idFilter by agent account UUID
--client-nameFilter by client name in event details
--user-idFilter by user ID (admin only, defaults to self)
--allShow all users’ logs (admin only)
--startStart time (ISO 8601). Default: 7 days ago
--endEnd time (ISO 8601). Default: now
--limit, -nMax events to return (default 50, max 2000)
--jsonOutput 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:
  1. 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.
  2. 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:
  1. Choose a delivery pattern: Runlayer-owned bucket with pull-based ingestion, or customer-owned bucket with direct delivery.
  2. For Runlayer-owned bucket delivery, provide the IAM role ARN your SIEM pipeline will use to read/list exported objects.
  3. 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.
  4. 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.

Sessions

Monitor agent activity in real time