Authorization Boundary
The Authorization Boundary is the layer between LLM intent and action commit. It is the protocol's signature property: no LLM is in the authorization path.
Think of it as the structural separation between probabilistic intent and the layer that decides whether an action commits. Other tools filter what the model says. Execution controls what the model is allowed to do.
What it does
The boundary evaluates a structured intent against a set of policy rules and emits one of three verdicts:
- pass — proceed to scoring and execution.
- block — stop. The caller receives a structured error with the failing rule, the offending field, and a remediation array.
- escalate — pause. The action is held until an approval-chain signature is received (or the TTL expires).
Rules are structured and evaluated consistently against the inputs. No probabilistic models, no LLM-as-judge. Inspectable, reviewable, version-controlled.
Why this matters
Every other agent-safety product in the market sits inside the LLM loop. NVIDIA NeMo Guardrails filters what the LLM produces. OpenAI moderation inspects outputs. Constitutional AI steers the model's behavior. All of those are valuable, and all of them share a property: the LLM is still in the path that decides whether a real-world action commits.
The Authorization Boundary is the architectural separation that breaks that property. When an action reaches the boundary, the LLM has already done its job — the boundary evaluates a structured request against rule-defined policy. A prompt-injected agent cannot persuade the boundary, because the boundary does not read prose.
How it fits
intent ─▶ policy ─▶ BOUNDARY ─▶ score ─▶ execute ─▶ receipt
│
▼ (if block)
structured error
with remediation
Rule families
Two rule families ship with the protocol. You add more.
Hard-deny list
- What it is
- Action classes that are never allowed regardless of delegation. e.g., export_pii, delete_audit_log, disable_boundary.
- Best for
- Actions that should never be permitted by any agent for any reason.
Delegation evaluation
- What it is
- Compares requested resource consumption (amount, scope, duration) against the delegation token bound to the action.
- Best for
- Per-agent, per-action quantitative limits.
Performance characteristics
The boundary runs as a pure function of the action + the resolved policy version. Evaluation cost is linear in the number of active rules; rules per evaluation is unbounded by design. Concrete latency numbers will publish on the status page once the hosted service exits private beta — until then, treat any numbers below as design targets, not measurements.
| Metric | Production target |
|---|---|
| p50 evaluation | < 2ms |
| p99 evaluation | < 5ms |
| Rules per evaluation | unbounded (linear) |
Failure modes
- Replay attack — same intent submitted twice with the same delegation. Mitigated by the action's idempotency key + delegation single-use semantics.
- Policy drift — rules updated without versioning. Mitigated by rule
versioning and a per-action
policy_versionstamp recorded in the receipt. - Insider rule bypass — a privileged actor disables a rule. Mitigated by
audit-log immutability and the hard-deny rule for
disable_boundary.
See it in action
Open the sandbox and click "Transfer $99,999 from treasury" or "Export all customer PII". The boundary halts both before they reach commit, with distinct error codes and distinct remediation paths.