Connect your AI Node

The Vrymdor AI Node is a checkpoint that runs inside your own network, in front of your AI agents and the tools they use. n8n, Make, Zapier, LangChain, LlamaIndex, Claude Desktop, IDEs (integrated development environments) and your own code all call the node the same way, and every call gets the same protection:

1. The agent's identity and status are checked (a stopped or expired agent is refused).
2. Your policy decides whether the action is allowed for the agent's role.
3. PII (personally identifiable information, such as email addresses and card numbers) and secrets (such as API keys, where API means application programming interface) are replaced with [REDACTED:<TYPE>] before anything leaves, and again on the way back.
4. The request is signed and a metadata-only audit record is written. Prompts and payloads stay in your network.

The node never runs code it is sent. It runs one allowed action (remove PII, run a tool, call a model or send a webhook) against a destination you configured.

This guide takes you from a new account to a first governed call on each platform. Every command and response below matches the current product.

Before you start

You need an AI Node account. Create one at https://app.vrymdor.com/node/start. Community is free; Pro and Business are paid monthly; Enterprise is a custom contract. After you sign up you get an activation email: open the link, sign the service agreements, and set your password. Your workspace is then at https://app.vrymdor.com/app.

Community is a hard cap: at 10,000 requests in a calendar month (UTC, Coordinated Universal Time) the node answers with HTTP (Hypertext Transfer Protocol) status 402 and the code quota_exhausted until the month resets or you upgrade. Paid plans are never blocked for volume. One request is one call the node evaluated, whatever the decision; calls refused for a bad credential, a plan limit or a rate limit do not count.

You also need Docker (for the Docker and Docker Compose options), or a Kubernetes cluster with Helm 3 or Helm 4 (for the Helm option), on a machine inside your network.

Step 1: get your credentials

There are two kinds of credential. Keep both like passwords.

The gateway URL (uniform resource locator, the web address) that platforms use is your node's own address as that platform can reach it, for example http://vrymdor-node:8080 inside Docker or https://ai-gateway.example.com behind your reverse proxy. The node listens on port 8080.

Get your node token

1. Sign in at https://app.vrymdor.com/app. AI Node accounts open on the Home base tab.
2. Find the Connect your node card. Its badge reads Waiting for node until a node reports in.
3. Select Show my node token. A workspace admin can do this. The token is filled into the Docker, Docker Compose and Helm commands on the card, each with a Copy button (copy buttons work in the web app; in the phone app, select the text). The card's MCP entry and its n8n, Make and Zapier entry never use the node token: they take an agent's credentials (next section).

The card also shows your Workspace id. Only an air-gapped node needs it (Option D); a connected node looks it up by itself.

Register an agent for each platform

1. Open the AI agents tab.
2. In Register an agent, fill in Name (for example n8n production), Role (lowercase, as in your policy) (for example devops), Owner email (the person accountable for the agent) and Valid for (days) (90 or less).
3. Select Register. The app shows the agent id and its secret once: "Agent agt.... Its secret, shown only now: vrymagent_.... Put it in the agent's configuration; Vrymdor keeps only a hash of it." Copy both now.

Use one agent per platform connection. Stopping an agent on the AI agents tab ends every token it holds at once, without touching your other agents.

Step 2: run your node

Pick one option. In every option the node registers with your workspace on start, and the Connect your node badge changes from Waiting for node to Connected and active within about a minute (the node reports every 60 seconds). If reports stop for three minutes the badge reads Node offline.

Not yet on Docker Hub. The image vrymdor/node-proxy is being published. Until it is, Vrymnox support provides it as a file, vrymdor-node-proxy.tar, with its checksum file vrymdor-node-proxy.tar.sha256. On the machine that runs the node, check and load it with the two commands below (on macOS, check it with shasum -a 256 -c vrymdor-node-proxy.tar.sha256). The file carries the image under two tags, vrymdor/node-proxy:1.0.0 (what Docker Compose and the Helm chart run) and vrymdor/node-proxy:latest (what the docker run commands below run), so every option finds it. (Remove this note and the two commands below it once the image is on Docker Hub.)

sha256sum -c vrymdor-node-proxy.tar.sha256     # prints: vrymdor-node-proxy.tar: OK
docker load -i vrymdor-node-proxy.tar

Option A: Docker

1. Start the node with your node token:

docker run -d --name vrymdor-node -p 127.0.0.1:8080:8080 \
  -v vrymdor-node-data:/data \
  -e VRYMDOR_NODE_TOKEN=vrym_live_... \
  vrymdor/node-proxy:latest

VRYMDOR_NODE_TOKEN is the only required setting. The node then contacts https://api.vrymdor.com (outbound only, over HTTPS, the encrypted form of HTTP; nothing needs to reach the node from the internet). The vrymdor-node-data volume keeps the node's signing key, admin token and audit across restarts.

-p 127.0.0.1:8080:8080 makes the node reachable only from this machine, which is the safe choice for a first test. When other machines, or other containers such as n8n or the MCP bridge on Linux, must reach it, use -p 8080:8080 instead, and limit who can reach port 8080 with your firewall.

Because of -d the container runs in the background, so its messages, including the Activate License message described below, are in docker logs vrymdor-node.

1. Check it is healthy:

curl -s http://127.0.0.1:8080/healthz

A ready node answers {"status":"ready","checks":{"redaction_engine":true,"token_key":true,"signing_key":true,"state_store":true,"audit_writable":true},...,"fail_mode":"FAIL_CLOSED"}. docker ps also shows the container as healthy after its first health check.

1. Watch the Connect your node card switch to Connected and active.

1. Optional: tell the node where agents may go. Without this, only Remove PII and secrets and the policy checks work. Add the destinations as JSON (JavaScript Object Notation) in VRYMNOX_UPSTREAMS, with the API keys in their own variables (the node holds the keys; platforms and agents never see them). Remove the first container first (the vrymdor-node-data volume keeps the keys), then start it again with the new settings:

docker rm -f vrymdor-node
docker run -d --name vrymdor-node -p 127.0.0.1:8080:8080 \
  -v vrymdor-node-data:/data \
  -e VRYMDOR_NODE_TOKEN=vrym_live_... \
  -e VRYMNOX_UPSTREAMS='{"anthropic":{"url":"https://api.anthropic.com","kind":"llm","auth_header":"x-api-key","auth_env":"ANTHROPIC_API_KEY"},"github":{"url":"https://mcp.example.com/github","kind":"mcp"},"hooks":{"url":"https://hooks.example.com/vrymdor","kind":"webhook"}}' \
  -e ANTHROPIC_API_KEY=sk-ant-... \
  vrymdor/node-proxy:latest

kind is llm (a model API), mcp (an MCP server), webhook, websocket or grpc. The name before each object (anthropic, github, hooks) is the Upstream you enter in each platform.

1. Find the admin token for the node's local admin API (used in Step 3):

docker exec vrymdor-node cat /data/admin.token

What the Activate License message means. If the container starts without a node token, it prints the message below and stops with exit code 2 (with -d, read it with docker logs vrymdor-node). Follow the link to create a free Community account, then copy your token from Connect your node, remove the stopped container with docker rm vrymdor-node, and run the command again.

Vrymdor AI Node: no node token yet.

  Activate License: https://app.vrymdor.com/node/start?plan=node_community

Option B: Docker Compose

Use this to run the node with its own Redis (needed for more than one node replica) on one host. The package folder holds docker-compose.yml and .env.example.

Not yet published. Until the image is on Docker Hub, support provides the package folder and the image file. Load the image first (see the note at the start of Step 2). The compose file runs vrymdor/node-proxy:1.0.0 unless .env sets VRYMNOX_GATEWAY_VERSION; without that image on the machine, docker compose up -d stops with "failed to read dockerfile" (the package folder has no Dockerfile to build from). If your image file has only the latest tag, either tag it with docker tag vrymdor/node-proxy:latest vrymdor/node-proxy:1.0.0, or put VRYMNOX_GATEWAY_VERSION=latest in .env. (Remove this note after publishing.)

1. In the package folder, copy the settings file and open it:

cp .env.example .env
nano .env

1. Set your token. This is the only line you must fill in:

VRYMDOR_NODE_TOKEN=vrym_live_...

Optional lines in the same file: VRYMNOX_CONTROL_PLANE_URL (default https://api.vrymdor.com), VRYMNOX_GATEWAY_VERSION (the image tag, default 1.0.0), VRYMNOX_UPSTREAMS and the API keys it names (see Option A, step 4), and VRYMNOX_AUDIT_RETENTION_DAYS (183 in the example, which meets the EU (European Union) AI Act six-month log duty for high-risk deployers). Leave VRYMNOX_SIGNING_KEY and VRYMNOX_ADMIN_TOKEN unset and the node generates them into its data volume.

1. Start it:

docker compose up -d

1. Check it is ready:

docker compose exec gateway python -c "import urllib.request;print(urllib.request.urlopen('http://127.0.0.1:8080/healthz').read().decode())"

1. Find the admin token for the node's local admin API (used in Step 3):

docker compose exec gateway cat /data/admin.token

The compose file keeps the node on an internal Docker network named vrymnox-gateway_agents and does not publish a port, so only containers on that network can call it, at http://gateway:8080. To reach it from the host or other machines, add a docker-compose.override.yml beside it (127.0.0.1:8080:8080 keeps it to the host; 8080:8080 opens it to other machines, as in Option A):

services:
  gateway:
    ports: ["127.0.0.1:8080:8080"]

Option C: Helm, Kubernetes or OpenShift

The chart is vrymdor-node. It runs the node as a non-root user (user id 10002) with a read-only root filesystem, every Linux capability dropped, liveness and readiness probes on /healthz, and a Secret that holds your node token.

Not yet in a public chart repository. Until it is, support provides the chart as a folder (vrymdor-node) or a file (vrymdor-node-1.0.0.tgz); use that path in place of ./vrymdor-node below. The chart runs the image vrymdor/node-proxy:1.0.0, which is not on Docker Hub yet either, so give your cluster the image from the support file (see the note at the start of Step 2) in one of two ways: - Push it to a registry your cluster can pull from and point the chart at it: docker tag vrymdor/node-proxy:1.0.0 registry.example.com/vrymdor/node-proxy:1.0.0, docker push registry.example.com/vrymdor/node-proxy:1.0.0, then add --set image.repository=registry.example.com/vrymdor/node-proxy to the helm install command. - Or import it on every Kubernetes node that may run the pod: sudo ctr -n k8s.io images import vrymdor-node-proxy.tar (containerd; on k3s, sudo k3s ctr images import vrymdor-node-proxy.tar), or, on a kind test cluster, after docker load, kind load docker-image vrymdor/node-proxy:1.0.0. (Remove this note after the chart and the image are published.)

1. Install with your node token:

helm install vrymdor-node ./vrymdor-node --set nodeKey=vrym_live_...

To keep the token out of your shell history, create the Secret yourself and point the chart at it:

kubectl create secret generic vrymdor-node-token --from-literal=VRYMDOR_NODE_TOKEN=vrym_live_...
helm install vrymdor-node ./vrymdor-node --set existingSecret=vrymdor-node-token

1. Verify. The port-forward command keeps running and holds the terminal, so run curl in a second terminal:

kubectl get pods -l app.kubernetes.io/name=vrymdor-node
kubectl port-forward svc/vrymdor-node 8080:8080

curl -s http://127.0.0.1:8080/healthz          # in a second terminal

Stop the port forward with Ctrl+C when you are done. Inside the cluster, platforms call http://vrymdor-node.<namespace>.svc:8080. The admin token for Step 3 is in the pod: kubectl exec deploy/vrymdor-node -- cat /data/admin.token.

The values you can set:

An install that cannot start is refused with the fix in the message, for example "set nodeKey (your node token from Connect your node in the Vrymdor app) or existingSecret".

Option D: air-gapped (Enterprise)

Air-gapped mode is for a network with no route to the internet. Set VRYMDOR_AIR_GAPPED=1 and the node never contacts Vrymdor: no registry sync, no reports, no telemetry. Because it cannot fetch your agents, it reads them from a file. The Connect your node card stays at Waiting for node for an air-gapped node, because it never reports.

An Enterprise air-gapped install is arranged with Vrymnox. Vrymnox support provides the node image as the file vrymdor-node-proxy.tar with its checksum file vrymdor-node-proxy.tar.sha256, on a USB (Universal Serial Bus) drive, and prepares the agents file with you; the agent secrets themselves are never on the drive. On the server:

1. Check and load the image from the drive:

sha256sum -c vrymdor-node-proxy.tar.sha256     # prints: vrymdor-node-proxy.tar: OK
docker load -i vrymdor-node-proxy.tar          # loads vrymdor/node-proxy:1.0.0 and :latest

1. Put the agents file and your policy in a folder, for example /opt/vrymdor/node. The agents file is a JSON list; each agent has agent_id, name, role, owner_email, expires_at (a date and time in ISO 8601, the international standard format, for example 2027-01-31T00:00:00Z) and secret_sha256 (the hex digest of the agent secret under SHA-256, the Secure Hash Algorithm with a 256-bit digest).
2. Start the node. VRYMNOX_TENANT_ID is your Workspace id, shown on the Connect your node card (Vrymnox support also has it):

docker run -d --name vrymdor-node -p 127.0.0.1:8080:8080 -v vrymdor-node-data:/data \
  -v /opt/vrymdor/node:/etc/vrymdor:ro \
  -e VRYMDOR_AIR_GAPPED=1 \
  -e VRYMNOX_TENANT_ID=<your workspace id> \
  -e VRYMNOX_AGENTS_FILE=/etc/vrymdor/agents.json \
  -e VRYMNOX_POLICY_FILE=/etc/vrymdor/vrymnox-policy.yaml \
  vrymdor/node-proxy:latest

1. Check curl -s http://127.0.0.1:8080/healthz answers "status":"ready". As in Option A, use -p 8080:8080 when other machines must reach the node.

Starting air-gapped without a tenant id is refused. With a node token set, docker logs vrymdor-node shows "Vrymnox gateway cannot start: air-gapped mode (VRYMDORAIRGAPPED) needs VRYMNOXTENANTID, and the agents in VRYMNOXAGENTSFILE, because the gateway never talks to the control plane". With neither a token nor a tenant id, the node shows the Activate License message (Option A) instead, because it checks for those first.

With Helm, set airGapped=true, tenantId and the agents. A JSON list cannot go through --set (Helm splits the value at its commas), so pass the agents file with --set-file, or name a Secret you manage that holds it under the key agents.json:

helm install vrymdor-node ./vrymdor-node --set airGapped=true --set tenantId=<your workspace id> \
  --set-file airGappedAgents=agents.json
# or keep the agents in a Secret you manage:
kubectl create secret generic vrymdor-node-agents --from-file=agents.json
helm install vrymdor-node ./vrymdor-node --set airGapped=true --set tenantId=<your workspace id> \
  --set airGappedAgentsSecret=vrymdor-node-agents

The chart refuses an air-gapped install without a tenant id ("airGapped needs tenantId (the node never asks the cloud which tenant it serves)") or without agents ("airGapped needs airGappedAgents (a JSON list) or airGappedAgentsSecret").

The separate offline USB kit for Vrymdor Business Security servers is described in the onboarding guide; it installs the security connector, not the AI Node.

Step 3: set your policy

The policy decides which roles may use which upstreams and tools, and which tools wait for a person. Set it before you connect platforms that run tools: a tool call is refused with tool_not_allowed until the policy lists the tool for the agent's role. Removing PII works without a policy, and so do model calls and webhooks until a role limits its upstreams (a role with an upstreams list reaches only those).

1. Start from the example in the package, vrymnox-policy.example.yaml, and keep your copy as vrymnox-policy.yaml in your own repository. A small policy:

version: 1
roles:
  devops:
    upstreams: [github, hooks, anthropic]   # the upstreams this role may reach
mcp:
  tools:
    - name: create_issue
      upstream: github
      roles: [devops]
      input_schema:                  # the tool's arguments are checked against this
        type: object
        required: [title]
        properties:
          title: {type: string, maxLength: 200}
    - name: delete_branch
      upstream: github
      roles: [devops]
      require_approval: true         # every call waits for a person

The example file also shows redaction (your own patterns and literal terms), injection (flag or block prompt injection markers) and defaults (rate limits and token lifetime).

1. Check it without starting anything:

docker run --rm -v "$PWD":/w:ro vrymdor/node-proxy:latest policy-check /w/vrymnox-policy.yaml

A valid file prints Policy valid. sha256 <hex>, 2 tool(s), 14 detector(s).; an invalid one prints Policy rejected: <reason> and exits 1, so you can run it in CI (continuous integration).

1. Apply it to the node with the admin token from Step 2. On the machine that runs the node with Option A:

GW=http://127.0.0.1:8080
ADMIN_TOKEN=$(docker exec vrymdor-node cat /data/admin.token)
curl -X POST --data-binary @vrymnox-policy.yaml -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H 'Content-Type: application/yaml' "$GW/api/v1/policies/import"

With Option B or C, get the admin token as shown there, and set GW to an address where you reach the node. The answer is {"status":"applied","policy_sha256":"<hex>","tools":2}. The node saves the policy in its data volume, so it also survives a restart.

If your workspace also stores a policy, the workspace policy wins at the next full sync. The node asks for your registry every 5 seconds, and while nothing changed the answer is a short "not modified" (HTTP 304), so a policy you imported locally stays in force until your workspace registry changes (an agent is registered, stopped, released or extended, the plan changes, or the workspace policy changes) or the node restarts. Then the workspace policy replaces it. Use one place for your policy.

Holds and approvals. A tool with require_approval: true answers HTTP 202 with "decision":"hold" and a hold_id. The person approving sees the agent's stated intent beside the exact request. The agent states it with the X-Vrymnox-Intent header (up to 500 characters) or, in a node request, as "context": {"intent": "..."} (up to 200 characters; the header wins when both are sent). From the Python client: node.tool("github", "delete_branch", {...}, context={"intent": "..."}). Approve or reject on the node, inside your network, so the request never leaves it:

curl -s -H "Authorization: Bearer $ADMIN_TOKEN" "$GW/api/v1/holds"
curl -s -X POST -H "Authorization: Bearer $ADMIN_TOKEN" "$GW/api/v1/holds/<hold_id>/approve"   # or /reject

The caller then gets the result from GET $GW/v1/node/holds/<hold_id> (202 while waiting; the final answer once, then it is forgotten). A rejected hold answers with the code rejected_by_reviewer; a hold nobody decides is rejected after hold_timeout_seconds (900 by default) with approval_expired. The AI agents tab shows how many requests are waiting for approval in total across your nodes.

Where decisions show up. Every decision is in the node's hash-chained audit (in /data/audit). The AI agents tab shows each node's report (counts and readiness, never payloads) and every agent's state, and Home base shows this month's requests against your plan.

Step 4: connect your platform

Every platform below needs three values from Step 1: the gateway URL (your node), an Agent ID and an Agent Secret. The examples use an agent with the role devops, an upstream named github that offers the tool create_issue, an upstream named anthropic and a webhook upstream named hooks, as set in Step 2 (Option A, step 4) and Step 3. Replace them with the names in your node's settings and policy. Every tool example needs the tool in your policy (Step 3); without it the call is refused with tool_not_allowed.

n8n

The community node is n8n-nodes-vrymnox. It adds the credential Vrymnox Agent API and the node Vrymnox, which n8n also offers as an AI agent tool. For the AI agent tool, start the n8n instance with N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE=true; n8n offers community nodes as tools only with that setting.

Not yet on npm. Until it is, self-hosted n8n can load the package file from support: unpack n8n-nodes-vrymnox-1.0.0.tgz into a folder, rename the unpacked package folder to n8n-nodes-vrymnox, and start n8n with N8N_CUSTOM_EXTENSIONS set to the folder that contains it. (Remove this note once the package is on npm.)

1. In n8n, open Settings, Community Nodes, Install, enter n8n-nodes-vrymnox, accept the risk notice and install.
2. Create the credential: Credentials, Add credential, search Vrymnox Agent API, and fill in:
3. Gateway URL: your node as n8n reaches it, for example http://vrymdor-node:8080 (default http://vrymnox-gateway:8080).
4. Agent ID: agt_...
5. Agent Secret: vrym_agent_...

Save. n8n tests the credential by exchanging it at your node's /v1/token. n8n then keeps the short-lived access token from /v1/token in the credential and exchanges the secret again whenever the node answers that the token expired, so you never handle tokens yourself.

1. Add the Vrymnox node to a workflow and choose its credential.
2. Choose an Operation. The fields shown depend on it:

Input defaults to the incoming item ({{ $json }}); it also accepts JSON text.

1. First test: set Operation to Remove PII and Secrets and Input to {"note": "mail [email protected], card 4111 1111 1111 1111"}, then select Execute step. The output item has "ok": true, "decision": "allow" and "output": {"note": "mail [REDACTED:EMAIL], card [REDACTED:CREDIT_CARD]"}.

How it behaves:

• Wait for Approval (on by default, 1 to 60 minutes, default 15): when a tool needs a person's approval, the node checks every 5 seconds until it is decided or the time runs out. Off, the step returns at once with "decision": "hold" and a hold_id.
• A refusal stops the workflow with an error such as Vrymnox tool_not_allowed: Tool drop_db is not on the allowlist. In the node's Settings, set On Error to Continue to get the refusal as an item with an error field on the normal output instead, or to Continue (using error output) to send that item to the node's separate error output.
• Each step sends an idempotency key made from the execution, node and item, so an n8n retry never runs an action twice.

Make

The Make custom app has one connection and one module, Run a governed action.

Not yet public in Make. Until Make approves the listing, Vrymnox can invite your Make organization to the app. (Remove this note once the app is public.)

1. In a scenario, add the Vrymnox AI Node app and the module Run a governed action.
2. Create a connection with:
3. Gateway URL: your node as Make's cloud can reach it, with no trailing slash, for example https://ai-gateway.example.com. Make runs in the cloud, so the node must be reachable over HTTPS from the internet (for example behind your reverse proxy).
4. Agent ID: agt_...
5. Agent secret: vrym_agent_...

A wrong credential shows "The gateway refused this agent's credential."

1. Fill in the module:

1. First test: Action Remove PII and secrets, Input mail [email protected], then Run once. The output shows decision allow and output mail [REDACTED:EMAIL].

The module's outputs are ok, decision, output, redactions, rules, hold_id, error and audit. A refusal shows as an error such as Vrymnox tool_not_allowed: .... A held action returns decision hold and a hold_id; the module does not wait.

Zapier (Webhooks by Zapier)

Zapier uses two Webhooks by Zapier steps: one exchanges the agent secret for a short-lived access token, the next sends the action. The node must be reachable over HTTPS from the internet.

1. Add a step: Webhooks by Zapier, event POST.
2. URL: https://ai-gateway.example.com/v1/token
3. Payload Type: json
4. Data: agent_id = agt_... and agent_secret = vrym_agent_...

Test it. The result has access_token, token_type (Bearer) and expires_in (600 seconds by default).

1. Add a second step: Webhooks by Zapier, event Custom Request.
2. Method: POST
3. URL: https://ai-gateway.example.com/v1/node/run
4. Headers: Authorization = Bearer followed by the Access Token from step 1, and Content-Type = application/json
5. Data:

{"action": {"type": "sanitize"}, "input": "Customer [email protected] paid with 4111 1111 1111 1111",
 "context": {"platform": "zapier", "workflow": "zap-42"}}

Map fields from earlier steps into input. A mapped value inside quotes must not contain an unescaped double quote; for free text, a Code by Zapier step that builds the JSON is safer.

1. Test it. The answer has "decision": "allow" and "output": "Customer [REDACTED:EMAIL] paid with [REDACTED:CREDIT_CARD]". Map output into the next step.

For a tool that your policy lists (Step 3), change Data to {"action": {"type": "tool", "upstream": "github", "tool": "create_issue"}, "input": {"title": "..."}}.

LangChain, LlamaIndex and Python

The Python client is the package vrymdor-node (module vrymnox_node, one dependency: httpx). The LangChain extra needs langchain-core 0.3.49 or newer, the first version that accepts the tools' JSON Schemas as they are.

Not yet on PyPI. Until it is, install the wheel file from support: pip install vrymdor_node-1.0.0-py3-none-any.whl. (Remove this note once the package is on PyPI.)

1. Install:

pip install vrymdor-node                  # the client
pip install "vrymdor-node[langchain]"     # plus LangChain
pip install "vrymdor-node[llamaindex]"    # plus LlamaIndex

1. Call the node. sanitize, llm and webhook work before you set a policy; tool needs the tool in your policy (Step 3):

from vrymnox_node import VrymnoxError, VrymnoxHeld, VrymnoxNode

node = VrymnoxNode("http://vrymdor-node:8080", agent_id="agt_...", agent_secret="vrym_agent_...")

print(node.sanitize("Customer [email protected] called"))       # Customer [REDACTED:EMAIL] called
node.tool("github", "create_issue", {"title": "Login fails"})
node.llm("anthropic", "v1/messages", {"model": "claude-...", "max_tokens": 200,
                                       "messages": [{"role": "user", "content": "Hello"}]})
node.webhook("hooks", {"customer": "[email protected]"})

try:
    node.tool("github", "drop_db", {})
except VrymnoxHeld as held:
    print(node.wait_for(held.hold_id))      # waits until a person decides (default up to 15 minutes)
except VrymnoxError as err:
    print(err.code, err.retryable)          # tool_not_allowed False

1. Give an agent framework only the tools your policy allows:

tools = node.langchain_tools()      # one LangChain StructuredTool per allowed tool, named github__create_issue
tools = node.llamaindex_tools()     # the same, as LlamaIndex FunctionTools with each tool's input schema

The client exchanges the secret for a token and renews it a minute before it expires. Every call is governed like any other: a tool the role may not use is not in the list at all.

Claude Desktop, Cursor, VS Code and other MCP clients

The node is an MCP server. Its tool list shows vrymnox_sanitize, vrymnox_check (dry run), vrymnox_hold_status, vrymnox_llm (when a model upstream is configured) and every tool your policy allows for the agent's role, named <upstream>__<tool>, for example github__create_issue.

What the node protects here. Text you type into Claude Desktop or an IDE chat goes to that client's model provider before any tool runs, so the node cannot remove PII from your prompt. It protects what the tools send and receive: the arguments a tool call carries and the answer that comes back. Try it with test data, for example "use vrymnox_sanitize on: mail [email protected]", never with real personal data.

Desktop clients and IDEs start a local command, so they use the stdio (standard input and output) bridge, which runs from the node image and renews the agent's token by itself. It needs Docker on the computer running the client. Use http://host.docker.internal:8080 when the node runs on the same computer (Docker Desktop on macOS and Windows), or your node's address otherwise. With Docker Engine on Linux, host.docker.internal is not defined: add "--add-host=host.docker.internal:host-gateway" to args before the image name, and publish the node's port on an address the containers can reach (-p 8080:8080 does; -p 127.0.0.1:8080:8080 does not).

Claude Desktop. Open Settings, Developer, Edit Config, or edit the file directly: ~/Library/Application Support/Claude/claude_desktop_config.json on macOS, and %APPDATA%\Claude\claude_desktop_config.json on Windows. Add:

{
  "mcpServers": {
    "vrymdor": {
      "command": "docker",
      "args": ["run", "-i", "--rm",
               "-e", "VRYMNOX_NODE_URL", "-e", "VRYMNOX_AGENT_ID", "-e", "VRYMNOX_AGENT_SECRET",
               "vrymdor/node-proxy:latest", "mcp-stdio"],
      "env": {
        "VRYMNOX_NODE_URL": "http://host.docker.internal:8080",
        "VRYMNOX_AGENT_ID": "agt_...",
        "VRYMNOX_AGENT_SECRET": "vrym_agent_..."
      }
    }
  }
}

Restart Claude Desktop. The Vrymdor tools appear in the tools menu. Ask it to "use vrymnox_sanitize on: mail [email protected]" and the tool answers "mail [REDACTED:EMAIL]" (the output as JSON, so a text answer comes back in quotes).

Cursor. Put the same mcpServers block in ~/.cursor/mcp.json (all projects) or .cursor/mcp.json in a project.

VS Code. In .vscode/mcp.json, the key is servers and each server names its type:

{
  "servers": {
    "vrymdor": {
      "type": "stdio",
      "command": "docker",
      "args": ["run", "-i", "--rm", "-e", "VRYMNOX_NODE_URL", "-e", "VRYMNOX_AGENT_ID", "-e", "VRYMNOX_AGENT_SECRET",
               "vrymdor/node-proxy:latest", "mcp-stdio"],
      "env": {"VRYMNOX_NODE_URL": "http://host.docker.internal:8080", "VRYMNOX_AGENT_ID": "agt_...",
              "VRYMNOX_AGENT_SECRET": "vrym_agent_..."}
    }
  }
}

If Python can import the node's package on that computer (for example on the node's own server), the command can be python with the arguments -m vrymnox_gateway mcp-stdio and the same three variables.

MCP over HTTP. POST /mcp speaks MCP over streamable HTTP (JSON responses; protocol versions 2025-11-25, 2025-06-18, 2025-03-26 and 2024-11-05). Every request needs Authorization: Bearer <token> from /v1/token, and that token lasts 600 seconds by default, so use /mcp directly from code that can fetch a fresh token, and the stdio bridge for desktop clients:

curl -s -X POST "$GW/mcp" -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

GitHub Actions

This step removes PII and secrets from a pull request description. The node must be reachable from the runner: a public HTTPS address, or a self-hosted runner inside your network. Add three repository secrets (Settings, Secrets and variables, Actions): VRYMDOR_NODE_URL, VRYMDOR_AGENT_ID and VRYMDOR_AGENT_SECRET.

GitHub gives no repository secrets to a pull_request run from a fork, so this workflow works for pull requests from branches of the same repository; on a pull request from a fork the token request fails, and so does the step. Do not switch to pull_request_target to get the secrets for forks if the job checks out or runs the pull request's code: that hands your agent secret to untrusted code. (The step below reads only the pull request body, never its code.)

name: Clean pull request text
on: pull_request
jobs:
  sanitize:
    runs-on: ubuntu-latest
    steps:
      - name: Remove PII and secrets from the pull request body
        shell: bash                  # bash -eo pipefail: a refused or failed call fails the step
        env:
          GW: ${{ secrets.VRYMDOR_NODE_URL }}
          AGENT_ID: ${{ secrets.VRYMDOR_AGENT_ID }}
          AGENT_SECRET: ${{ secrets.VRYMDOR_AGENT_SECRET }}
          PR_BODY: ${{ github.event.pull_request.body }}
        run: |
          TOKEN=$(jq -n --arg id "$AGENT_ID" --arg s "$AGENT_SECRET" '{agent_id:$id,agent_secret:$s}' \
            | curl -sf -X POST "$GW/v1/token" -H 'Content-Type: application/json' -d @- | jq -r .access_token)
          echo "::add-mask::$TOKEN"
          jq -n --arg body "$PR_BODY" '{action:{type:"sanitize"},input:$body,context:{platform:"github-actions"}}' \
            | curl -sf -X POST "$GW/v1/node/run" -H "Authorization: Bearer $TOKEN" \
                -H 'Content-Type: application/json' -d @- \
            | jq -r .output > sanitized-body.txt
          cat sanitized-body.txt

The pull request body is passed through an environment variable and jq, never pasted into the script, so text in the pull request cannot change the command. For a body with [email protected] and an Anthropic key, the file holds [REDACTED:EMAIL] and [REDACTED:ANTHROPIC_KEY] in their place.

Any HTTP client (curl)

Set GW to your node, exchange the agent secret, then call the node. The token request also accepts the OAuth 2.1 (Open Authorization) client credentials form (grant_type=client_credentials, client_id, client_secret).

GW=http://vrymdor-node:8080
TOKEN=$(curl -s -X POST "$GW/v1/token" -H 'Content-Type: application/json' \
  -d '{"agent_id":"agt_...","agent_secret":"vrym_agent_..."}' | jq -r .access_token)

Remove PII and secrets (nothing is sent anywhere):

curl -s -X POST "$GW/v1/node/run" -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"action":{"type":"sanitize"},"input":"Card 4111 1111 1111 1111, mail [email protected]"}'

{"node_version":"1","ok":true,"decision":"allow","output":"Card [REDACTED:CREDIT_CARD], mail [REDACTED:EMAIL]",
 "redactions":{"CREDIT_CARD":1,"EMAIL":1},"asi":[],"rules":["redacted"],"hold_id":null,"error":null,
 "attestation":{"payload_sha256":"<hex>","signature":"t=<unix>,v1=<hex>"},
 "audit":{"hash":"<hex>","trace_id":"<hex>"},"latency_ms":3.8}

Run a tool (an MCP tool your policy allows, Step 3):

curl -s -X POST "$GW/v1/node/run" -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"action":{"type":"tool","upstream":"github","tool":"create_issue"},"input":{"title":"Login fails for [email protected]"},"idempotency_key":"run-881:item-0"}'

The tool receives Login fails for [REDACTED:EMAIL] and its answer comes back in output. A repeated idempotency_key from the same agent gets the first answer back for ten minutes instead of running twice.

Call a model (the request body goes to action.path on the model upstream):

curl -s -X POST "$GW/v1/node/run" -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"action":{"type":"llm","upstream":"anthropic","path":"v1/messages"},"input":{"model":"claude-...","max_tokens":200,"messages":[{"role":"user","content":"Summarize the ticket from [email protected]"}]}}'

Send a webhook (to an upstream of kind webhook):

curl -s -X POST "$GW/v1/node/run" -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"action":{"type":"webhook","upstream":"hooks"},"input":{"customer":"[email protected]"}}'

Check only (dry run): add "params":{"dry_run":true} to any tool, model or webhook request. Every check runs, nothing is forwarded, and rules includes dry_run.

Inspect an envelope (webhook mode: the sanitized payload comes back, nothing is forwarded):

curl -s -X POST "$GW/v1/inspect" -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"vrymnox_version":"1","source":{"platform":"zapier","workflow_id":"zap-42","step":"2"},"action":{"kind":"webhook"},"payload":{"customer":"[email protected]","note":"Card 4111 1111 1111 1111 on file"}}'

{"vrymnox_version":"1","decision":"allow","redactions":{"EMAIL":1,"CREDIT_CARD":1},"asi":[],"rules":["redacted"],
 "payload":{"customer":"[REDACTED:EMAIL]","note":"Card [REDACTED:CREDIT_CARD] on file"},
 "attestation":{"payload_sha256":"<hex>","signature":"t=<unix>,v1=<hex>"},"audit":{"hash":"<hex>","trace_id":"<hex>"}}

source.platform is zapier, n8n, github or custom. GET $GW/v1/node/schema (no token needed) returns the request and response JSON Schemas and every error code.

Troubleshooting

Refusals carry a stable code and no internal detail, in the shape of the route that answered:

Plan headers: once the node has received your plan in its first sync, answers on the metered agent routes (/v1/node/run, /mcp, /v1/inspect, /v1/llm/..., /v1/mcp/... and /v1/webhooks/...) carry X-Vrymdor-Requests-Used and X-Vrymdor-Requests-Included, and from 80 percent of the allowance also X-Vrymdor-Quota-Warning. Other routes (/v1/token, /healthz, /v1/node/schema, the admin API) carry none, and an air-gapped node sends none, because it never receives a plan.

The node itself: