Non-bypassable execution authorization for AI agents.
Deterministic boundary: (intent, state, policy) → ALLOW | DENY
No authorization → no execution.
Agents propose actions.
OxDeAI decides if they are allowed to execute.
No valid authorization → execution is unreachable.
Authorization is evaluated before any side effect is reachable.
OxDeAI introduces an explicit decision phase:
proposal → authorization → execution
(intent, state, policy) → deterministic decision
intent: proposed actionstate: evaluation contextpolicy: rule set
If ALLOW → emits AuthorizationV1
If DENY → execution is unreachable
- No authorization → no execution
- (intent, state, policy) → deterministic ALLOW | DENY
- Same input → same decision
- Verification failure → fail closed
OxDeAI enforces a strict invariant:
No authorization → no execution
All tool calls MUST pass through the PEP Gateway:
- authorization verified before execution
- intent hash must match canonical input
- replay protection enforced
- fail-closed by default
There is no execution path outside the boundary.
The agent cannot call tools directly. All execution goes through a PEP Gateway.
Agent → Gateway → Protected Upstream
↘ direct call → 403
ALLOW→ executedDENY→ blockedREPLAY→ blockedBYPASS→ rejected
No valid authorization → no execution path
export UPSTREAM_EXECUTOR_TOKEN=demo-internal-token
node examples/non-bypassable-demo/protected-upstream.mjs
node examples/non-bypassable-demo/pep-gateway.mjs
node examples/non-bypassable-demo/agent.mjsWithout an execution boundary:
- retries duplicate side effects
- budgets leak
- permissions drift
- control lives inside the model loop
You are relying on best-effort enforcement.
OxDeAI makes execution conditional.
Most agent systems control behavior.
OxDeAI controls execution.
Without an execution boundary, agents are not production-safe.
OxDeAI is not a replacement for inline PDP/PEP authorization.
Inline or sidecar policy evaluation (OPA, Cedar, Cerbos) is the simpler baseline and should generally be preferred.
A detachable authorization artifact is justified in two cases:
- Independent verification — the party that must verify the authorization is not the party that ran the decision point or controls the enforcement log (counterparty, auditor, regulator). Decision logs are evidence the operator produced about the operator's own enforcement.
- Unreachable premises — the executor cannot reach the authoritative inputs required to re-evaluate locally, across a separate trust/network zone or third-party boundary.
Topology alone does not justify it. Separate processes or multiple enforcement points are solved by placing a decision point next to the executor.
When neither condition applies, do not make the decision detachable.
This boundary came out of a public exchange with a Cerbos maintainer: r/AskNetsec thread · applicability discussion
- Agent proposes an action
- OxDeAI evaluates
(intent, state, policy) ALLOW→ AuthorizationV1 issued- Gateway verifies authorization
- Execution becomes reachable
DENY → blocked before any side effect
- unintended execution
- duplicate or replayed actions
- budget overruns
- permission leakage
- non-reproducible decisions
- Prompt guardrails → probabilistic
- Monitoring → after execution
- OxDeAI → deterministic, before execution
Logs explain what happened. Authorization artifacts prove what was allowed.
OxDeAI is validated through verifiable invariants, not claims:
- frozen canonicalization vectors
- cross-language verification (TypeScript / Go / Python)
- conformance suite (CI validated)
- cross-adapter equivalence
pnpm test:vectors:allAll implementations produce identical canonical bytes and hashes.
OxDeAI is a protocol composed of:
- Canonicalization → deterministic bytes
- ETA Core → decision function
- Conformance → verification rules
- PEP Gateway → enforcement boundary
→ Implementation paths
docs/spec/**- normative protocol definitionsdocs/**- non-normative guides and examples; if there is a conflict,docs/spec/**wins
OxDeAI is not a global authority.
- Any system can issue authorization
- Signature ≠ trust
- Trust is configured by the verifier
verifyAuthorization(auth, {
mode: "strict",
trustedKeySets: [...],
});No trust configuration → fail closed
| Concept | Controlled by |
|---|---|
| Issuer | Any system |
| Trusted keys | Verifier |
| Execution gate | OxDeAI |
The repository itself is protected by a deterministic pre-merge authorization boundary.
findings + exceptions + policy → ALLOW | DENY
- No valid exception → no merge path
- High/critical findings → always DENY
The gate can emit a verifiable decision artifact (integrity proof).
Same principle: No valid justification → no merge No valid authorization → no execution
Prerequisites:
- Node.js 20+
- pnpm 9+
git clone https://github.com/oxdeai/oxdeai.git
cd oxdeai
pnpm install
pnpm build
export OXDEAI_ENGINE_SECRET='test-secret-must-be-at-least-32-chars!!'
pnpm -C examples/openclaw start
---
Runs an OpenClaw agent with enforced execution authorization.
## Delegated Authorization
Delegation behaves like a capability system:
```text
parent → AuthorizationV1 (budget=1000)
↓
DelegationV1 (max=300)
↓
child → verifyDelegationChain() → execute / DENYProperties:
- strictly narrowing
- single-hop
- locally verifiable
- cryptographically bound (Ed25519)
- deterministic evaluation
- fail-closed execution
- replay protection
- evaluation isolation
- cross-runtime equivalence
- ~80–150µs overhead per action (p50)
- negligible vs agent execution time
Maintained TypeScript adapters:
- LangGraph (LangGraph.js)
- OpenAI Agents SDK (JS/TS)
- OpenClaw
Adapter-shape bindings (TypeScript; Python-native adapters for these frameworks are not yet published):
- CrewAI
- AutoGen
All adapters produce identical outcomes:
ALLOW / ALLOW / DENY / verifyEnvelope() => ok
- execution authorization protocol
- deterministic decision layer
- pre-execution enforcement
- cryptographic authorization artifacts
- not an agent framework
- not a prompt guardrail
- not a monitoring system
- not heuristic runtime logic
- not a replacement for inline PDP/PEP authorization
| Artifact | Status |
|---|---|
| AuthorizationV1 | Stable |
| DelegationV1 | Stable |
| VerificationEnvelopeV1 | Draft |
| ExecutionReceiptV1 | Planned |
Artifacts are portable:
- TypeScript (reference)
- Go
- Python
Verification works across runtimes.
Agents moved from answering → acting.
Execution is now the risk surface.
- Prompt guardrails shape behavior
- OxDeAI controls execution
Probabilistic control < Deterministic authorization
Agents propose actions. OxDeAI decides if they can execute.
No authorization → no execution.