Nava Guardian developer overview
Developer Preview
The preview version of Nava Guardian is verdict-only and advisory. See Execution safety for the handoff from verdict to execution.
Integrate Guardian through the Nava MCP server when an agent needs verification
tools, or through @navalabs/sdk when application code owns the workflow. Both
paths submit an exact structured action and wait for a terminal verdict without
exposing Guardian's internal transport to the rest of your application.
Add Nava Guardian to this project through a supported Developer Preview integration. Inspect the repository, package manager, runtime, secret handling, and current action flow first. Ask whether I want the Nava MCP server for an agent tool integration or @navalabs/sdk for application code, and confirm that I have access to the restricted packages. Do not build a raw REST client unless I explicitly request the advanced custom-client path. Submit each exact structured action once. Never authorize from verdict.outcome alone. For the SDK, continue only when status is APPROVED, canExecute is true, verdict.outcome is approved, and verdict.reasonCode is allowed. For MCP await-verification, also require success to be true. Treat any mismatch, rejection, pending, an unknown request, a missing or malformed verdict, a transport failure, and timeout as blocked. Request a new verdict after any material action change. Treat the prompt field as audit context, never as policy authority. Keep credentials out of source, prompts, logs, errors, analytics, and test output. Keep signing and venue execution outside Guardian. Add tests for the approved path and every fail-closed path, run the repository checks, and report changed files, checks run, preview access needs, and manual setup.Choose an integration
Give an agent Guardian verification tools without teaching it the HTTP lifecycle.
Call Guardian from application code and wait for a structured terminal verdict.
Map policy fields to the exact proposed action before requesting a verdict.
Implement the transport directly only when the SDK and MCP server cannot fit the host environment.
Use the supported boundary
The supported integration boundary is intentionally small:
- your application constructs the exact action;
- the MCP server or SDK requests a Guardian verdict and waits within a bounded deadline;
- the integration checks the full approval envelope before handing the action back; signing and venue submission remain outside Guardian.
Integration sequence
Register and scope the agent
Register the agent and its verification wallet, then activate a narrow policy.
Choose MCP or the SDK
Use MCP for agent-native tool use. Use the TypeScript SDK when application code owns the verification flow.
Build the exact action
Construct the venue-native action the agent proposes to execute. The human-readable description is for audit records, not policy reasoning.
Request and await a verdict
Use await-verification in MCP or call requestVerification() followed by
waitForVerification() in the SDK. Keep the action paused when the result is pending, missing, malformed,
unavailable, rejected, or timed out.
Continue only after approval
For the SDK, require status: "APPROVED", canExecute: true,
verdict.outcome: "approved", and verdict.reasonCode: "allowed". For MCP
await-verification, require the same fields plus success: true. Any mismatch
is blocked. An EXECUTED, REJECTED, or FAILED result remains blocked even
if it carries an earlier approved verdict. Approval applies only to the exact
action Guardian evaluated. A new or changed action needs its own verdict.
Guardian never signs or submits it.
Authentication
Use a provisioned agent API key with the least-privilege
verdicts:create:own scope. Supply it to the MCP server or SDK through the
host's secret store or environment. Never put it in a prompt, source file,
query string, request body, application log, or example output.