01
Identity and ownership
A worker is designed to carry a persistent role, an accountable owner, a mandate, and lifecycle state. That keeps work attributable beyond one model session.
Security model
Security is a system of boundaries, not a badge.
AI work crosses models, tools, data, and infrastructure. LumeGrid is being built so authority is explicit before execution and evidence remains attached afterward.
Current posture: private development with design partners. Architecture-backed claims are separated from customer-ready availability below.
Control boundaries
What the platform is designed to control.
02
Scoped capabilities
Tools and data are granted to a role for a defined purpose. Broad credentials and permanent authority are treated as risks, not conveniences.
03
Action authorization
New workers begin proposal-only. Review requirements can be set by action class; bounded authority remains inside an explicit operating charter.
04
Pause and containment
The operating model includes the ability to pause a worker or wider operation and to restrict protective actions to an explicit safe set.
05
Durable execution
Multi-step work is designed to preserve state across retries, interruptions, and review waits instead of silently restarting from a prompt.
06
Evidence continuity
Intent, identity, policy decisions, approvals, execution, and outcomes are designed to remain connected in an inspectable record.
Threat model
Assume models and tools can fail.
The product direction starts from failure modes, not a promise that inference is always correct.
- Prompt or tool abuse
- Limit capabilities and evaluate the requested action against the worker's mandate and policy.
- Over-privileged access
- Prefer purpose-bound grants, tenant scope, expiry, and revocation over a reusable master credential.
- Unexpected autonomy
- Start proposal-only; permit bounded action classes only through explicit policy and operating charters.
- Interrupted work
- Preserve durable state, retries, and review waits so recovery does not erase the trail.
- Runaway cost
- Apply a tenant-level spend ceiling and stop conditions before work continues.
- Control drift
- Keep authority changes and outcomes inspectable so operators can see when the system departs from intent.
Security controls
Controls with explicit evidence and limits.
The architecture treats identity, authorization, isolation, secrets, audit history, privacy, and containment as separate boundaries. Each statement below says what the control supports—and what it does not prove.
S-01
Purpose-scoped grants
Sensitive dispatch paths can check principal, purpose, scope, expiry, and revocation. Some low-risk system paths are intentionally allowlisted, so this is not presented as a universal gate.
S-02
Row-level tenant isolation
Tenant-scoped Postgres records are built around forced row-level security and policy binding. Repository audits verify the structure, not the live state of every deployment.
S-03
Encrypted credentials
Credential storage uses envelope encryption with tenant-bound key wrapping and scoped access; production code refuses the in-memory development fallback.
S-04
Hash-chained audit records
Recorded tenant audit entries are append-only and hash/Merkle chained so later verification can surface modification. Legal holds are excluded from ordinary rotation.
S-05
Configurable PII controls
Tenant policy can require PII redaction before a model-provider request. The control is configurable, not a claim that no personal information can ever leave the system.
S-06
Containment and incident evidence
The platform includes pause, quarantine, incident-lifecycle, reporting, and verification-drill evidence surfaces without claiming an unverified response-time SLA.
Claim register
What is supported. What is still being proven.
| Area | Status | Plain-language evidence |
|---|---|---|
| Configurable supported roles | Private development | Role, mandate, cadence, and authority configuration exists in the platform; the complete customer path is still being verified. |
| Proposal-only start | Architecture-backed | Workers can begin without action authority and escalate consequential work for review. |
| Bounded autonomy | Architecture-backed | The platform supports authority bands and signed operating charters; out-of-bound work returns for review. |
| Tenant-level spend ceiling | Architecture-backed | A tenant-level hard cap is the grounded control. Per-worker budget enforcement is not yet claimed here. |
| Action evidence | Architecture-backed | Operational receipts are tamper-evident and linked. Cryptographic signatures protect signed approvals and document/evidence flows. |
| Tenant data isolation | Structurally audited | Tenant-scoped Postgres records use forced row-level security and bound policies. This is architecture evidence, not a live production attestation. |
| Privacy and compliance flows | Private development | Privacy-rights records, multi-role compliance reviews, trust artifacts, and security evidence surfaces exist; customer reachability varies by deployment. |
| Enterprise identity | Private surface | SAML/OIDC configuration, SCIM provisioning, hierarchical roles, MFA policy, and IP allowlist surfaces are implemented for private tenant use. |
| Managed / self-hosted / isolated | Design direction | Deployment requirements are evaluated with each design partner; public availability is not implied. |
| SOC 2 / ISO / HIPAA / FedRAMP | Not claimed | LumeGrid does not present unearned certifications or regulated-compliance status as current fact. |
Security questions
Ask for the boundary, the evidence, and the current status.
Send architecture, disclosure, or data-handling questions to [email protected]. For electronic signature details, read the dedicated compliance note.