Skip to main content

​
Security model

Navi is designed so that all public clients use the same trust boundary. Whether you use the CLI, MCP, or REST API, authentication, access control, and metering all resolve through the public Navi API.

​
Public trust boundary

Clients integrate with the public Navi surface only. Internal orchestration, internal services, and private infrastructure are not exposed through public documentation or public client setup.

​
Authentication

​
Current public access mode

Today, the current public deployment supports authenticated session access. That means:
  • the CLI can authenticate with a valid session cookie
  • the local MCP server can reuse the same CLI config
  • the REST API accepts the same authenticated session context

​
Planned credential types

Navi is already structured for:
  • personal access tokens for individual users
  • service API keys for server-to-server integrations
These credential types are not enabled in the current public deployment yet. When a deployment does not support them, the token issuance routes respond with 501 not_implemented.

​
Authorization

Navi authorizes access using:
  • the authenticated principal
  • the principal’s organization
  • scoped capabilities such as agents:read, runs:write, or briefings:read
This keeps the public model consistent across every interface.

​
Metering and limits

Navi is designed to meter public usage consistently across all interfaces:
  • request volume
  • run creation and run inspection
  • token consumption
That makes CLI, MCP, and API usage governable through a single public control plane.

​
Request tracing

Public API responses include a requestId. Keep that value when you contact support or investigate an unexpected response.

​
Local credential handling

​
CLI

The CLI stores its local configuration in: 
~/.config/navi/config.json
That file may include:
  • your Navi base URL
  • your session cookie
  • future token values when token auth is enabled

​
MCP

The local MCP server reads from the same Navi config and environment values as the CLI. It does not require separate credentials.

​
What this public documentation does not include

This documentation does not publish:
  • secrets
  • internal service URLs
  • deployment runbooks
  • private system topology
  • privileged internal-only workflows