ADR 0001 — Vendor access is a granted role; leverage is the engagement credential, never a backdoor

In short

This settles how our team gets into a client’s system in order to run it for them. We do not build a hidden way in. We are added as an ordinary named member of the client’s own system: visible in their admin screen, recorded in their audit log, and removable by them at any moment. What holds an engagement together instead is the licence — cut us off mid-contract and the system keeps running exactly as it is, but its engagement credential is switched off, so it stops receiving updates, new capabilities and support. Nothing is destroyed and nothing is bricked: the client always holds the plug, and a serviced system simply pulls ahead of a frozen one.

Context

Qren is a deployment house: bespoke agentic-system engagements ($50–200k initial + monthly retainer) operated remotely by the Qren team on instances that run on client-controlled hardware. Two locked positions collided:

1. The sovereign rule (accounts spec, 2026-08-17): each client’s Qren is THEIR instance on THEIR machine; routing may pass through Qren’s edge, compute and data never do. The shipped workspace layer hard-codes “system admin sees metadata only.”
2. The business need: the team must be able to service, debug, and operate client systems remotely for the life of the engagement — and the engagement must not be trivially terminable by a client flipping a switch while under contract.

Options considered: (a) standing vendor access clients cannot remove (a rootkit in effect — unenforceable on client hardware, fatal in any security review, kills enterprise deals); (b) sovereignty preserved with leverage through licensing; (c) absolute blindness (metadata only forever — strangles the retainer business).

Decision

Access: the deployment team (“Qren Ops”) is an ordinary principal in the client’s own permission system — a (principal, scope, role) binding, visible in their admin panel, fully audited, technically revocable by the client at any time. Default telemetry is metadata + health; content access is scoped per engagement (wide for early partners — deep access is the price of a free system; narrow for conservative clients). Ops access reaches the Qren instance only (services, agents, granted workspaces, config) — never the client’s machine as a whole.

Leverage: revoking Qren Ops is an offboarding event, not a toggle — contractually a breach if done mid-engagement, and automatically consequential: Qren’s back end revokes the instance’s engagement credential (the activation/invite token), which freezes the instance at its current version — no updates, no new arms, broker/hosted-OAuth dead, portal routing dead, support ended. Nothing already deployed is destroyed or disabled: the deployment fee bought the deployment; the retainer buys the living system. A frozen Qren decays against a serviced one — that decay is the retention mechanism.

Consequences

• The sales pitch keeps its strongest line intact: “your AI on your hardware, your data never leaves, you hold the plug — and every action we take is in your audit log.”
• No hidden access exists anywhere in the product; security audits find exactly what the contract says.
• The updater/broker/portal MUST remain gated on the engagement credential — that gating is load-bearing for the entire business model.
• Remote operations ride the existing per-machine tunnel + portal routing under the Ops principal; no separate access channel may be built.
• Clients who stop paying keep a working-but-frozen system; reactivation is a re-engagement, not a reinstall.