---
title: Attack Vectors, Traced — N1 Threat Assessment
---

# Attack Vectors, Traced

Each vector is walked gate by gate through N1's real landscape and asked one question — with the controls that exist today, can you actually get in? Every verdict is backed by an artifact: a config read on the live production cluster, a `file:line` in the service code, or a Cloudflare control-plane record. **There is no unauthenticated path from the open internet to patient data.** Every realistic route runs through something N1 already trusts — a device, an account, or a signed-in person.

### Metadata

- **Source:** Landscape + live verification
- **Cluster:** n1-production · 191421493115 · us-east-2
- **CF snapshot:** state.json · 2026-06-08
- **Method:** claim → artifact, or it doesn't ship

## How each verdict was decided — claim → artifact

### Verdict Summary

- **4 Reachable** — A grounded path exists with today's controls. Worth real defensive weight.
- **7 Bounded** — A genuine weakness, but a verified control stands in the way. Named each time.
- **2 Needs-evidence** — The deciding artifact lives in a SaaS console, not in code. A question, not a finding.
- **3 Blocked** — The controls close the path. Kept to show the work.
- **3 Amplifiers** — Not a way in. Turns a small foothold into a large one. Matters after entry.

## 02 · A worked attack, start to finish — the most realistic chain

## Compromise a remote contractor's laptop, then try to reach patient data.

Entry layer: endpoints. Objective: PHI in Aurora / S3.

1. **Phish or infect an unmanaged laptop.** Remote contractors work on personal machines — no device management, no endpoint detection on N1 devices.Landscape §2
2. **Ride the trusted session.** The device holds an always-on WARP tunnel and a signed-in Google session; the attacker inherits an identity that already passed 2FA.§2, §4.2
3. **See only what that contractor can see.** A contractor account is not an admin — no AWS access (only three named accounts), not on the prod-deploy list. Blast radius = that one person.§4.5, §7A.1
4. **Reach staging data over WARP.** Any WARP-enrolled `@n1.healthcare` device can resolve `db.staging.n1` and read the staging database, read-only.§6.7
5. **Is staging real or synthetic? — open.** The whole severity of step 4 turns on this. No seed script, fixture, or prod→staging copy job exists in any repo, and `synthetic-medical-reports` is an OCR-training generator, not a staging seeder. The absence of a seeder leans toward organic (possibly real) data — but that's inference. Settles at the console: query staging Aurora for account emails / ages.
6. **Production PHI — stops here.** Production data is never exposed over WARP. Reaching it needs a production app session, AWS credentials (three people), or a pod foothold. The stolen laptop provides none.§6.7, §4.5, §17.1

**Verdict — Reachable but bounded.** The laptop is the realistic front door; it yields staging access and a trusted identity, but not production PHI by itself. The chain continues to the crown jewels only if (a) the laptop belongs to a privileged account, or (b) staging holds real records (step 5, open).

**A second realistic chain — the in-cluster ArgoCD bypass.** A foothold in any pod (via V-02, a supply-chain image) on the flat pod network (V-12) can reach `argocd-server:8080` directly and authenticate as the enabled local `admin` account — bypassing Cloudflare Access, Google SSO and ArgoCD RBAC — for full production deploy control. See V-07 Finding A.

## 03 · Every vector, traced

Reachable

### V-01: Unmanaged endpoint compromise — the keystone

**Verdict:** 🔴 Reachable | **Category:** `Endpoints`


No device management and no endpoint detection on N1 machines; access is gated by the session on the device, so stealing the session skips 2FA entirely. Stops at the privileges of the account on that laptop — a contractor device ≠ AWS ≠ prod deploy. The crown-jewel version requires a privileged-account device. §2, §4.5

### V-02: Path-traversal write in the document parser

**Verdict:** 🔴 Reachable | **Category:** `Application · ingestion`


◕ signed-in clinician uploads›
✕ filename unsanitized›
✕ joined into a write path

An authenticated upload reaches api-backend, which takes the filename unsanitized — `records.py:254` (`file.filename or "unknown"`) — and passes it to `parser-gate .../converters/office.py:191`: `input_path = temp_path / source_filename`. A name like `../../etc/cron.d/evil.docx` resolves outside the temp dir. It is a filesystem **write**, not command injection (no `shell=True` anywhere). Same flaw at `office.py:141`.

Bounded by container filesystem permissions — a non-root user with read-only rootfs largely neuters it (confirm in the Helm chart). No other reachable sink on the active path: mineru 2.7.6 emits its own image filenames; parser-sequential gets pre-parsed JSON; OcrRouter / pdf-converter are archived and off-path; helix-parser is a separate genetic pipeline.

Fix

Strip directory components: `temp_path / Path(source_filename).name` at `office.py:141` and `:191`.

### V-04: Dangling DNS takeover (plan.n1-research.com)

**Verdict:** 🔴 Reachable | **Category:** `Edge · DNS`


A live CNAME points at an external Cloudflare Pages project not in N1's account — a claimable dangling target on a trusted domain. Impact is phishing / brand abuse on `*.n1-research.com`, a stepping stone to V-01-style credential theft, not direct data access. The retired GKE tunnels behind other dead DNS are harmless 502 dead-ends; this CNAME is the only live takeover candidate. §6.4, §6.7

### V-20: The alarm shares fate with the building

**Verdict:** 🔴 Reachable | **Category:** `Detection integrity`


SigNoz sends alerts to Slack, and Slack federates to Google — so the channel that would warn about an identity compromise can be silenced by that same compromise. There is no out-of-band alert path independent of Google and Slack. A response gap, not an entry point. §13, §6.6

Bounded

### V-03: Indirect prompt injection via uploaded records

**Verdict:** 🟡 Bounded | **Category:** `— nuisanceAI pipeline`


CHR agents (forge-runner, on the AGNO framework) read patient data through MCP tools; instructions hidden in an uploaded document can influence the model the agent acts on. The deciding question — what those tools can reach — resolves against the attacker (V-10 below): the tools are read-only, single-patient, and have no attacker-controllable egress. A successful injection is therefore a **nuisance** (garbage in the generated report), not an exfiltration path.

Every tool reads only the one patient pinned in `WORK_DIR` (`patient-data/server.py:27`); nothing writes patient records; outbound calls go only to hardcoded NCBI / OpenTargets / N1 endpoints. No cross-patient read, no egress to an attacker.

### V-07: ArgoCD authentication

**Verdict:** 🟡 Bounded | **Category:** `— in-cluster bypassKubernetes · deploy control`


✓ CF Access app on prod host›
✓ @n1.healthcare SSO + deny-all›
✕ local admin bypasses it in-cluster

Production ArgoCD is gated by a Cloudflare Access application named **“ArgoCD”** whose `self_hosted_domains` include `argocd.n1-research.com` (CF snapshot, 2026-06-08). Policies: (1) allow `email_domain=n1.healthcare` + Google login; (2) **deny everyone**; (3) non-identity `any_valid_service_token`. The external door is shut. RBAC default is `role:readonly`; named deployers are jasper, umar.shah, arun, darpan.bafana. Three residuals from the live cluster:

Path A (green): internet → Cloudflare Access (Google SSO, deny-all) → tunnel → ArgoCD. Path B (red): a pod inside the flat network reaches `argocd-server:8080` directly and logs in as the enabled `admin` account — no CF Access, no SSO, full RBAC bypass.

⚠ Finding A — local admin account enabled (real)

Live `argocd-cm`: `admin.enabled: "true"`; `argocd-secret` carries `admin.password` + `admin.passwordMtime`. CF Access only fronts the external hostname; with no NetworkPolicies (V-12), any pod can reach `argocd-server:8080` and log in as `admin` (superuser), bypassing CF Access, SSO and RBAC — full prod deploy control. **Fix:** `admin.enabled: "false"` + a NetworkPolicy on the `argocd` namespace.

⚠ Finding B — service-token policy unscoped

Access policy #3 admits `any_valid_service_token` — any valid Cloudflare service token in the account (currently two SigNoz ingestion tokens) can reach prod ArgoCD non-interactively, around the human SSO gate. **Fix:** scope to a named token, or remove policy #3.

⚠ Finding C — jwt-proxy may be off the served path (drift)

Helm intends `argocd-server` → jwt-proxy `:8888` (it mints the `Cf-Access-Authenticated-User-Email` header Dex authproxy needs). Live, that Service targets raw `:8080`; the `:8888` path is on a separate `argocd-server-proxy` Service. If the dashboard-managed tunnel forwards to the raw service, SSO-by-header breaks and login falls back to the shared `admin`. `server.insecure:true` ⇒ in-cluster traffic is plaintext. **Confirm:** tunnel targets `argocd-server-proxy:8888`.

### V-11: Phishing a privileged Google identity

**Verdict:** 🟡 Bounded | **Category:** `Identity`


2FA is mandatory; onsite staff use hardware YubiKeys that defeat remote phishing outright. A remote user on a TOTP authenticator app can be relay-phished, but the blast radius is that account's reach; reaching the crown jewels needs one of the three AWS accounts, the hardest to phish. §4.3, §4.5

### V-13: GitHub account → production code

**Verdict:** 🟡 Bounded | **Category:** `Source & CI/CD`


Org-wide 2FA, branch protection (no force-push, ≥1 approval), and signed commits on every branch of every repo. A stolen session can't produce a signed commit without the key, nor merge without a second approver. The realistic version needs a full device compromise (V-01, for the key) plus a second account. §17.3

### V-15: LiteLLM key theft

**Verdict:** 🟡 Bounded | **Category:** `AI pipeline`


A LiteLLM key buys model access — cost abuse / denial-of-service — not a read of stored PHI; you'd already need the data to send it. Keys are Access-gated, self-service, 30-day expiry, invalidated on reissue. §11, §17.2

### V-18: Cloudflare account / tunnel compromise

**Verdict:** 🟡 Bounded | **Category:** `Edge · second trust root`


Catastrophic if it happens (owns ingress, the identity gate, TLS termination) but low-likelihood and dependent on Cloudflare's own security. Tunnel tokens live in Secrets Manager, needing a prior AWS/pod foothold to extract. How the Cloudflare dashboard account itself is protected (2FA / SSO / admin-seat count) is not confirmed here, though the `state.json` snapshot likely captures part of it. §6.7, §8.8

### V-19: Unpinned ingress image (cloudflared:latest)

**Verdict:** 🟡 Bounded | **Category:** `Supply chain`


The sole ingress component is pulled by mutable tag, as are a few first-party Go proxies and mineru — no digest pin, so a bad upstream image lands on restart. Realistic only via upstream registry compromise. Base/tool images are Docker Hardened Images and the prod path runs a Grype scan. The public R2 wheel bucket is a read-only public-exposure issue, not an injection path unless write access is separately compromised. §9.2, §9.4, §8.2, §7A.5, §6.5

Needs-evidence

### V-08: Rogue OAuth-app consent grant (Workspace)

**Verdict:** 🔵 Needs Evidence | **Category:** `Identity`


Whether Google Workspace restricts third-party OAuth app access (unconfigured = open; restricted = blocked). Not derivable from any repo or the cluster. **Would need:** the Workspace app-access / API-controls settings.

### V-09: Staging holds real PHI

**Verdict:** 🔵 Needs Evidence | **Category:** `Data · developer access`


Every enrolled `@n1.healthcare` device can read the staging DB and Redis, read-only — a broad internal surface (verified, §6.7). Whether those are real or synthetic records decides severity. No seed script, fixture, or prod→staging copy job exists in any repo, and `synthetic-medical-reports` is an OCR-training generator, not a staging seeder — the absence leans toward organic (possibly real) data, but that's inference. **Would need:** staging Aurora account emails / ages, or the `automated-testing` image entrypoint.

Blocked

### V-05: Broken object-level access (IDOR) on patient records

**Verdict:** 🟢 Blocked | **Category:** `Application · API`


Object-level authorization is enforced at the router mount, not scattered per handler. Every PHI router is `APIRouter(dependencies=[Depends(phi_scope_for(...))])` (`records.py:57,59`) → `authorize()` (`policy.py:555,624`), requiring the caller to be the data subject **or** hold a `completed=True` doctor-patient association (`auth_service_client.py:164`; pending associations don't count). A CI test fails the build if any route lacks a guard (`tests/unit/test_route_coverage.py`); a second targets the IDOR class (`tests/security/test_authz_full_audit.py`). No bare lookup-by-path-id without an ownership check was found.

### V-06: SSRF / injection in api-backend

**Verdict:** 🟢 Blocked | **Category:** `Application · API`


No user-controlled outbound-URL sink exists — every outbound URL is from environment config (`support.py:39`, `base.py:721`, `hydra_auth.py:106`). The one `requests.post(external_api_url,...)` is inside a docstring example (`exceptions.py:495`), not live code. SQL is SQLAlchemy ORM / parameterized; the two f-string SQL spots are a hardcoded isolation-level literal (`biomarkers_service.py:53`) and migration DDL. `subprocess` is test-only; no `os.system` / `eval` on user input.

### V-17: Direct attack on AWS infrastructure

**Verdict:** 🟢 Blocked | **Category:** `Cloud · network`


Nothing to scan or connect to in AWS — ingress is a Cloudflare Tunnel that dials outward; no public IPs, load balancers, or inbound ports. The EKS API server is public but IAM/OIDC-authenticated and held by three accounts. This concentrates risk onto the edge (V-18) and identity (V-11). §17.1, §8.7

Amplifiers

### V-12: Flat pod network — free lateral movement

**Verdict:** ⚠️ Threat Amplifier | **Category:** `Kubernetes`


Each cluster has exactly two NetworkPolicies, both for Prometheus scraping; pod-to-pod traffic is otherwise unrestricted (NETWORK-SERVICES NS-1). Not a way in — it turns one compromised pod into reach across the whole cluster, and it is what makes V-07's local-admin bypass reachable (any pod → `argocd-server:8080`). Staging and prod remain separate VPCs with no link.

### V-14: No human gate after a merge to main

**Verdict:** ⚠️ Threat Amplifier | **Category:** `Source & CI/CD`


The deploy-approval step exists but is commented out of the shared workflow, so a merge to main ships to production with no second checkpoint. It removes the catch after the merge gate, so the entire defense collapses onto the PR review. Mitigated by SHA-pinned actions, safe-chain, and a Grype scan on the prod path. §17.3, §7A.5

### V-16: Mass exfiltration via valid credentials

**Verdict:** ⚠️ Threat Amplifier | **Category:** `Data · the objective`


The objective, not an entry point — it only happens after another vector succeeds. S3 is fully public-access-blocked and KMS-encrypted at rest, so accidental exposure isn't the risk; abuse via valid credentials is. The missing control is detection of bulk reads and unusual egress through the single NAT. §8.4, §8.7, §17.4

## 04 · What to act on, in priority order

1. **Disable the ArgoCD local `admin` account** (`admin.enabled: "false"`) — closes the in-cluster bypass of Cloudflare Access. *(V-07 A)*
2. **Scope the ArgoCD Access service-token policy** to a named token, or drop policy #3. *(V-07 B)*
3. **Add NetworkPolicies** to the `argocd` and app namespaces — defangs V-07 A/B and is the V-12 fix.
4. **Confirm the tunnel targets `argocd-server-proxy:8888`**, not raw `:8080`; reconcile the service drift. *(V-07 C)*
5. **Patch the parser-gate path-traversal** at `office.py:141,191`. *(V-02)*
6. **Endpoints (V-01)** — no EDR; the keystone. Watch for session-token theft and unusual access from known-good devices.
7. **Data-read volume & NAT egress (V-16)** — bulk reads from Aurora / S3 are not monitored.
8. **Answer V-09 at the console** — real or synthetic PHI in staging.
9. **Out-of-band alerting (V-20)** — an alert path independent of Google and Slack.
10. **DNS hygiene (V-04)** — claim or remove the dangling `plan.n1-research.com` CNAME.

Open questions

| Question | Status |
| --- | --- |
| Does staging hold real or synthetic PHI? | Open — narrowed (no seeder in any repo) |
| How is the Cloudflare dashboard account protected? | Open — snapshot may close it |
| Does Google Workspace restrict third-party OAuth apps? | Open — Workspace console |
| Does the tunnel route ArgoCD through the jwt-proxy (`:8888`)? | Open — confirm tunnel ingress target |
Verdicts reflect controls as configured on **2026-06-11** (production cluster `191421493115`) and the Cloudflare snapshot of **2026-06-08**, not as continuously re-verified against live config. Items marked Needs-evidence / Open are questions to resolve, not confirmed exposures. Method: `n1-adversarial` — a claim ships only with the artifact that backs it.