Security Risk Register

This register records accepted-risk decisions for the UpsQuad platform. An accepted risk is one where the team has consciously chosen not to remediate (or to defer remediation), because the residual risk is judged tolerable given the compensating controls in place. Each entry captures who accepted the risk, when, the controls that bound the exposure, the residual risk that remains, and the trigger that forces a re-evaluation.

This is a living document. Accepting a risk is not a one-time event — every entry carries a review cadence and a review trigger. When a trigger fires, the owner must re-open the entry, re-assess, and either renew the acceptance, tighten the controls, or schedule remediation.

How to read an entry

Each risk is recorded under a stable identifier (RR-NNN) with the following fields:

Field	Meaning
Status	Accepted / Superseded / Remediated / Under review
Owner	Who is accountable for this risk and its review
Accepted by	The person who authorised the acceptance
Accepted on	Date the acceptance was recorded
Review cadence	How often the entry is revisited absent a trigger
Review trigger	Condition(s) that force an immediate re-evaluation
Risk	What could go wrong
Compensating controls	What bounds the exposure today
Residual risk	What remains after the controls are applied

---

RR-001 — Standing auth-bypass flags on the box dev stack

Field	Value
Status	Accepted
Owner	DevOps Engineer (dev-stack operator)
Accepted by	Founder (Vaisakh)
Accepted on	2026-06-12
Review cadence	Quarterly, or on any trigger below
Review trigger	The dev stack ever holds real tenant data, or beta-dev.app.upsquad.ai is opened beyond @upsquad.ai identities, or the gateway triple-gate contract changes

Risk

The box dev stack runs the gateway with its auth-bypass flags left standing — DISABLE_AUTH and ICS_MODE are both enabled (each set to true) for the lifetime of the stack, rather than toggled on per-session and torn down afterwards. This is what lets beta-dev.app.upsquad.ai run live-wired against the real backend while authenticating callers through the persona-switcher dev identity instead of a genuine Clerk session.

A standing bypass is, in the abstract, a privilege-escalation and unauthenticated-access risk: anything that could reach that gateway would transact without proving identity.

Decision and history

This supersedes the earlier architect recommendation made during the PR #1269 review, which asked for the bypass to be opt-in and ephemeral (enabled only for the duration of a wiring session, then disabled). The founder accepted the standing-flag posture on 2026-06-12 for the box dev stack only, on the basis that the compensating controls below make the standing exposure acceptable in exchange for a materially smoother live-wiring loop.

The acceptance is scoped to the box dev stack alone. It does not extend to the beta (GCP) or app (GCP) spokes.

Compensating controls

1. Network/identity perimeter — Cloudflare Access. beta-dev.app.upsquad.ai sits behind Cloudflare Access, which restricts reachability to @upsquad.ai identities. An anonymous internet caller cannot reach the gateway at all; the bypass is only ever exposed to authenticated members of the org.

2. Environment confinement — gateway triple-gate. The bypass is honoured only when ENVIRONMENT=development. The gateway enforces this structurally: bypassAllowed in internal/gateway/auth.go returns false for any environment value other than the {development, sandbox} allow-list, and the sandbox branch additionally requires the companion ICS flag. Independently, authbypass.MustCheckStartupGate (internal/gateway/auth/bypass.go, bug #772) refuses to start the gateway in an inconsistent flag state. The beta and app spokes ship with ENVIRONMENT set to a non-development value, so on those spokes the bypass is structurally impossible — no combination of leaked flags can waive auth there.

3. Data minimisation — synthetic data only. The dev stack contains seeded/synthetic fixtures only. There is no real tenant data behind the bypassed gateway, so the impact of an unauthenticated transaction is bounded to throwaway data.

4. Provenance — box-local configuration. The flags are set via a box-local repo-root .env file that is never committed to source control. They exist only on the operator's box and cannot leak into a deployed manifest through the repo.

Residual risk

With the four controls in place, the residual risk is low: an @upsquad.ai insider could transact against synthetic dev data without a real session. There is no path for an external party to reach the bypassed surface, and there is no path for the standing flags to take effect on a spoke that carries real tenant data, because those spokes do not run with ENVIRONMENT set to development.

The residual risk is accepted in exchange for the developer-velocity benefit of a continuously live-wired dev stack.

Review trigger (restated)

Re-open and re-assess this entry immediately if either of the following becomes true:

• the dev stack ever begins holding real tenant data, or
• beta-dev.app.upsquad.ai is opened to identities beyond @upsquad.ai.

Either change invalidates a compensating control and the standing-bypass posture must be re-justified or remediated (likely reverting to the opt-in/ephemeral model from the PR #1269 review).