Date: 2026-09-10

​
Executive summary

Compass uses a local-first architecture where Nova CLI runs on the user’s PC as the main execution engine and Compass cloud services provide API key authentication, LLM middleware, integrations, and Azure-hosted platform capabilities. The main control boundary is between:
  • Local execution: Nova CLI, Compass Desktop, local tools, skills, and ACP/A2A conversations.
  • Compass cloud: Compass API, LLM middleware, Graph API service, FastRAG, MCP service, Azure OpenAI, Redis, Storage, Key Vault, App Configuration, and supporting platform services.
  • Client surfaces: Compass web app, Office add-ins, Pocket Partner PWA, and Compass Desktop.
The architecture should preserve three principles:
  1. Local work stays local by default. Nova performs execution on the user’s PC unless a cloud service is explicitly required.
  2. Compass API is the trust gateway. API key authentication and LLM middleware are centralised through the Compass API.
  3. Data access is controlled by purpose. Each service should receive only the data required for the current task, with auditable access and clear retention boundaries.

​
Architecture scope

​
Local components

​
Cloud components

Legacy Azure names may still contain kore; externally and in product documentation, the system should be referred to as Compass.

​
Identity and authentication controls

​
API key authentication

  • Nova CLI authenticates with the Compass API using an API key.
  • Office add-ins authenticate with the Compass API using an API key.
  • API keys should be scoped per user, tenant, or client application where possible.
  • API keys should be stored only in secure local storage or approved secret stores.
  • API keys should never be logged, included in telemetry, exposed in URLs, or embedded in client-side public assets.

​
Local pairing and protocol controls

  • Compass Desktop connects to local Nova using ACP.
  • Pocket Partner pairs through Compass Desktop before establishing direct chat with Nova using A2A.
  • Pairing should use short-lived pairing codes or equivalent challenge-response validation.
  • Paired devices should be revocable from Compass Desktop or Nova.
  • A2A sessions should be bound to the paired device identity and should expire after inactivity.

​
Cloud service identity

  • Azure services should prefer managed identity over static credentials.
  • Container pulls from Azure Container Registry should use managed identity where supported.
  • Service-to-service access should use least privilege role assignments.
  • Admin or shared credentials should be rotated out of production paths.

​
Data flow controls

​
Nova CLI to Compass API

Purpose:
  • API key validation.
  • LLM middleware access.
  • Optional cloud service orchestration.
Controls:
  • Send only the prompt, context, metadata, and tool outputs required for the requested operation.
  • Avoid sending local file contents unless the user explicitly selected or authorised them.
  • Redact secrets before requests are sent to cloud services.
  • Use HTTPS for all cloud communication.

​
Compass Desktop to Nova CLI

Purpose:
  • Local UI control of Nova through ACP.
Controls:
  • Restrict ACP to local trusted endpoints by default.
  • Require explicit user approval before Desktop exposes Nova to other devices.
  • Validate command origins and prevent unauthorised local command execution.

​
Pocket Partner to Compass Desktop and Nova CLI

Purpose:
  • Device pairing through Compass Desktop.
  • Direct chat with Nova after pairing using A2A.
Controls:
  • Require explicit local approval for pairing.
  • Use time-limited pairing sessions.
  • Encrypt device-to-device communication.
  • Allow users to list, revoke, and reset paired devices.
  • Limit mobile-initiated actions that can modify files, send emails, or affect external systems unless confirmed.

​
Office add-ins to Compass API

Purpose:
  • Office productivity workflows using Compass LLM middleware.
Controls:
  • Authenticate with API keys.
  • Send only selected document content or user-approved ranges/slides/sections.
  • Avoid uploading entire documents by default.
  • Clearly distinguish local document context from cloud-submitted context.
  • Apply tenant and user-level policy controls for sensitive document handling.

​
Data classification

​
LLM middleware controls

The Compass API LLM middleware should enforce:
  • Provider routing and model selection policy.
  • API key validation before model access.
  • Request size limits.
  • Prompt and response logging policy.
  • Sensitive data redaction before logging.
  • Abuse and rate limiting controls.
  • Tenant-aware configuration.
  • Clear separation between user content, system instructions, and tool outputs.
  • Audit events for high-impact tool usage.

​
Storage and retention controls

Recommended retention posture:

​
Network and infrastructure controls

Recommended Azure posture:
  • Enforce HTTPS-only endpoints.
  • Use TLS 1.2 or higher.
  • Disable public network access where private endpoints are practical.
  • Use managed identity for service-to-service access.
  • Restrict storage, Redis, Key Vault, ACR, and Cognitive Services access to required services and networks.
  • Prefer private endpoints and VNet integration for production services.
  • Enable diagnostic settings for critical resources.
  • Ensure live production services have Application Insights or equivalent monitoring.
  • Use staging slots for controlled deployment where supported.

​
Operational controls

​
Deployment

  • Use separate development, staging, and production configuration.
  • Keep production secrets out of source control and CI logs.
  • Use deployment slots for high-risk changes.
  • Require health checks before traffic switchovers.

​
Monitoring

  • Monitor API latency, error rates, authentication failures, model failures, and rate limits.
  • Alert on spikes in failed API key authentication.
  • Alert on unusual LLM usage patterns, high token volume, and abnormal tool activity.
  • Monitor ACR image pull failures and container restart loops.

​
Auditability

Audit events should capture:
  • API key authentication success/failure.
  • Model request metadata without sensitive payloads.
  • Tool calls that affect files, emails, calendars, cloud resources, or databases.
  • Pairing, unpairing, and A2A session lifecycle events.
  • Graph API access by user, tenant, scope, and operation.
  • RAG document ingestion, access, and deletion events.
  1. Formalise the Compass data classification model and retention periods.
  2. Replace remaining static service credentials with managed identity where possible.
  3. Add explicit pairing revocation and expiry requirements for Pocket Partner.
  4. Define Office add-in content-submission rules by default: selected content first, full document only with confirmation.
  5. Review Azure public network exposure for Storage, Key Vault, Redis, ACR, and Cognitive Services.
  6. Standardise monitoring across Compass API, Graph API, MCP, FastRAG, and frontend services.
  7. Document LLM middleware logging, redaction, and audit policy.