Skip to main content
Every MCP tool call that completes — whether allowed, denied, or escalated — writes exactly one AgentActivityEvent row to activity_log (via the agent-platform columns added by migration 0042) via a Postgres trigger (the F4 IRON RULE: no direct INSERT path exists outside the trigger). Operators cannot delete or update rows; the table is append-only by design. The Trust Console tails this table in real time; the audit:stream MCP scope surfaces a read-only window of these events — the agent-event projection — to authorized agent runtimes.

Canonical URL

https://glide.co/schemas/agent-banking/v1/agent-activity-event.json

Required fields

Optional fields

eventKind vocabulary

Lifecycle

AgentActivityEvent rows are written by a Postgres trigger on the activity_log table — not by application code. This is the F4 IRON RULE: no direct INSERT path exists, and there is no UPDATE or DELETE path for any consumer. When emitted: on every MCP tool call commit (including denied calls — the row captures the denial). Non-tool-call events (consent_granted, kill_switch_triggered, etc.) are emitted by the corresponding server-side handlers via the same trigger path. Who consumes:
  • Trust Console UI — tails the table via a tRPC subscription with per-principal row-level security.
  • audit:stream MCP scope — exposes a read-only window to authorized agent runtimes. Scoped to the calling grant’s vaultId; cross-vault reads are refused.
  • Ops dashboards — query activity_log directly (read-only DB role), filtering on agent_principal_id IS NOT NULL.
Retention: the activity_log table is append-only with no TTL at v1. Row-level security ensures each principal can only read their own events. Future versions may introduce archival tiers (see @glideco/compliance-export).

Example

Validation

The event is validated three ways:
  1. At write time by the Postgres trigger — the trigger schema-checks required fields before inserting. Events that fail the check are rejected; the calling transaction rolls back.
  2. At build time via scripts/validate-manifests.mjs:
  3. Against the published JSON Schema for consumer-side validation:

Common pitfalls

  • Setting eventKind but not eventType. The schema marks eventType as required for backward compat. Both fields must be set and must match.
  • Omitting eventId on new producers. Consumers de-duplicate on eventId. Without it, retried deliveries create duplicate Trust Console rows.
  • Passing a non-UTC timestamp. The isoDateTimeUtc type requires the Z suffix. +00:00 offset strings fail schema validation and are rejected at ingest.
  • Emitting an eventKind value outside the closed enum. Unknown values are dropped at ingest without error. The enum is CODEOWNERS-protected — new values require a schema migration.
  • Storing PII in summary. The summary field renders in the Trust Console list row, which may be visible to support staff. Keep it to action + amount + rail — no email addresses, phone numbers, or wallet addresses.

Reading list