إنتقل إلى المحتوى الرئيسي

Approval queue workflow

When you'd use this​

The approval queue exists because some agent and operator actions are too consequential to run without human sign-off. This runbook walks through reading the queue, evaluating the context, and approving or rejecting a request.

What lands in the queue​

The architecture document defines five automation tiers:

  • L0, read-only; never blocks on approval.
  • L1, agent recommends an action; no approval needed because no action is taken.
  • L2, agent acts after synchronous approval; this is the queue's primary source.
  • L3, agent auto-quarantines reversible actions; the approval queue receives a post-hoc record but the operator cannot block it.
  • L4, auto-close on narrow pre-approved categories; never blocks.

The Security Overview dashboard surfaces the queue depth and the high-risk subset (critical + high). The pulsing dot on the KPI card means high-risk items are present right now.

Reading a request​

Each request carries:

  • The action verb (Isolate host, Disable account, Block egress, Rotate key, ...).
  • The risk level (low, medium, high, critical) computed by the policy bundle.
  • The requesting agent or operator identity.
  • The case ID it belongs to (drilldown linked).
  • The expiry time. If the request is not acted on before expiry, the approval defaults to rejection and the agent is notified.

Acting on a request​

Approve, reject, or reach for context. Approving fires the underlying action via the appropriate MCP server; the action result lands on the case's audit trail. Rejecting closes the request; the agent is notified and decides whether to retry with a different proposed action.

A request you suspect is malicious (compromised operator identity, unexpected agent behaviour) should be rejected and the operator account flagged. The approval audit trail is queryable from the observability page.

What goes wrong​

  • Request expires before you can act, the agent receives a rejected_by_expiry outcome and decides whether to re-request. The dashboard's high-risk approvals card surfaces the time-remaining so this should not surprise you.
  • An "approve" click returns "policy bundle stale", the policy bundle that authorised the request has been superseded. Refresh the page and re-evaluate; the request body shows the bundle version it was issued against.
  • A request without a case ID, that is allowed for system- initiated actions (mode changes, maintenance jobs). The requested_by field tells you which actor proposed it.