check_approval
Check the status of a pending approval, or submit a decision.
WHEN TO USE: Only when the user asks you to check an approval or when you need to verify approval status before proceeding with a previously held action.
POLL MODE (no decision parameter): Returns the current status of an approval.
- status="pending": approval is still awaiting a human decision. Inform the user it is still pending and STOP. Do NOT poll in a loop — wait for the user to ask you to check again.
- status="approved": the action has been approved. You may now proceed with the original action that was held.
- status="rejected": the action was denied. Return the rejection reason to the user and STOP. Do not retry.
- status="expired": the approval timed out without a decision. Inform the user and STOP.
DECIDE MODE (decision + justification parameters): Submits a decision after the user explicitly instructs you to approve or reject.
- You MUST present the full approval context (threat type, severity, risk factors) to the user FIRST.
- You MUST wait for the user's EXPLICIT instruction (e.g., "approve it", "reject it") before calling with a decision.
- NEVER decide autonomously — always require explicit human instruction.
- High/critical severity approvals can ONLY be decided via the Shrike dashboard — the server will reject MCP-submitted decisions for these.
- Low/medium severity approvals have a 60-second cooldown after creation before decisions are accepted.
- If the server returns a 403 error, inform the user of the reason and direct them to the dashboard if needed.
IMPORTANT: Do NOT automatically poll in a loop. Approvals may take minutes to hours. Inform the user of the pending status and wait for them to ask you to check again.
ENFORCEMENT SEVERITY (agent contract): While an approval is pending, approval_context.enforcement_severity signals how your control flow should treat it:
- "blocking" — do NOT proceed with the flagged action AND do NOT proceed with any downstream work that depends on its outcome. Park the whole cascade until the decision arrives. This is set by policy for actions where dependent steps would be incorrect if executed before approval (e.g., data pipelines, cascading writes).
- "advisory" — do NOT proceed with the flagged action, but you MAY defer this task and continue with unrelated work. Come back and check_approval when the user prompts you or when a dependent step needs the decision.
Pre-launch, the default is "advisory". Policy-driven per-action severity ships post-launch.
Enterprise context: Provides the human-in-the-loop control required for compliance (GDPR Art. 22, SOC2 CC8.1). Every decision is recorded with full audit trail.
ERROR HANDLING: If this tool returns an error, inform the user. Do NOT proceed with the original action without a confirmed approval.