Vertex Firewall

Put a policy boundary in front of every programmable URL.

The Vertex Firewall is the security layer for Node Vertex. It controls who can read, write, signal, subscribe, drain, upload, or execute logic on a vertex. It is designed for internet-facing automation, AI agents, IoT fleets, and machine-to-machine communication where every endpoint needs explicit policy.

IP restriction

Allow or deny requests by CIDR range, fixed IP, private network, geography, or tenant-defined network zones. Public vertices can still be narrowed to trusted infrastructure.

allow: 203.0.113.0/24
deny: 0.0.0.0/0 unless signed

Identity gates

Layer API keys, bearer tokens, basic auth, tenant users, signed expiring URLs, OIDC, SAML, and node-to-node shared secrets per vertex.

Authorization: Bearer {token}
?token={signedAccessToken}

Method policy

Control which verbs are available: GET for read-only state, POST for signals, PUT for replacements, PATCH for JSON updates, DELETE for lifecycle actions.

allowed: GET, HEAD, OPTIONS
blocked: POST, PUT, PATCH, DELETE

Rate and abuse limits

Throttle public writable vertices, protect mailbox endpoints from spam, limit burst traffic, and isolate noisy tenants or devices before they affect the fabric.

Payload inspection

Enforce size limits, content types, JSON validity, schema rules, file name sanitization, hash verification, and future signed payload verification.

Lifecycle enforcement

TTL, read-once, write-once, append-only, immutable operation results, revocation, disabled states, and logical deletion become security controls.

Zero-trust vertex policy

Do not expose another webhook receiver without a firewall.

Webhook endpoints and agent tools are often public by necessity. Vertex Firewall makes that exposure explicit, narrow, observable, and revocable. Every vertex can have its own network, identity, verb, payload, TTL, and audit policy.

Example policy

{
  "vertex": "/acme/build-status",
  "read": "tenant-users OR signed-token",
  "write": "api-key AND ip:203.0.113.0/24",
  "methods": ["GET", "POST"],
  "ttlMinutes": 1440,
  "maxPayloadKb": 64,
  "contentTypes": ["application/json"],
  "audit": "write-and-auth-failures"
}

Firewall capability model

Capability	Purpose	Examples
IP allowlist / denylist	Network-level access control	Office CIDR, cloud NAT, device fleet ranges
Auth composition	Require multiple controls	API key + IP, OIDC + signed token
Rate limits	Stop abuse and noisy clients	100 writes/minute, 10MB/day egress
Payload rules	Validate data before storage or signal	JSON schema, max size, allowed MIME types
Replay protection	Prevent repeated signed requests	Nonce, timestamp, max uses
Audit evidence	Prove what happened	Payload hashes, auth failures, actor metadata