Threat model
Understand protected assets, hostile inputs, trust boundaries, and the gates required before sensitive use.
Lumen assumes research execution is hostile. Prompts, retrieved pages, model output, generated code, notebook content, uploaded files, connector data, extension metadata, browser input, and sandbox files may all be malicious or simply wrong. A useful result does not make its producer trusted.
This page describes the target security boundary and the evidence required to activate it. Slice 0 implements a deterministic local story and typed seams; it does not establish multi-tenant, hosted compute, or sensitive-data readiness.
Assets and authority
The protected assets are workspace data, identity and membership, canonical PostgreSQL state, immutable artifact bytes, workflow control, budgets, audit history, provider credentials, connector authority, and external side effects. The browser may request product commands but cannot mutate research tables directly. An attempt process may compute with declared inputs but cannot administer the database, workflow service, object store, compute provider, connector, or model account.
PostgreSQL is canonical for semantic state. Immutable object storage is canonical for artifact bytes. Durable workflow history coordinates work but is not a second product database. Sandboxes and attempt processes are disposable.
Principal threat paths
| Threat | Likely path | Required control and evidence |
|---|---|---|
| Cross-workspace access | Forged ID, missing tenant predicate, guessed artifact key | Composite tenant ownership, authorization on every read and command, negative cross-workspace tests |
| Prompt or source injection | Retrieved content asks the model to reveal data or call an unrelated tool | Untrusted-content labels, generated allowlisted tools, scoped capability, approval and egress enforcement |
| Credential escape | Environment inheritance, browser bundle, logs, notebook output, sandbox inspection | Role-specific secret storage, scrubbed child environments, redaction and canary scans, no raw provider key in compute |
| Unauthorized side effect | Replayed or mutated tool call, approval mismatch, ambiguous retry | Typed arguments, generation fencing, one-use authority, durable approval, idempotency identity and reconciliation |
| Artifact substitution | Staging overwrite, wrong digest or media type, tenant-key collision | Hostile staging, trusted streaming verification, create-only promotion, manifest and ownership checks |
| Executable-content compromise | Notebook HTML, preview, terminal or extension metadata reaches a privileged origin | Sanitized or isolated rendering, strict content policy, filtered runtime protocol, no imported executable hooks |
| Denial or cost exhaustion | Agent fan-out, oversized output, retry loop, provider quota | Nested budgets, concurrency and size limits, cancellation, externalization, circuit breakers and measured load gates |
| Recovery corruption | Duplicate delivery, process death, notification loss, stale generation resumes | Idempotent commands, monotonic durable events, reconciliation, immutable failed attempts and restart tests |
Boundary rules
Authority narrows toward compute. The trusted app accepts authenticated, typed commands and enforces workspace policy. The worker coordinates provider administration and verification. An attempt gets only expiring capabilities bound to its workspace, project, run, attempt, generation, allowed action, budget, and audience. It uploads to staging; a trusted process verifies bytes before immutable promotion.
Default-deny egress and a policy document are not interchangeable. The selected image, provider class, network path, and tool gateway must reject direct administrative endpoints and arbitrary destinations in runtime tests. Approval is also not evidence that an action happened: only the trusted gateway's recorded execution and reconciled provider identity establish that fact.
Admission gates
Before real credentials or sensitive data are admitted, prove normal and denied access, cross-workspace isolation, capability replay and expiry, budget exhaustion, cancellation, duplicate delivery, ambiguous provider outcomes, artifact tampering, renderer injection, secret canaries, process restart, backup/restore, and incident recovery at the actual boundary. Dependency, license, provenance, SBOM, static-tree, and full-history secret checks remain separate gates.
The release may state only the environment and data classes those checks cover. It must not turn a scanner result, architecture diagram, or local fake into a compliance or production-security claim.
Reporting and response
Report a suspected vulnerability through the private process in Security reporting. Do not test with accounts, services, or data you do not own. On suspected exposure, stop the affected capability, preserve access-controlled evidence, revoke or rotate credentials, reconcile external side effects, and rerun the exact failed boundary before reactivation.
Continue with isolation, network and tool policy, and artifact verification for boundary-specific controls.