Review these terms to understand and use the AI governance audit log viewer effectively.
The 1:1:1 mapping
The governance model that Agent Governance audits is built on a 1:1:1 mapping: one Airman MCP instance, one declared purpose, and one Postgres login role. When an AI agent operates through a specific Airman MCP instance, it connects to Postgres as a role that has only the privileges appropriate to that purpose. The database enforces this boundary — not application code, not middleware, and not prompts. See Configuring Airman MCP for setup details.
Airman MCP
Airman MCP is the Model Context Protocol (MCP) server that brokers Postgres access for AI agents. It exposes Postgres operations as tools the agents can call, and it tags every query it runs via the Postgres application_name variable in the form airman:<purpose>/<session-short>, so the activity can be reconstructed later. The viewer relies entirely on these tags to group and attribute agent activity.
Purpose
Purpose is a declared intent label configured per Airman MCP instance through the AIRMAN_MCP_PURPOSE environment variable (for example, billing, support, or analytics). It appears as the first segment of the tag Airman writes to each query and is surfaced in both the sessions list and session detail. Purpose is set on the agent side, not in the viewer.
Access mode
Access mode controls what SQL an Airman MCP instance is permitted to execute. In restricted mode, Airman performs SQL syntax analysis before forwarding a query to PostgreSQL, blocking disallowed statement types such as DROP, DELETE, and INSERT at the MCP layer. Every query also runs inside a read-only transaction with enforced timeouts. In unrestricted mode, write operations are permitted, which is appropriate for agents that need to persist output — for example, a reporting agent writing to a dedicated output table. Access mode is configured on the Airman MCP instance, not in the viewer.
Session
A session is a logical grouping of SQL statements executed by an AI agent within a single Airman MCP interaction. Each session is the primary unit of audit in the viewer: when you open a cluster, you see its sessions, and when you open a session, you see the statements it contains.
Airman MCP identifies a session with a session short — the first eight hexadecimal characters of the MCP session token. All log entries that share a session short belong to the same session.
Step
A step is a single SQL statement within a session — one parsed Postgres log record. Each step carries the SQL text and its execution metadata: target database, Postgres role, backend process ID, duration, and error severity.
Instance
An instance is a registered upstream data source — either a Hybrid Manager (HM) deployment or a standalone Loki endpoint. The viewer can connect to multiple instances at once, aggregating the clusters and sessions from all of them. See Connecting data sources.
Cluster
A cluster is a Postgres cluster managed by HM or monitored through Loki. The viewer lists clusters as the entry point for auditing: you pick a cluster, then review the AI agent sessions detected for it.
Loki and LogQL
Loki is the log aggregation system that stores the Postgres query logs the viewer reads. It's optimized for label-based queries expressed in LogQL, its query language. HM includes a Loki pipeline. You can also point the viewer at a standalone Loki instance that receives Postgres logs. The viewer's backend constructs LogQL queries to find the session-tagged log entries for a cluster.
Sync watermark
A sync watermark is a per-instance, per-cluster record that tracks how far back the viewer's backend has cached session data from Loki. It records the earliest known entry and how far the cache has been populated, which is what enables fast, incremental syncing instead of requerying the full log history on every visit. See Architecture and data flow.