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.

Your integration submits a structured proposed action through Nava Service, waits for a terminal verdict, and submits the action to its venue only when verdict.outcome is approved.

Add Nava Guardian to this agent integration. Submit the exact structured action to POST /transactions, poll the approval-status resource with bounded backoff, fail closed unless verdict.outcome is approved, and keep signing and venue submission outside the Guardian client.

Use the supported boundary

Loading diagram...

The customer-facing integration has two operations:

POST /transactions submits the proposed action with arbiter: "policy".
GET /transactions/:requestHash/approval-status returns an approval-status envelope whose optional verdict contains the Guardian result.

Continue your integration

Submit an action

Construct and submit the exact structured proposed action, then retain its requestHash.

Handle verdicts

Poll with a bounded deadline and safely handle pending, rejected, unavailable, and approved outcomes.

Map the policy model

Map policy fields to proposed actions before you submit them.

Read the Guardian API

Use the canonical request, response, enum, and error contract.

Integration sequence

Register and scope the agent

Build the exact action

Construct the structured action the agent proposes to execute.

Submit and retain the request hash

Submit the action and retain its requestHash.

Poll and handle the verdict

Poll and handle the verdict with a bounded deadline.

Submit only after approval

Submit the action to its venue only after an approved outcome. A new or changed action needs its own Guardian request.

Authentication

Send the agent API key in the x-api-key header. Never put it in a query string, request body, application log, or example output.

Use an agent key with the least-privilege verdicts:create:own scope for the policy-verdict path. The status route requires authentication and confirms that the caller owns the transaction.

Suggest changes to this page