n8n Safety Gate – Drop-In Workflow (Complete Guide)

[← Back to Docs](/docs)

This guide is for teams who already use n8n and want a production-ready Safety Gate workflow.

n8n is optional. If you are not using n8n, use the HTTP API instead.

How It Works (end-to-end)

This section describes the exact production flow implemented by the drop-in workflow.

Step 1 — Your workflow produces AI output

An upstream node (LLM/agent) produces the final AI output you intend to use to trigger a real-world action.

Step 2 — The workflow calls the Safety Gate

The workflow sends the AI output and context to:

• POST https://aisafegate.com/api/validate

Step 3 — The workflow enforces the decision

#### If status is PASS

The workflow continues directly to your downstream action nodes.

#### If status is BLOCK

The workflow stops immediately.

#### If status is WARN

The workflow pauses and enters a polling loop.

The WARN response includes:

• decision_id
• approval_token

The workflow persists both values and polls for approval.

Step 4 — Human approval (WARN only)

The workflow polls:

• GET https://aisafegate.com/api/decisions/:id/approval (provide token via header: X-Approval-Token: <approval_token>)

until either:

• it receives { "approved": true } and continues, or
• its built-in timeout/maximum poll count is reached and it stops.

Step 5 — Fail closed on errors and timeouts

The workflow is designed so that failures do not become execution:

• Missing/invalid responses, missing approval parameters, or malformed approval responses stop the workflow.
• Approval polling treats { "approved": false } as “not approved yet” (or “could not be safely evaluated”) and never as approval.
• If approval is not observed in time, the workflow stops instead of executing.

Clarification — n8n is optional

This workflow is a convenience integration.

If you do not use n8n, you can integrate directly via HTTP using the same contract (POST https://aisafegate.com/api/validate and, for WARN, GET https://aisafegate.com/api/decisions/:id/approval with X-Approval-Token: <approval_token>).

Policy Coverage & Enforcement

All policy enforcement is handled by the **n8n Safety Gate Drop-In workflow**.

You must not re-implement policy logic in your own downstream nodes. The Safety Gate workflow is authoritative and **fail-closed** by design.

⚠️ context.actionKind is REQUIRED

**context.actionKind is REQUIRED.** Requests missing actionKind are immediately **BLOCKED** (fail-closed).

Valid:

{
  "context": {
    "actionKind": "money.refund"
  }
}

Invalid:

{
  "context": {}
}

Minimal ASG Payload (n8n)

You only need to send:

• ai_output
• context

You must not include unused policy fields.

ASG scopes validation by context.actionKind:

• For non-monetary actions (messaging.*, data.*, identity.*, workflow.*, infra.*, security.*, support.*), billing is not evaluated.
• For money.* actions only, billing/usage enforcement is evaluated.

Example minimal payload:

{
  "ai_output": {
    "email": "..."
  },
  "context": {
    "actionKind": "messaging.send",
    "message_type": "email",
    "recipient_count": 1,
    "workflow_name": "email-auto-reply",
    "source": "n8n",
    "enforcement_mode": "strict",
    "fail_closed": true
  }
}

Action-Scoped Billing Isolation

ASG evaluates billing/usage enforcement **only** for actions where:

context.actionKind starts with money.

For all other action kinds (messaging.*, data.*, identity.*, workflow.*, etc.):

• ASG does not run billing validation
• ASG does not consume usage
• Billing-shaped fields (e.g. amount_usd, currency, transaction_id, invoice_id, or billing) are ignored safely
• Billing-related errors are impossible

This means customers never need to guess or include billing fields for non-money actions.

Safety Gate Outcomes

A WARN outcome never executes automatically.

Execution resumes only after human approval tied to the same decision_id.

Human Approval Flow (WARN)

1. The Safety Gate returns WARN with a decision_id.

2. Execution pauses automatically.

3. Approval is requested and polled securely.

4. Approval must:

- Match the same decision_id

- Return approved: true

5. Execution resumes or fails closed.

execution_authorized

execution_authorized is a boolean flag.

It is set only when:

• The Safety Gate returns PASS, or
• The Safety Gate returns WARN and approval is granted

Downstream execution must not proceed unless this flag is true.

Fail-Closed Behavior

The Safety Gate system is fail-closed by design.

Any unexpected condition results in immediate execution stop.

Examples:

• Missing actionKind
• Invalid Safety Gate response
• Approval timeout
• Decision ID mismatch
• Missing approval token

A. What this workflow is

The Safety Gate concept

AI Safety Gate is an enforcement layer that sits between **AI output** and **real-world execution**.

In n8n terms: put the Safety Gate between your LLM/agent node and anything that creates side effects (sending messages, updating systems of record, calling payment/fulfillment APIs, writing to your data stores).

Why PASS / WARN / BLOCK exist

The Safety Gate returns one of three enforcement outcomes:

• PASS: safe to proceed.
• BLOCK: not safe to proceed; stop immediately.
• WARN: ambiguous/borderline; execution is paused until a human explicitly approves.

Why WARN requires human approval

WARN exists for cases where the system must not guess.

In production systems, “probably safe” is not sufficient—especially when AI output can trigger irreversible actions. WARN forces human review and prevents silent unsafe execution.

What problems this solves in real systems

• Prevents accidental execution of policy-violating content.
• Prevents AI from triggering irreversible side effects during outages or misconfigurations.
• Provides a human review path (WARN) without you building a separate approval system.

B. When to use this workflow

Use the workflow when AI output is being used to:

• **LLM outputs**: emails, chat messages, summaries, recommended next steps.
• **User-generated content**: anything untrusted that will be published or executed.
• **Automated pipelines**: automations that write to external systems.

When NOT to use it

Do not use this workflow:

• For purely non-executing analysis where there are no side effects.
• As a client-side control (do not put API keys in browsers/mobile apps).
• As a substitute for authentication/authorization of the underlying action. The Safety Gate is an enforcement decision, not an identity system.

C. Step-by-step walkthrough (safe, production-ready)

1) Import the workflow

1. Open n8n.

2. Go to **Workflows**.

3. Choose **Import from File**.

4. Select:

- n8n-nodes-ai-safety-gate/ai-safety-gate-workflow.json

2) Add your API key (required)

Create an **HTTP Header Auth** credential in n8n with:

• Header name: Authorization
• Header value: Bearer <YOUR_AI_SAFETY_GATE_API_KEY>

Attach it to:

• AI Safety Gate1
• Poll Approval

3) Confirm the production base URL

The workflow should call:

• https://aisafegate.com/api/validate
• https://aisafegate.com/api/decisions/.../approval

4) Connect your AI output

Feed your AI output into the workflow so it becomes the ai_output value that is validated.

5) Connect the next step (side effect)

Connect your irreversible step (send message, publish, update record, etc.) to the workflow’s PASS path.

6) Run safely

Run the workflow and verify:

• PASS continues to your next step
• WARN pauses until approval is confirmed
• BLOCK stops

D. Zero-mistake change rules

DO NOT CHANGE

SAFE TO CHANGE