/ docs · functional specification

The full platform
functional reference.

Every functional area of AI API Mapper documented at implementation depth so architects, security reviewers, and platform engineers can evaluate the product with real technical context.

Runtime · Governance

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
  • 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.

Each audit record captures:

  • tenant and actor identity
  • correlation ID
  • 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.)

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 a correlation ID.

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.

Functional Value

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