← Back to blog
VisionApril 27, 2026·8 min read

Why we built AuthzX

Every software team eventually hits the same wall: who is allowed to do what?

The first version is always the same. A few if statements. A role column on the users table. Maybe an isAdmin flag. It works for a while. Then requirements compound: multi-tenancy, attribute-based rules, compliance constraints, audit trails, time-bounded access. The ad-hoc if checks metastasize into something nobody wants to touch. Authorization becomes the scariest part of the codebase.

The landscape is fragmented

There are good tools out there. OPA gives you a powerful policy language in Rego, but it's raw infrastructure — you still need to build the dashboard, the SDK layer, the policy distribution, the audit trail, and the management API yourself. That's months of plumbing before you enforce a single rule.

Managed platforms like Permit.io and Cerbos offer better DX — dashboards, SDKs, Terraform providers — but their architectures are shaped around RBAC or ABAC for traditional web applications. They were built before AI agents entered the picture.

On the other end, OpenFGA and SpiceDB are relationship-based (ReBAC) systems — powerful for modeling ownership graphs, but a heavyweight choice if your access model is fundamentally attribute-and-role-based.

None of them are built for a world where an AI agent is calling tools on behalf of a user, and you need to authorize that tool call in the same engine that authorizes your human users.

The AI agent gap

This is what pushed us to build AuthzX.

AI agents are proliferating. They call APIs, invoke tools, access databases, interact with external services — all on behalf of human users. The authorization question is no longer just “can this user do this action on this resource?” It's “can this agent, acting on behalf of this user, invoke this tool, in this context?”

Most teams solve this with bespoke middleware — a pre-check before each tool call, hardcoded to the specific agent framework. It works until you have five agents, three frameworks, and compliance asking for an audit trail of every tool invocation.

We wanted one policy engine that treats AI agents as first-class subjects. The same policies that authorize your human users should authorize your agents. The same audit trail that tracks a user's actions should track agent tool calls. No separate system, no glue code, no drift.

What we designed for

We set out with a specific set of constraints:

  • One engine for everything. Users, services, AI agents — all subjects, all evaluated by the same policy engine, all visible in the same audit trail.
  • Sub-millisecond local evaluation. Authorization checks happen on every request. They need to be fast enough that developers never consider skipping them. Our local agent evaluates policies in hundreds of microseconds — no network round-trip, no latency tax.
  • Terraform-first policy management. Policies are code. They should live in version control, go through pull request review, and deploy through CI/CD pipelines. We built a first-class Terraform provider so teams can manage their entire authorization configuration declaratively.
  • Full observability. Every authorization decision should be queryable. Who was denied? Which policy blocked them? How is decision volume trending? The dashboard isn't an afterthought — it's the reason customers stay.
  • ABAC + RBAC, not religion. We support attribute-based and role-based access control. Not because one is universally better, but because real systems need both. Roles for coarse-grained structure, attributes for fine-grained conditions.

How it works

AuthzX has three layers:

  1. Cloud control plane. This is where you define applications, subjects, resources, roles, and policies. The admin dashboard gives you visibility into everything — decision logs, hotspots, trends, schema. The API and Terraform provider give you programmatic control.
  2. Local agent (AuthzX Agent). A lightweight Go binary that runs alongside your application. It syncs policies from the cloud, evaluates authorization checks locally, and forwards audit logs back. Zero-config, sub-ms decisions, graceful degradation if the cloud is unreachable.
  3. SDKs and integrations. Go, Node.js, and Python SDKs wrap the authorization API. The MCP adapter lets AI agent frameworks authorize tool calls through AuthzX with a single function call.

Honest positioning

We're not building a better policy engine. OPA's Rego is a proven, well-understood language — we use it under the hood. We're not pioneering a new access control model. ABAC + RBAC is the mainstream path, and it covers the vast majority of real-world authorization needs.

What we are building is a better developer experience around authorization. The gap between “powerful policy engine” and “product teams can actually use this” is enormous. That gap is where AuthzX lives.

And we're claiming the AI agent authorization space. Not because it's trendy, but because it's a real problem that's about to get much bigger, and nobody else is building for it yet.

What's next

AuthzX v1 is live and free during Early Access. You can sign up, create your first application, define policies, deploy the local agent, and start authorizing — users, services, and AI agents — in under 10 minutes.

We're a solo founder building in public. The roadmap is ambitious: policy versioning and rollback, impact simulation, security hardening for enterprise deployments, and eventually AI-assisted policy authoring and debugging. But the foundation is solid, the agent is fast, and the dashboard is useful today.

If authorization is a pain point in your stack — or if you're building AI agents and wondering how to enforce access control on tool calls — give AuthzX a try. We'd love to hear what breaks.

Try AuthzX free during Early Access

No credit card required. Authorize anything in under 10 minutes.

Get Started