The Shape of the Problem
When an AI agent takes real-world actions — purchases, bookings, API calls, message sending, government submissions — the policy questions you need to answer are specific:
- Can this agent spend more than $X on this purchase?
- Has it spent more than $Y in the last 24 hours, cumulatively?
- Is the counterparty domain in the allowlist? At what trust level?
- Is this a routine action or one that requires a human signoff?
- After the action completes, can the recipient prove it was authorized?
These look like access control questions, but they aren't quite. They're decisions over individual actions with their own attributes, in a context that includes recent history, cost thresholds, counterparty trust, and obligations like "require approval" or "step up auth." And once the decision is made, the question of proving it — to the recipient, to an auditor, to a compliance officer — matters as much as the decision itself.
What's Already Available
The OSS authorization stack already has good tools. None are designed for this specific shape of question.
OPA (Open Policy Agent) is a general-purpose policy engine, written in Go, evaluating Rego policies against structured JSON. It's used widely for Kubernetes admission, Envoy authorization, and microservice authz. It's stateless, expressive, and CNCF-graduated. (Detailed comparison →)
Cedar is AWS's open-source policy language and library, written in Rust, embeddable directly in applications. It targets RBAC and ABAC use cases over principal/action/resource tuples, with a notable formal verification capability via its symbolic compiler. (Detailed comparison →)
OpenFGA is a relationship-based authorization service inspired by Google Zanzibar. It models permissions as relationship tuples and answers traversal queries — the right tool for SaaS sharing semantics where Alice can view Document X because she's a member of the project that owns the folder it's in. (Detailed comparison →)
Each is excellent for what it's designed for. None of them ship with the surrounding pieces an autonomous agent needs.
Where They Stop
A general-purpose policy engine like OPA gives you the decision. It doesn't give you:
- An identity model for the agent making the request
- A signing scheme that prevents replays and confirms the agent is who it claims to be
- A state machine for human-in-the-loop approvals when a policy says "ask first"
- A cryptographic proof token the counterparty can verify offline, without calling back into your system
- An audit log structured for compliance review, scoped per agent and per organization
For OPA's traditional use cases — Kubernetes admission, microservice authorization — those pieces don't matter. The host system already has identity (the kubelet, the service mesh), already has audit (the API server, OpenTelemetry), and the decision consumer is the calling service itself, not some third party who needs to prove the action was approved.
For autonomous AI agents, those pieces do matter, and you have to build them yourself. Or you adopt something that bundles them.
What "AI-Agent-Specific" Actually Means
When we say OpenLeash is opinionated for AI agents, we mean five concrete things.
1. Agent identity. Agents register with Ed25519 keypairs and sign every authorization request. The signature includes a timestamp and a single-use nonce. OpenLeash verifies the signature, the timestamp window, and that the nonce hasn't been seen before — before evaluating any policy. An agent can't lie about who it is, and a captured request can't be replayed.
2. Approval workflow. When a policy returns
REQUIRE_APPROVAL, OpenLeash creates a pending approval request that an
owner reviews in a portal and approves or denies. The approval token is single-use,
action-scoped, and time-limited — the agent gets it back, includes it on a follow-up
authorize call, and then proceeds. State machine, audit log, retry semantics, all
built in.
3. Cryptographic proof tokens. Every approved action returns a PASETO v4.public token signed with Ed25519. The token binds the decision to the specific action — it includes the action ID and a hash of the canonical action body — so it can't be reused for a different action. Any counterparty can verify the token offline with the public key. There's no "phone home" required.
4. Append-only audit log. Every authorization attempt, every approval, every policy change is recorded in a JSONL audit log scoped per user, organization, and agent. The log is the receipt for compliance review.
5. Action-level YAML policies. Policies are constraints
(cost <= 100, cumulative_spend_24h < 500,
counterparty_trust >= MEDIUM) and obligations
(HUMAN_APPROVAL, STEP_UP_AUTH, DEPOSIT).
Schema-validated YAML, version-controlled in your repo, reviewable by a non-engineer
compliance officer without learning Rego.
The Tradeoffs
OpenLeash is opinionated, and being opinionated has costs.
YAML is less expressive than Rego. If your policy logic needs iteration over arbitrary data structures, recursive rule evaluation, or partial evaluation across a complex policy bundle, OpenLeash YAML won't get you there. You should be using OPA. We picked YAML because for the agent-governance domain, the constraint-and-obligation model covers what you actually need to express, and the simplicity makes the policies reviewable by people who aren't engineers — the compliance officer, the head of finance, the operations lead.
A sidecar service has different operational characteristics than an embedded library. Cedar can be embedded directly in your Rust application. OpenLeash runs as a separate process. That means an extra deployment surface, an extra HTTP hop, and an extra failure mode to think about. We chose a sidecar because the agent's process and the authorization process want different operational properties — the policy engine should outlive any specific agent run, and the audit log shouldn't be lost when the agent crashes.
Some of OPA's flexibility is gone. Rego can express almost any policy logic. OpenLeash YAML is intentionally less powerful. We picked simplicity over generality because the domain is narrow — agents take a small number of action types with predictable attributes — and a constrained language makes mistakes harder.
Where This Fits in Your Stack
If you already use OPA for Kubernetes admission, keep using it. OpenLeash isn't trying to replace your infrastructure policy engine.
If you use OAuth for delegated access between services, keep using it. OpenLeash isn't an OAuth replacement — it complements OAuth by adding per-action authorization on top of API-level access. (Comparison →)
If you use OpenFGA or Cedar for in-application access decisions, keep using those. OpenLeash sits at a different layer — outside the application, between the agent and its actions.
The intended deployment is: your application keeps its existing authz stack. You add OpenLeash as a sidecar specifically for AI agents that take side-effectful actions in or alongside your application. The agent calls OpenLeash before each action, gets a decision and (if allowed) a proof token, and proceeds. Your audit trail now has a per-action record with a verifiable cryptographic receipt.
Get Started
OpenLeash is Apache-2.0 and runs locally. Install with
npm install -g @openleash/cli or the
one-liner installer, run
openleash wizard to create your first owner / agent / policy, and you
have a working sidecar on 127.0.0.1:8787 in about ninety seconds. SDKs
are at endpoint parity for
TypeScript,
Python, and
Go.
The full comparison pages — vs OPA, vs Cedar, vs OpenFGA — go deeper into when to use each tool. They're written to be honest, not boosterish: each has a section explicitly recommending the alternative when it's the better fit.
If you're already running an autonomous AI agent in production and you're solving these problems with bespoke glue, we'd like to hear what you've built — and whether OpenLeash would have saved you the trouble. Issues and discussions are open on GitHub.