Navige Technical Reference

Quick Start

Two ways to connect. MCP-speaking agents (Claude Desktop, Cursor, Cline, Continue, and any other MCP-compatible client) point at Navige as a native MCP server — see the MCP section below. Anything else calls POST /enforce directly with a virtual key — see the setup guide's Direct REST tab for curl, Python, and Node examples.

Authentication

All authenticated endpoints take a virtual key, minted per agent from your dashboard's Agents page (shown once). Pass it as a bearer token:

Authorization: Bearer nv_your_key_here

An MCP client that can't set custom headers can pass the same key as a query parameter instead: ?api_key=nv_your_key_here.

Sign in to the dashboard itself with your email and password — each organisation supports multiple team members with owner, admin, and viewer roles, not a single shared credential. A virtual key is scoped to one agent and carries that agent's activity; it's shown once at creation and can't be retrieved again, only revoked and replaced.

MCP — Claude Desktop and other MCP clients

Connect any MCP-compatible agent by adding Navige as an MCP server in your config. Every tool call passes through Navige's governance pipeline before it executes.

{
  "mcpServers": {
    "navige": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://api.navige.ai/mcp?api_key=nv_xxx"]
    }
  }
}

Governance Pipeline

Every call through MCP or /enforce runs the same pipeline, in order. The first check that stops the call returns its decision immediately — nothing later in the list runs.

Caching

To keep the pipeline fast, Navige caches two things in Redis:

• Virtual-key lookups — a 60-second cache, so authenticating the same agent repeatedly doesn't hit the database every call.
• Policy context — your organisation's active rules and settings, a 30-second cache, since policy evaluation itself is deterministic code with nothing to cache per-call.

PII & Compliance

Before any call's arguments are written to the audit trail, Navige redacts what shouldn't be stored raw — the original, unredacted values are still what your policy rules evaluate against; only what gets persisted is masked:

• Masks PII — email addresses, UK and international phone numbers, card numbers, UK National Insurance numbers, US Social Security numbers, and IBANs. Emails and phone numbers keep a partial prefix/suffix for readability (j***@company.com); card numbers, NI, and SSN are fully replaced.
• Redacts secrets — API keys, tokens, and bearer credentials replaced with [REDACTED].
• Scores risk — every tool and agent gets a numeric 0–100 risk score, shown in the dashboard banded into Low/Medium/High for a quick read.

Every redaction is counted, not just applied silently — each audit entry records how many PII matches and secrets it redacted, feeding directly into compliance reports rather than being recomputed against data that was never stored raw.

Blockchain Anchoring

Blockchain anchoring is optional, off by default, and free on every plan — turning it on doesn't require an upgrade. Once an organisation turns it on, Navige hashes each batch of audit-log entries together with the hash of the previous batch, and records the result on the Polygon Mainnet via a smart contract at 0xd2544fc3164ac0eBfb6B7A2c193800F9651Fc46F.

Because each batch's hash includes the one before it, the batches form a chain: altering or removing any past batch changes its hash, which breaks every hash computed after it. This creates an independently verifiable tamper-evident record. The audit trail itself is also append-only at the database level — direct edits or deletes are blocked outright — so if any logged entry in a batch were somehow altered, recomputing that batch's hash would not match what's on-chain, and neither would any batch anchored after it.

Anchor records are stored alongside your audit logs. Use the Blockchain tab in your dashboard to see every anchor with a direct Polygonscan link, or query the API below to verify programmatically.

Viewing your anchors

Every anchor — batch hash, Polygon transaction hash, and a pre-computed Polygonscan link — is listed in your dashboard's Blockchain tab. This is a dashboard feature, not a separate API-key-authed endpoint on the gateway; the shape below is what that view returns:

{
  "id": "uuid",
  "hash": "0xabc123...",
  "prev_hash": "0x999888...",
  "batch_from": "2026-07-22T13:00:00.000Z",
  "batch_to": "2026-07-22T14:00:00.000Z",
  "action_count": 142,
  "status": "live",
  "tx_hash": "0xdef456...",
  "polygonscan_url": "https://polygonscan.com/tx/0xdef456...",
  "created_at": "2026-07-22T14:00:00.000Z"
}

How to verify a batch independently

1. Export your audit log for the batch's time window, and note the log_hash of the anchor immediately before it — that's your prevHash (null for an organisation's first anchor)
2. Recompute: ethers.keccak256(ethers.toUtf8Bytes(JSON.stringify({ prevHash, batch }))), where batch is each record's id, occurredAt, decision, requestHash, in the same order the batch was built
3. Compare the result to log_hash above
4. Open the polygonscan_url → More details → Input data — the same hash is written on-chain

Salesforce & Agentforce

Two separate pieces, both live: automatic discovery of every Agentforce and Einstein Bot agent in a connected org, and — new — a real-time enforcement package for the ones you specifically want governed.

Discovery is self-serve from the dashboard — Settings → Salesforce. Create a Connected App (or External Client App) in your own Salesforce org, set its callback URL to https://app.navige.ai/api/platforms/salesforce/callback, and paste in your instance URL and Consumer Key/Secret. From there it's a real OAuth flow (Authorization Code + PKCE) that records every agent found, plus its CRM system access, in your Registry — no code deployed into Salesforce for this part, and no CLI required. Salesforce Connected Apps are scoped to the org that creates them, which is why this needs your own org's app credentials rather than a single "click to connect" button. It's inventory only: Agentforce runs entirely inside Salesforce's own runtime, so this never shows a live conversation trace, only that an agent exists and what it can reach.

Real-time enforcement is a small, installable Salesforce package (Apex classes, a permission set, a platform event) your admin deploys with the Salesforce CLI. It adds an Invocable Action — Navige: Check Before Acting — that any Flow or Agentforce Topic Action can call right before a real step executes, getting back the same allow / deny / approval decision every other integration gets. Because Salesforce Apex callouts cap out around 120 seconds and an approval can take up to 5 minutes, the package always calls with wait: false and polls for the outcome via a Queueable job, publishing a platform event once Navige reports a final decision.

Full setup instructions, the package source, and a verification checklist are in the salesforce/ directory of the Navige repository.

Plan Limits

Limits are enforced at the intercept point. When a limit is exceeded, the API returns HTTP 429 with a clear error message. Usage resets on the 1st of each calendar month.