Governance, Guardrails & Approvals

Governance is the layer between "the model decided to" and "the platform did". Every tool call passes through a staged guard pipeline, gated actions park in an approval inbox, tenant policy shapes what needs a human, and every decision lands in the audit log. Modules: core/guardrails and core/approval.

flowchart TD TC["Tool call proposed by model"] --> S1["1 · Step ceiling
max steps per turn?"] S1 -->|ok| S2["2 · RIGOROUS verify
ToolCallVerifierService (if depth=RIGOROUS)"] S1 -->|exceeded| DENY1["Deny / stop turn"] S2 -->|plausible| S3["3 · HITL gate
HumanApprovalGateService"] S2 -->|rejected| DENY2["Call refused"] S3 -->|auto-allowed| S4["4 · Output validation"] S3 -->|parked| INBOX["Approval inbox
(tenant-admin decides)"] INBOX -->|approve| S4 INBOX -->|reject| DENY3["Call refused · audited"] S4 --> S5["5 · Sanitization
redact/escape output"] S5 --> EXEC["Tool executes"] EXEC --> AUD["Audit log + tool_call_log"]
GuardedToolCallback: the five-stage pipeline every tool call traverses.

FR-GOV-01 · GuardedToolCallback pipeline

GuardedToolCallback (core/guardrails/.../GuardedToolCallback.java) wraps every tool — built-in, integration, MCP — in the same five stages:

StageFunction
1 · Step ceilingCaps the number of tool calls a single turn may make; stops runaway loops.
2 · RIGOROUS verifyFor agents at ReasoningDepth.RIGOROUS, an independent verifier call (ToolCallVerifierService) checks the call plausibly matches the user's ask before it may run.
3 · HITL gateHumanApprovalGateService decides — from tool classification, tenant policy and jev thresholds — whether the call executes, is refused, or parks on the approval inbox.
4 · Output validationChecks the tool's result shape/content before it re-enters the model context.
5 · SanitizationRedacts/escapes output so tool results cannot smuggle instructions or leak secrets back into the prompt.

FR-GOV-02 · Approval inbox & policies

Gated actions are durable ApprovalRequest rows served by ApprovalController at /api/approvals. Tenants tune gating via approval policies (PUT /api/approvals/policy, ApprovalPolicyService) — which action types auto-allow, which require sign-off, which are admin-only.

RequirementDescriptionStatus
FR-GOV-02.1Inbox lists pending requests; approve/reject resolves them and resumes the parked run/job.live
FR-GOV-02.2Admin-only classes: gated agent tool calls (mcp_tool.* action types) and adminOnly payloads are decidable by tenant-admin only; unparseable payloads default-deny; a requester cannot approve their own request (self-approval check).live
FR-GOV-02.3Approval replay grants: an approval can carry a recorded replay envelope so the exact approved tool input executes — not a re-asked model call.live
FR-GOV-02.4Retry job: a scheduled job re-drives approved-but-unexecuted actions, so approvals never strand.live
FR-GOV-02.5Channel-send approvals: outbound channel messages can be gated so a human reviews what an agent says to a customer before it sends (VOICE is the deliberate exception — a live call cannot wait).live

FR-GOV-03 · Content moderation

Moderation packs screen content against configurable rule sets; flagged items queue in a human review queue for a moderator decision. Tenant guardrail rules (TenantGuardrailRuleEvaluator, CustomRuleContentGuardrail) let a tenant define its own blocked/escalated content classes on top of platform packs.

FR-GOV-04 · Procedures / SOP layer

Procedures (migration V270__procedures.sql) are tenant-defined standard operating procedures enforced at the tool boundary: ProcedureGuardEvaluator and ProcedureGuardKind check a proposed tool call against the SOP (e.g. "refunds above ₹X require a human", "never email outside the allow-list domain") inside the guard pipeline, not as prompt instructions the model can ignore.

FR-GOV-05 · Audit log

Approval decisions, gated executions, policy changes and administrative actions write audit records — the evidentiary trail for "who let the agent do that". See Security: Compliance Posture for retention posture.

FR-GOV-06 · Kill switches & tenant controls

ControlScopeEffect
Tenant kill switchOne tenantHalts agent execution for that tenant without touching the platform.
Platform kill switchGlobalPlatform-admin emergency stop of agentic execution.
Guardrail rulesPer tenantCustom blocked/escalated content and action classes.
Allow-listsPer tenantWhitelisted tools/domains/recipients exempted from or required for gating.
Autonomy tiersPer tenant / per agent (jev threshold)Graduated autonomy — from "approve everything" to "auto-allow within policy".

FR-GOV-07 · Compliance program

The software carries no compliance certification. The controls it implements, and how they map to SOC 2 and ISO/IEC 42001, are summarised on Compliance Posture; compliance is a property of each deployment and its operator.

Unverified claim class

"SOC 2" / "ISO 42001" anywhere in product copy refers to the assessment document's control mapping — no audit has been performed. Do not present either as attained.

Cross-references