Enterprise AI needs a doorway for routed action.
AI can change files, call tools, update systems, and start workflows. ZLAR puts a rule in front of the actions a deployment routes through it. The rule can allow, block, or ask a person.
The hard part is not AI writing. It is AI doing.
The model can be useful and still need a door. When it is about to touch a repo, a task record, a customer record, a workflow, or a system setting, someone needs to know what rule applies.
Without that door, every new AI capability adds more watching. People hesitate because no one can point to the place where the action is checked.
Bring one real action: what can pass, what must stop, and what needs a yes?
The rule comes before the action.
Allow, block, or ask
ZLAR checks routed actions against signed rules before they proceed.
The yes is separate
Important actions can ask a named person outside the AI's runtime. Silence is not consent.
The action leaves a receipt
The receipt records what counted as authorized effect when the AI tried to act.
Start with one real action.
Pick a concrete action: a repo change, deployment step, sensitive file edit, internal workflow trigger, MCP tool call, or record movement. Define what is allowed, what is blocked, and when a person must say yes.
The point is not to slow every action down. The point is to make the important yes real and leave proof afterward.
Next action
Bring one action class. Name the route, policy, receipt, refusal rule, and side doors before discussing anything broader.
Boundary
- ZLAR governs routed/intercepted action surfaces only.
- It does not replace IAM, SIEM, DLP, endpoint controls, model risk, legal review, or security architecture.
- Serious deployment closes bypass paths with sandbox, OS, network, and platform controls.
- Safe Codex wording: "ZLAR can govern Codex CLI-invoked MCP tool calls when those MCP servers are routed through ZLAR."