ADR-009 — Three Deployment Modes Strategy (Extension / Agent / Proxy)

Context

Noxys initial design assumed a 2-mode deployment: browser extension (BYOD-friendly) + desktop agent (Go, fleet-managed via MDM). A network-level forward proxy (noxys-proxy Go repo) was scoped early but not formalized as a first-class deployment mode — its roadmap items got dispersed across api/sidecar/infra during Phase 3a (2026-04-28).

Real customer scenarios, surfaced during pre-seed conversations and competitive analysis (Netskope, Cyera, SentinelOne), demand a third mode:

• Compliance-heavy customers (banks, defense, healthcare) often forbid endpoint installs.
• Regulated industries demand network-level audit trails — extension/agent are user-bypassable; proxy is not.
• SASE-style buyers (Zscaler, Netskope incumbents) expect a proxy-shaped offering at minimum.
• Some customers want mix-and-match: ext for BYOD users, agent for IDE teams, proxy for sensitive subnets — all under one tenant.

Decision

Adopt a three-mode deployment strategy with full mix-and-match flexibility.

The three modes are first-class peers, all backed by a central api + sidecar control plane. Customers (or per-user-group policies) pick any combination.

The three modes

Mode	Repo	Coverage	Hard enforcement	Bypass risk
Extension	noxys-extension	Browser AI services (chat.openai.com, claude.ai, gemini.google.com, embedded-AI in SaaS)	Soft (UX warning, badge, redact) — user can disable	High in BYOD, low under MDM force-install
Agent	noxys-agent (Go)	Desktop AI apps via OS network hooks (eBPF Linux, Network Extension macOS, ETW Windows) — Cursor, Claude Desktop, ChatGPT Mac, IDE plugins	Hard if admin install	Low under MDM, none if eBPF-locked
Proxy	noxys-proxy (Go)	All network traffic to AI APIs, regardless of app source. MITM TLS via deployed CA root.	Hard (drop with 429 before request reaches OpenAI/Anthropic/etc.)	None (unless DNS/VPN bypass — out-of-scope)

Backend (shared by all 3 modes)

Component	Repo	Role
Control plane	noxys-api	Auth, tenants, RBAC, audit, plan-gate, central token-budget counter, policy authority, telemetry ingest, webhooks
PII detection	noxys-presidio	Presidio recognizers (FR/DE/ES/IT/NL), ONNX NER (CamemBERTa-v2 LoRA), guardrail endpoint
Console	noxys-console	Per-tenant per-group mode-mix configuration UI, dashboards, billing
Catalog	shared via api	AI service catalog with jurisdiction/risk metadata
Telemetry	api + extension/agent/proxy clients	Each mode emits structured events to api → SIEM/audit

Mix-and-match decision tree (sales-facing)

CLIENT BUYER QUESTIONS:
1. Can users install browser extensions ? → if YES include EXT
2. Do users use desktop AI apps (Cursor, Claude Desktop, IDE plugins) ? → if YES include AGENT
3. Is "no endpoint install" a compliance requirement ? → if YES include PROXY (drop EXT/AGENT if absolute)
4. Does the customer need hard enforcement against bypass ? → if YES require PROXY at minimum

DEFAULT RECOMMENDATIONS:
- BYOD + SMB → EXT only
- Mid-market with MDM, IDE-heavy → EXT + AGENT
- Enterprise compliance-heavy → EXT + AGENT + PROXY
- Regulated industries (banks/defense/healthcare) → PROXY mandatory, EXT/AGENT optional
- Network-only deployment (legacy IT) → PROXY only

Token budgeting — illustrative cross-mode behavior

Token budget is the canonical example of a cross-mode capability. Each mode contributes differently:

Source of token count	Coverage	Authority
Extension (tiktoken in browser before send)	Browser-only, soft	Reports event to api
Agent (eBPF intercepts pre-send)	Desktop-only, hard if admin	Reports event to api
Proxy (read body, tokenize, hard cap)	All traffic, hard	Authoritative — drops 429
api (central counter, plan_gate)	Aggregates all 3 → enforces tier limit	Source of truth

A Business-tier customer wanting enforceable hard caps must include Proxy. Without proxy, ext+agent provide best-effort soft caps + visibility, but a determined user can bypass.

Rationale

1. Customer flexibility = win rate. Pre-seed solo-dev cannot afford to lose deals on deployment mode mismatch. Three-mode coverage = "no, we have a fit" answer in every conversation.
2. Mix-and-match is the actual market — large customers don't pick one mode; they pick per-policy-zone. Mandating one mode = losing ground to multi-vector incumbents (Netskope+Zscaler-style).
3. Proxy is the compliance moat. Extension/agent are user-bypassable. Compliance buyers (regulated industries, AI Act audit) need a tamper-evident layer. Proxy is the only "zero endpoint trust" option.
4. Code reuse. All 3 modes consume the same sidecar (PII detection) and api (auth/audit/policy). Marginal cost of adding proxy as 3rd mode is low — it's a new client of existing services.
5. Counter-positioning vs Netskope. Netskope = inline cloud TPU on Vertex AI. Noxys proxy = inline EU sovereign with on-device inference fallback. We win on sovereignty + flexibility, not raw scale.

Consequences

Positive

• Sales unlock: every IT policy maps to at least one valid Noxys deployment.
• Differentiation: only EU sovereign player offering all 3 modes flexibly.
• Compliance story: proxy = enforceable hard caps + tamper-evident audit (vs ext/agent soft).
• Future-proof: SASE-style buyers (Zscaler/Netskope/etc.) get a familiar deployment, not an unfamiliar new model.

Negative

• Engineering scope: 3 client-side codebases to maintain (TS+MV3 ext, Go agent, Go proxy). Mitigation: aggressive shared-libs strategy (noxys-shared Go module for proxy+agent common code; noxys-sdk-js for ext+console).
• Pricing complexity: tier matrix grows (mode selection × user volume × deployment cloud × on-prem option). Mitigation: simple defaults, custom Enterprise tier absorbs combinatorics.
• QA matrix: ~6+ modes × 4+ OSes × 5+ AI services = combinatorial test surface. Mitigation: contract-tested api as canonical, mode-specific E2E only on critical flows.
• Sidecar load: all 3 modes can hit sidecar. Mitigation: stateless sidecar + horizontal scale + per-tenant rate limit.

Migration & roadmap impact

• Phase 3c (2026-04-28) dispersed proxy roadmap items to api/sidecar/infra. Reversed conceptually here — items remain dispersed (logic centrally lives in those repos), but noxys-proxy repo gets dedicated runtime+deployment items (PROXY-DEPLOY-1, PROXY-DEPLOY-2, PROXY-OBS-1, PROXY-INTEG-1, PROXY-TIER-1) added to S9-S10 (2026-04-28 update).
• noxys-agent repo similarly retains the desktop daemon role; Phase 3c skipped low-confidence items there for manual triage.
• Helm Option C (ADR-008) applies: each repo carries its chart at <repo>/deploy/helm/, values in noxys-infra/helm-values/<service>/<env>.yaml. Proxy chart will land at noxys-proxy/deploy/helm/.

Status

Accepted. Effective for all roadmap items 2026-04-28 onward. Existing items in api/sidecar/infra that proxy-mode consumes (token budgeting, PII rewriting, default-deny, content filtering, routing) gain an implicit acceptance criterion: must expose stable contract consumable by all 3 modes (extension, agent, proxy).

Open Questions

• Pricing surcharge for proxy mode — does proxy belong in Business tier (current 15€/u) or warrant a separate "Compliance" tier at 20-25€/u ? Decision deferred to GTM/pricing review (next session).
• noxys-shared Go module repo — needed for code reuse between agent + proxy. Currently does not exist (Phase 3c surfaced the gap). Create or fold into noxys-eu/.github ? Decision deferred.
• CA distribution UX — proxy mode requires deploying a Noxys root CA to client endpoints. MDM-friendly but UX-painful for SMB. Need design pass: opt-in MITM scoping (only AI domains), strict cert pinning logging, transparency dashboard.