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 use the public verifier below — no login required, and nothing in it needs to trust Navige's word for anything.

Each batch is hashed as a Merkle tree, not one flat hash — a single record can be proven against the anchor's root without exposing anything else in that batch. That's what makes a signed decision receipt independently verifiable on its own. Completeness — proving nothing was deleted before a batch was ever hashed, which no hash over the batch alone can show — is checked separately: a running total of every action anchored so far is compared against a live recount on every verification.

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...",
  "hash_scheme": "merkle",
  "batch_from": "2026-07-22T13:00:00.000Z",
  "batch_to": "2026-07-22T14:00:00.000Z",
  "action_count": 142,
  "cumulative_count": 4187,
  "status": "confirmed",
  "tx_hash": "0xdef456...",
  "polygonscan_url": "https://polygonscan.com/tx/0xdef456...",
  "created_at": "2026-07-22T14:00:00.000Z"
}

How to verify a batch or a single decision independently

Easiest path: the public verifier for a whole batch, or fetch GET https://api.navige.ai/api/receipts/:actionId for a single decision — a signed, portable JSON object (decision, the exact policy version that matched it, and a proof against the anchor covering it) verifiable completely offline against the public key at GET /.well-known/navige-signing-key. No login, and no ongoing trust in Navige's API required after that one key fetch.

To recompute by hand instead: check the anchor's hash_scheme. For "flat" (anchors created before 8 Sep 2026):

1. Export your audit log for the batch's time window, and note the 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 hash above, then open polygonscan_url → More details → Input data to confirm the same value is on-chain

For "merkle" (current anchors), the root is computed over a binary Merkle tree of the same per-record leaves with prevHash as an extra leaf at index 0 — GET /api/blockchain/verify/:anchorId/record/:actionId returns the proof path for one record rather than requiring you to reconstruct the whole tree by hand.

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.

AWS Bedrock

Covers both AWS agent products — Bedrock Agents Classic and Bedrock AgentCore — since new AWS accounts increasingly land on AgentCore while existing Classic agents keep running unaffected.

Discovery is self-serve from the dashboard — Settings → AWS. AWS has no OAuth consent screen for third-party access, so this uses the same cross-account IAM role pattern Datadog, PagerDuty, and Snyk all use: generate setup instructions to get a stable per-org External ID and ready-to-paste trust-policy JSON, create the IAM role it describes in your own AWS account, paste back its Role ARN. Navige calls sts:AssumeRole to get short-lived, read-only credentials — nothing long-lived ever leaves your account. One connection discovers agents across both products: Classic's ListAgents and AgentCore's independently-listable Agent Runtimes and Harnesses.

Real-time enforcement differs by product. For Classic, a small reusable Lambda module gates a Bedrock Agent Action Group before it executes — Lambda's 15-minute timeout comfortably covers /enforce's approval hold, so no polling loop is needed. For AgentCore, there's no code to deploy at all: an AgentCore Gateway can expose tools over MCP, and pointing a Gateway Target directly at https://api.navige.ai/mcp — the same endpoint Claude Desktop and Cursor already use — means every tool call routed through that gateway flows through Navige's existing governance, with only AWS-side configuration required.

Full setup instructions and the Lambda package source are in the aws/ 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.