The model proposes. It never decides, and it never acts alone.
Every action an AI agent wants to take is checked against explicit rules before it happens — not logged after the fact, not caught by a periodic review. If a proposed action doesn't match policy, it doesn't execute. There is no path from "the model wants to" to "it happened" that skips this check.
Propose → govern → execute
Propose
The model reasons over the request and produces a proposed action — a query, a write, a call to an external system, a document it wants to send. At this stage the proposal is just data; nothing has happened yet.
Govern
The proposed action is checked against explicit, human-authored policy: is this action within the model's permitted scope, does it touch data the requester is allowed to touch, does it require a specific human sign-off before it can proceed. This check happens outside the model, on infrastructure the model doesn't control and can't reason its way around.
Execute
Only an action that passes governance reaches the systems that can actually change something. An action that fails, or that needs a human decision the request didn't include, stops here — it doesn't execute in a degraded or partial form; it doesn't happen.
Deterministic, not probabilistic
Most AI safety controls today are probabilistic — a classifier scores an output, a filter flags likely-bad content, a monitor watches for anomalies. Those tools catch a lot, but by construction they can be fooled, and they're evaluated after the fact. Luminous's enforcement layer works differently: actions are checked against an explicit, human-authored whitelist of what's permitted, not scored for how suspicious they look. An action either matches a permitted pattern or it doesn't — there's no confidence threshold to tune, no score to game. That's the practical difference between "probably fine" and "structurally can't happen."
The model never authors the query it's granted
A common failure mode in AI deployments is a model that both decides what to look up and is trusted to say what it looked up — the same component sets the question and reports the answer, with nothing independent in between. Luminous separates those roles structurally: the model can request, but a separate control decides what's actually retrieved and executed, and that boundary holds even if the model is compromised, confused, or deliberately manipulated by a prompt injected into its input.
Access control that's actually enforced, not just configured
Role-based access is table stakes; the gap in most AI deployments is that row-level security (RLS), column-level security (CLS), and attribute-based access control (ABAC) get configured in the data layer but aren't actually re-checked at the moment an AI agent asks for data. Luminous enforces RLS/CLS/ABAC mechanically, at the point of access, every time — not as a policy the model is trusted to respect, but as a gate the request has to pass through regardless of what the model intended.
Closing the TOCTOU gap
A classic security race condition — time-of-check-to-time-of-use (TOCTOU) — happens when a system checks whether an action is authorized, and then some time later actually performs it, leaving a window where conditions changed but the authorization didn't get re-checked. Luminous re-derives authentication and authorization at every stage of a request, not once at the start — identity and permission are checked again at the moment an action actually executes, not assumed to still hold from a check made earlier in the pipeline.
Human authorization for what can't be undone
For actions that are reversible — most reads, most drafts — the governance check is enough. For actions that can't be undone — sending an email, executing a trade, releasing a document, moving money — the platform requires a specific person to authorize that specific action before it executes. Not a standing approval, not a session-level "yes" given once at the start. If the authorization doesn't match exactly what's about to happen, the action doesn't proceed. How that approval is bound to the action →
Least privilege, made structural
An AI agent acting on someone's behalf never has more access than that person does, and in most deployments has less — access is evaluated per request against what the specific task needs, not granted up front as a standing role. That's the difference between "this agent could theoretically do a lot of damage but we trust it not to" and "this agent structurally cannot take an action outside what was authorized for this task."