forge

Forge Verify nodes for n8n — verify every AI agent action before execution

Package Information

Downloads: 2 weekly / 155 monthly
Latest Version: 0.1.1
Author: Veritera AI

Available Nodes

Forge Verify
Verify AI agent actions against Forge policies before execution. Allowed actions pass through; denied actions are routed separately.

Documentation

n8n-nodes-forge

Forge Verify community nodes for n8n — verify every AI agent action before execution.

Overview

This package provides n8n community nodes that integrate with the Forge Verify trust layer. Every action your AI agent takes is verified against your policies before execution. Blocked actions never reach downstream nodes.

Two outputs:

  • Allowed — action passed verification, workflow continues
  • Denied — action blocked by policy (or Forge unreachable in fail-closed mode)

Every output includes proof_id, verdict, reason, and latency_ms for a complete audit trail.

Installation

Community Nodes (Recommended)

  1. Open your n8n instance
  2. Go to Settings > Community Nodes
  3. Enter n8n-nodes-forge
  4. Click Install

Manual Installation

cd ~/.n8n
npm install n8n-nodes-forge

Restart n8n after installation.

Setup

  1. In your n8n workflow, add the Forge Verify node
  2. Create a new Forge API credential:
    • API Key: Your Forge API key (starts with vt_live_ or vt_test_)
    • Base URL: https://forge.veritera.ai (default; change only for self-hosted)
  3. Configure the node properties

Node Properties

Property Type Required Default Description
Action string Yes — The action to verify (e.g. payment.create)
Parameters (JSON) JSON No {} Action parameters evaluated against policy constraints
Policy string No — Policy name to evaluate against
Agent ID string Yes n8n-workflow Identifier for audit trails and per-agent scoping
Fail Closed boolean No true Block actions when Forge is unreachable

Usage Example

Workflow: AI agent sends an email

[Trigger] → [Build Email Action] → [Forge Verify] → Allowed → [Send Email]
                                                   → Denied  → [Log Blocked Action]
  1. Your trigger fires and builds the action payload
  2. Forge Verify checks email.send against your policy
  3. If allowed: the email is sent via the next node
  4. If denied: the blocked action is logged (never sent)

Output Data

Every output item includes the original input data plus a forge object:

{
  "original_field": "value",
  "forge": {
    "proof_id": "PRF-a1b2-c3d4",
    "verification_id": "VER-e5f6-g7h8",
    "verdict": "approved",
    "verified": true,
    "action": "email.send",
    "agent_id": "n8n-workflow",
    "policy": "comms-policy",
    "reason": null,
    "latency_ms": 38,
    "mode": "dpe",
    "audit_id": "AUD-i9j0-k1l2",
    "timestamp": "2026-04-12T18:00:00.000Z",
    "evaluated_constraints": []
  }
}

Fail-Closed Behavior

When Fail Closed is enabled (default and recommended):

  • If the Forge API is unreachable, all actions route to the Denied output
  • The reason field will indicate the failure cause
  • No unverified action ever reaches downstream nodes

Disable fail-closed only if you prefer the node to throw an error (stopping the workflow) on API failures.

Links

License

MIT

Discussion