Govern

Run manifest

Every run freezes a snapshot of exactly what it was authorized to do the instant it was created — not whatever your config says right now. That snapshot is stored on the run record (metadata.run_manifest) and, when the run is actually dispatched to a runner, copied onto the queued job too. Admin can pull it up for any run, forever.

What it is

At createRunCtx — the single function every run creation path (REST, streaming, cron, A2A delegation) goes through — the plane resolves the agent, the runner it will dispatch to, its declared tool allowlist and connector needs, whether connector policy is fail-closed, and who asked for the run. That resolved set of facts is written once, as run.metadata.run_manifest, and copied verbatim onto the queued job the runner receives. Neither copy changes after that point, even if you edit langgraph.json, rotate a grant, or flip policy on a minute later.

Why it is here

"What was this agent even allowed to do when it ran?" is a question every audit, incident review, and support ticket eventually asks. Live config answers "what's allowed right now" — which is the wrong answer once anything has changed since. A frozen per-run record is the only honest answer to a question about the past.

What's in it (schema v1)

{
  "schema_version": 1,
  "captured_at": "2026-09-05T02:58:06Z",
  "tenant_id": "acme",
  "agent_id": "sales-bot",
  "agent_version": 3,
  "runner_kind": "python-langgraph",
  "connector_needs": ["salesforce"],
  "allowed_tools": ["lookup_account"],
  "policy_fail_closed": true,
  "principal": { "identity": "alice", "permissions": ["runs:create"] },
  "parent_run_id": null,
  "depth": 0
}

agent_version — the registry version dispatched, so "which build of the agent actually ran" survives a later redeploy.
allowed_tools — absent means no in-graph tool allowlist was configured (unrestricted); present, including an empty list, means the runner was told to refuse every tool call not on it.
policy_fail_closed — whether the connector policy section was configured for this dispatch (true = a policy engine was active; it does not mean every call was denied). Specific allow/deny/pending decisions are still Grants & HITL and PDP / Cedar — see Audit for the decision log.
principal — omitted entirely when no auth provider is configured (open local/dev mode), not a blank record.

In the product

Runkite Admin Run detail page showing the Run manifest card

What to expect

Automatic, no config. Every run gets one in metadata — there's nothing to turn on, and nothing changes about how you write an agent. LLM cache hits get a manifest too (no runner dispatch, so nothing is copied onto a RunAssignment).
A record, not a gate. This is v1: it captures intent, it does not evaluate sequences of calls or block anything on its own. Reasoning about a sequence of tool calls in flight and denying a suspicious one before it runs is a different, heavier control than a per-run snapshot. Runkite's existing fail-closed grants, mandatory HITL, and break-glass are the enforcement layer; the manifest is what you check afterward to see what any of them were actually working with.
Lives in existing storage. No new database column or migration — it rides inside the metadata JSON column every run already has, so it works on every state backend the same way.
API-visible from day one. GET /admin-api/runs/{id} has always returned it (it's just a key in metadata); the Admin UI card in this release is what makes it visible without reading raw JSON.

Reference: docs/trust-governance.md · Grants & HITL · Admin UI guide → Threads & Runs · Limitations