Approve AI Agent Actions Before They Run: The ASK Decision

Correction note (2026-10-13). An earlier version of this article gave the wrong dashboard port, used audit flags that do not exist, and described an approver identity that the audit log does not record. The dashboard listens on port 5599. If nobody answers an ASK in time, the hook falls back to the agent's own approval prompt. The init adapter ids are claude-code and copilot, not claude or vscode. The audit log records ASK decisions on a best-effort basis: an entry can be dropped if the daemon queue is full, and old rows are deleted at the row caps.

Correction note (2026-10-13). An earlier version of this article said decisions appear as system notifications on macOS and Windows. The macOS and Linux desktop shells notify when an ASK is pending, the Windows shell only pulses the tray icon, and no notification carries a decision. You answer an ASK in the dashboard or through the Discord relay.

The problem with binary approval

Every AI coding agent ships with a binary permission model: you either approve everything automatically (YOLO mode) or you sit at the keyboard approving individual keystrokes one at a time. Neither option is workable for serious development.

YOLO mode trades safety for speed. Manual approval trades speed for safety. What you actually want is something in between: most routine actions run without interruption, but high-stakes actions -- deploying to production, pushing to a protected branch, running a migration -- pause and wait for a human.

That is exactly what SSG's ASK decision does.

How ASK works

When an agent tool call matches a rule with an ASK verdict, SSG does not block the call or pass it through. Instead it routes the pending action to the approval dashboard, where a human can approve or deny it. The agent waits for the decision.

Agent queues a tool call
         |
         v
SSG evaluates the call against your rules
         |
    Rule matches: verdict ASK
         |
         v
Decision queued in the approval dashboard
         |
    Human sees the call, approves or denies
         |
         v
Agent proceeds (if approved) or sees a block message (if denied)
         |
         v
ASK evaluation recorded in audit log with timestamp

From the agent's perspective, the call either succeeds or fails. From your perspective, you saw the action before it ran and made a deliberate choice. The audit log records that the rule asked, with the rule ID and a timestamp. It does not record who answered.

A real example: deployment approval

Add to .sigmashake/rules/deployments.rules:

rule ask-before-deploy {
  enabled true
  priority 95
  severity error
  ASK execution
  IF command CONTAINS "deploy"
  OR command CONTAINS "kubectl apply"
  OR command CONTAINS "helm upgrade"
  OR command CONTAINS "terraform apply"
  MESSAGE "Deployment command requires human approval before it runs."
  PROMPT "Allow this deployment command to run?"
}

rule ask-db-migration {
  enabled true
  priority 95
  severity error
  ASK execution
  IF command CONTAINS "migrate"
  OR command CONTAINS "db:migrate"
  OR command CONTAINS "flyway migrate"
  OR command CONTAINS "alembic upgrade"
  MESSAGE "Database migration requires human approval."
  PROMPT "Allow this database migration to run?"
}

rule ask-force-push-protected {
  enabled true
  priority 90
  severity error
  ASK execution
  IF command CONTAINS "push" AND command CONTAINS "--force"
  AND command REGEX "\\s+[oO][rR][iI][gG][iI][nN]\\s+([mM][aA][iI][nN]|[mM][aA][sS][tT][eE][rR]|[rR][eE][lL][eE][aA][sS][eE]|[pP][rR][oO][dD])"
  MESSAGE "Force-push to a protected branch requires human approval."
  PROMPT "Allow this force-push to a protected branch?"
}

Pull the pre-built deployment ruleset from the Hub:

ssg hub pull rules-deployments

With these rules in place, your agent works freely through code edits, test runs, linting, and file operations. The moment it constructs a deployment command, the action pauses in the dashboard. You review the exact command, approve or deny, and the agent proceeds.

The approval dashboard

Start the dashboard with:

ssg serve

The dashboard opens at http://127.0.0.1:5599 and shows every pending ASK decision in real time over a server-sent events connection. Each pending item shows:

• The tool name and full input (the exact command string, file path, or MCP tool arguments)
• Which rule triggered the ask
• The rule's message explaining why this action needs review
• Approve and Deny buttons
• A timestamp showing when the request arrived

When you approve, the agent receives a success response and executes the action. When you deny, the agent receives the rule's block message and can course-correct.

SigmaShake Desktop embeds the same approval dashboard in its native window, so you do not need to keep a browser tab open. The macOS and Linux desktop shells raise a notification when an ASK is pending, and the Windows tray icon pulses. You make the decision in the dashboard; a notification does not offer Allow or Deny buttons.

Customizing the approval prompt

The MESSAGE field in your rule is the text the approver sees alongside the pending action. Write it to give the reviewer the context they need to make a good decision quickly:

rule ask-before-deploy {
  enabled true
  priority 95
  severity error
  ASK execution
  IF command CONTAINS "deploy"
  MESSAGE "Deployment detected. Verify: (1) tests passed, (2) correct environment, (3) no migration conflicts. Approve to proceed."
  PROMPT "Allow this deployment command to run?"
}

Good messages make approvals fast and well-informed. Bad messages ("Confirm?") push the reviewer to guess.

Approve once per session or promote to ALLOW

From the dashboard, you can approve a single instance of an action or approve that specific command for the rest of the session. Permanent allow-listing is a separate rule change: you promote it from ASK to ALLOW in your rules file after you are confident the pattern is always safe.

The graduation path -- ASK first, ALLOW after review -- is the right way to build a confident allow-list. Start by requiring approval for everything that looks risky. Once you have seen the pattern fire a dozen times and confirmed it is always safe, remove the friction.

What the audit log records for each ASK decision

On a best-effort basis, each ASK decision is written to the local SQLite audit log (an entry can be dropped if the daemon queue is full, and old rows are deleted at the row caps) with the tool, input, rule ID, and timestamp. Query ASK decisions from the command line:

# All ASK decisions in the last 24 hours
ssg audit search --decision ask --since 24h

# Everything that matched the deploy rule
ssg audit search --rule-id ask-before-deploy

# Everything the agent ran or tried to run in the last 24 hours, as JSON
ssg audit search --since 24h --json

The audit log answers: which rule asked, at what time, and what exactly was the command. If nobody answers in time, the hook does not allow the call and does not return an error. For Claude Code, the hook waits 20 seconds for a dashboard answer (the wait cannot exceed 45 seconds). Then it falls back to the agent's own approval prompt.

ASK vs DENY: when to use each

The difference is intentionality. A rule should be DENY when the action has no legitimate automated use case. A rule should be ASK when the action is sometimes legitimate and the right person to decide in context is a human watching the session.

Common ASK candidates:

• Deployments (always want a human to confirm environment and migration state)
• Force-pushes to protected branches (sometimes right after an intentional rebase)
• Database migrations (need verification that the migration is correct)
• Publishing packages to npm or PyPI (irreversible, wants human sign-off)
• Any tool call from an unrecognized MCP server

Common DENY candidates:

• Recursive force-delete outside known build directories
• Reading secret files (.env, private keys)
• Shell commands with embedded credential strings
• Privileged container launches

When in doubt, start with ASK. You can tighten to DENY once you know the pattern never has a legitimate case.

Multi-agent sessions: one dashboard, all agents

The SSG daemon governs every agent that hooks into it -- Claude Code, Cursor, Codex, VS Code Copilot -- through a single Unix socket. All ASK decisions from all agents queue in the same dashboard. One approval surface for the whole project.

Get started

# macOS / Linux — free installer
curl -fsSL https://install.sigmashake.com | sh

# Windows (PowerShell)
# iwr -useb https://install.sigmashake.com/install.ps1 | iex

# Initialize (wires the PreToolUse hook or MCP server for your agent)
ssg init --client=claude-code
# or: ssg init --client=cursor
# or: ssg init --client=copilot

# Pull the deployments ruleset
ssg hub pull rules-deployments

# Start the daemon
ssg daemon &

# Open the approval dashboard (ASK decisions queue here)
ssg serve

Links: Download · Docs · Playground · Hub