Runtime Governance

Purpose

This functional area ensures runtime execution remains observable, traceable, and compliant with platform policy.

Main Capabilities

• audit event generation for runtime activity
• correlation-aware per-step call tracing
• acceptance of an optional caller-supplied correlation ID
• request and response payload capture
• configurable audit event filtering
• visibility into execution outcomes
• security throttling and authentication protection

Audit Event Generation

The Runtime writes governance audit records for runtime activity including tool listing, tool invocation, authorization outcomes, downstream call results, and any processing errors.

Repeated invalid bearer tokens and API keys are counted asynchronously through a shared authentication-protection store, which evaluates increments, time windows, alert thresholds, suppression, and expiry atomically. Alert bookkeeping deliberately fails open only after the request has already been denied, so a monitoring degradation never changes an authentication outcome.

Each audit record captures:

• tenant and actor identity
• execution ID (the correlation ID the platform generates for the call)
• external correlation ID, when the caller supplied one
• category and action
• status (Allowed, Denied, Error)
• HTTP method, host, and path
• structured dimension data for the step (mapping name, tool name, policy match, timing, etc.)

Credential Identity Attribution

The recorded actor on a tool-invocation audit record is always the calling identity — the real caller who invoked the tool — regardless of which downstream credential was used to make the call. This holds even when the call ran under a delegated credential (see Runtime Credential Resolution → Credential Caching): the audit trail never attributes a call to a delegated credential's own identity. Each record separately indicates whether the downstream call ran with a credential bound to the caller (On-Behalf-Of / delegated token exchange) or with a credential shared across the tenant, so an operator can review that distinction per invocation without the audit trail ever misattributing who made the call.

Configurable Audit Filtering

The governance audit writer supports event-level filtering through the Governance:Audit configuration section.

Configuration options include:

• Enabled — enable or disable audit logging globally
• LoggedEvents — a list of patterns that restrict which events are written (empty means all events are written)
• SuppressedEvents — a list of patterns that suppress specific events even when logging is enabled

Patterns follow the form category:action:outcome where each segment accepts * as a wildcard.

Request And Response Payload Logging

When request/response logging is enabled for a tool, the Runtime captures sanitized payload data as additional audit dimensions.

What Is Captured

For MCP-based invocations:

• the raw MCP request payload
• the raw MCP response payload

For downstream HTTP calls:

• the outbound HTTP method, URL, headers, and body
• the inbound HTTP status code, headers, and body

For SOAP-based calls, the same capture model includes the serialized SOAP request and response bodies, with SOAP security headers and credential-derived values sanitized before the payload becomes operator-visible.

Sanitization

All captured payloads pass through a sanitization step that:

• redacts sensitive header names (Authorization, tokens, API keys, secrets, cookies)
• redacts sensitive JSON property names and values
• redacts sensitive query string parameters
• truncates output to a configurable maximum byte size (default 512 KB per dimension)
• appends a truncation marker when content is cut

Configuration Per Tool

Request/response logging is configured at the toolset level and can be overridden per endpoint.

Configurable options include:

• RequestResponseLoggingEnabled — enables or disables payload capture for the toolset (disabled by default)
• RequestResponseLoggingMaxBodyBytes — the maximum bytes to capture per payload (default 512 KB)
• per-endpoint logging overrides that enable or disable capture for individual tools independently of the toolset default

Correlation-Aware Call Tracing

All audit records for a single runtime invocation share an execution ID.

The Runtime generates this ID itself for every request. It is never taken from caller input, so two callers cannot land in the same trace and no caller can write into another caller's execution history.

The call trace view reconstructs the full execution sequence by grouping records on this ID.

Each step in the trace includes:

• action name
• outcome status
• timestamp
• execution duration in milliseconds, when captured
• step-specific dimensions

The trace also exposes resolved caller information including tenant name, client application name, caller subject ID, and caller IP address when available.

External Correlation IDs

A caller may send an X-Correlation-Id header with an MCP tool call. The Runtime records that value as the external correlation ID and associates it with the execution ID it generated for the call, so an operator can start from an identifier the calling system already knows and find every platform audit record for that work.

The header is optional. Behaviour when it is present:

• the value is stored alongside — never in place of — the execution ID
• the value is echoed back on the X-External-Correlation-Id response header, confirming acceptance
• every audit record written for the call carries the value, so filtering by it returns the whole trace

The value is treated as an untrusted opaque identifier. It is accepted only when it is at most 128 characters and contains only letters, digits, and the punctuation identifiers normally use (- _ . : / + = @ #). Anything else — control characters, header-splitting sequences, whitespace, free-form sentences — is discarded rather than truncated, and the call proceeds with no external correlation ID recorded.

This field carries an identifier and nothing else. The platform does not accept, store, or process user prompts through it, and the character and length rules exist so it cannot be used to smuggle prompt content or arbitrary text into the audit trail.

Both the governance audit explorer and the Call Flow explorer can filter on the external correlation ID, and both display it next to the execution ID.

Functional Value

This area is what makes the Runtime acceptable for enterprise use cases where execution cannot be a black box.