Workflow: Govern an Action

Every AI action in your organization flows through TheWARDN's governance pipeline before it can execute. This page walks through exactly what happens when POST /govern is called.

Overview

The /govern endpoint is the single point of control for all AI agent actions. Every call produces an immutable audit record regardless of outcome.

Flow Diagram

Request arrives at POST /govern
         |
         v
+--------------------+
| Governance Mode?   |
+--------------------+
  |        |        |
  v        v        v
DISABLED  AUDIT   ENFORCED
  |       ONLY      |
  |        |        v
  |        |   Agent Lookup
  |        |        |
  |        |        v
  |        |   Agent Status Check
  |        |   active / paused / blocked / deregistered
  |        |        |
  |        |        +--- paused ------> All actions HELD
  |        |        +--- blocked -----> All actions BLOCKED
  |        |        +--- deregistered -> 403 Forbidden
  |        |        |
  |        |        v (active)
  |        |   CHAM Policy Load
  |        |   - Tenant-wide policies
  |        |   - Agent-scoped policies
  |        |   - Confidence floor injection
  |        |        |
  |        |        v
  |        |   Decision Boundary Checks
  |        |   - Sequence state
  |        |   - Grant lifecycle
  |        |   - L6 model governance
  |        |        |
  |        |        v
  |        |   Sentinel Evaluation
  |        |   - 21 SGP rules
  |        |   - CHAM policies
  |        |   - Tier mapping
  |        |   - Change windows
  |        |        |
  |        |        v
  |        |   +---------------------+
  |        |   | Verdict             |
  |        |   +---------------------+
  |        |     |       |       |
  |        |     v       v       v
  |        |  CLEARED  HELD   BLOCKED
  |        |     |       |       |
  |        |     |       v       v
  |        |     |   Escrow   Violation
  |        |     |   Created  Recorded
  |        |     |       |       |
  |        v     v       v       v
  |    +-----------------------------+
  |    | Audit Record Sealed         |
  |    | (SHA-256 hash chain)        |
  |    +-----------------------------+
  |              |
  v              v
Pass         Response Returned
Through      to Caller

Step-by-Step Walkthrough

1. Request Arrives at /govern

The client sends a POST /govern request with the action payload:

{
  "agent_id": "agent_abc123",
  "action": "send_email",
  "parameters": {
    "to": "customer@example.com",
    "subject": "Follow-up",
    "body": "..."
  },
  "confidence": {
    "overall": 0.87,
    "relevance": 0.92,
    "safety": 0.85,
    "accuracy": 0.84
  }
}

2. Governance Mode Check

The tenant's governance mode is checked first:

Mode	Behavior
DISABLED	Action passes through immediately. No evaluation. No audit.
AUDIT_ONLY	Full evaluation runs, verdict is logged, but the action is always allowed.
ENFORCED	Full evaluation runs. Verdict is binding. HELD and BLOCKED verdicts stop the action.

TIP

AUDIT_ONLY mode is ideal for onboarding. You can see what governance would do without blocking any production actions.

3. Agent Lookup and Status Check

TheWARDN looks up the agent by agent_id. The agent's current status determines what happens next:

Status	Behavior
active	Proceed to policy evaluation
paused	All actions automatically HELD (sent to escrow for human review)
blocked	All actions automatically BLOCKED (violation recorded)
deregistered	Request rejected with 403 Forbidden

WARNING

A deregistered agent cannot send governance requests. It must be re-registered to resume operations.

4. CHAM Policy Load

The Contextual Hierarchical Action Model (CHAM) loads all applicable policies:

1. Tenant-wide policies -- apply to every agent in the tenant
2. Agent-scoped policies -- apply only to the specific agent
3. Confidence floor injection -- if the agent has a confidence floor set, it is injected as a synthetic policy

Policies are additive. An action must satisfy all applicable policies to be CLEARED.

5. Decision Boundary Checks

Before Sentinel evaluation, three boundary checks run:

• Sequence state -- Is this action part of an approved sequence? Has the sequence expired or been revoked?
• Grant lifecycle -- Does this agent have an active grant for this action type? Has it been consumed or expired?
• L6 model governance -- Is the underlying model approved for this action category? Are model-level restrictions in effect?

6. Sentinel Evaluation

Sentinel is the core governance engine. It evaluates the action against:

• 21 SGP rules -- The Sentinel Governance Protocol, a comprehensive rule set covering safety, authorization, data handling, and more
• CHAM policies -- All loaded policies from step 4
• Tier mapping -- The action's tier classification (A/B/C) determines escalation thresholds
• Change windows -- Time-based restrictions (e.g., no deployments outside maintenance windows)

7. Verdict Determination

Sentinel returns one of three verdicts:

Verdict	Meaning	What Happens
CLEARED	Action is safe to execute	Action proceeds. Audit record sealed.
HELD	Action needs human review	Escrow record created. Action waits for human decision.
BLOCKED	Action is prohibited	Violation recorded. Action is killed.

The worst-case rule wins. If 10 policies pass but 1 triggers a HOLD, the verdict is HELD. If any policy triggers a BLOCK, the verdict is BLOCKED regardless of other results.

8. Audit Record Sealing

Every governance decision produces an immutable audit record:

{
  "audit_id": "aud_xyz789",
  "timestamp": "2026-04-10T14:32:01.000Z",
  "agent_id": "agent_abc123",
  "action": "send_email",
  "verdict": "CLEARED",
  "fired_policies": [],
  "confidence_scores": { "overall": 0.87 },
  "hash": "a3f2b1c4d5e6...",
  "prev_hash": "9e8d7c6b5a4f..."
}

The hash field is a SHA-256 hash of the record contents plus the previous record's hash, forming an unbroken chain. Tampering with any record breaks the chain and is immediately detectable.

9. Escrow Creation (if HELD)

When the verdict is HELD, an escrow record is created:

• The action is frozen in its current state
• A timeout is set (default: 10 minutes for B-tier, 30 minutes for C-tier)
• The escrow appears in the console for human review
• The API returns escrow_id so the caller can poll for resolution

See Escrow Lifecycle for details on what happens next.

10. Violation Record (if BLOCKED)

When the verdict is BLOCKED, a violation record is created with:

• The full action payload
• All fired policies and their reasons
• Severity level (CRITICAL / HIGH / MEDIUM / LOW)
• The agent responsible
• Timestamp and hash chain link

See Incident Response for how to handle violations.

11. Response Returned

The API returns the governance decision:

{
  "verdict": "CLEARED",
  "audit_id": "aud_xyz789",
  "fired_policies": [],
  "timestamp": "2026-04-10T14:32:01.000Z"
}

For HELD verdicts, the response includes escrow_id:

{
  "verdict": "HELD",
  "audit_id": "aud_xyz789",
  "escrow_id": "esc_def456",
  "timeout": 600,
  "fired_policies": ["policy_confidence_floor"],
  "timestamp": "2026-04-10T14:32:01.000Z"
}

For BLOCKED verdicts, the response includes the violation:

{
  "verdict": "BLOCKED",
  "audit_id": "aud_xyz789",
  "violation_id": "vio_ghi012",
  "fired_policies": ["policy_no_pii_external"],
  "reason": "Action blocked: PII detected in outbound email",
  "timestamp": "2026-04-10T14:32:01.000Z"
}

Latency

Governance evaluation typically completes in under 50ms. The hash chain sealing adds approximately 1-2ms. Total round-trip time for a /govern call is typically under 100ms.

Next Steps

• Escrow Lifecycle -- What happens after a HELD verdict
• Policy Evaluation -- Deep dive into how policies combine
• Incident Response -- Handling BLOCKED verdicts