The World Has Changed​

When we started Casbin back in 2017, the typical authorization scenario was straightforward: a user makes a request, we check if they have permission, done. Today? An AI agent might be acting on behalf of a user, calling multiple MCP servers, each with their own tool permissions, and the whole thing needs to happen in milliseconds at the edge.

The MCP spec now classifies MCP servers as OAuth 2.0 Resource Servers (June 2025 update), with fine-grained scopes like mcp:tools:weather or mcp:resources:customer-data:read. That is the kind of granular permission model Casbin was built for; integration with MCP and OAuth still needs more work.

What We're Working On​

MCP Server Authorization​

This is one of our main focus areas. When an AI agent calls an MCP server, the server must decide: can this agent, on behalf of this user, invoke this tool with these parameters?

Traditional RBAC is not enough. You need something like ABAC—e.g. “is this agent allowed to access customer data for Alice’s region during business hours?” We are exploring how Casbin’s policy model can express these constraints.

The catch: MCP servers must decide very quickly. We are looking at lightweight policy evaluation inside the MCP server process instead of calling a separate authorization service.

Edge-First Authorization​

Cloudflare Workers, Deno Deploy, Vercel Edge Functions - the edge computing space has exploded. In 2025, sub-50ms response times are table stakes, and you can't afford to add 100ms for an authorization check to some central server.

This is pushing us to think differently about how Casbin works. Can we compile policies to WebAssembly and run them directly in V8 isolates? Can we do smart policy caching at the edge while maintaining consistency? These are hard problems, and we don't have all the answers yet, but it's where things are heading.

We're particularly interested in the Cloudflare Workers ecosystem - they've built out a whole platform for MCP servers with built-in OAuth support. A native Casbin integration there could be powerful.

RAG Pipeline Authorization​

A recurring theme: companies building RAG systems where the LLM must access internal documents, but each user should only see documents they are allowed to see.

The OWASP Top 10 for LLM Applications 2025 lists “Sensitive Information Disclosure” as a major risk. The fix is not only to filter outputs but to ensure the LLM never retrieves documents the user is not authorized to access.

So authorization must happen at the vector store query level. We are looking at turning Casbin policies into metadata filters for vector DBs—i.e. a permission check becomes a WHERE clause pushed down to retrieval.

Multi-Agent Scenarios​

With multiple agents in a chain (e.g. coding agent → deployment agent → monitoring agent), permission delegation is tricky. Each agent may have different capabilities, and you must track the full chain.

OAuth’s On-Behalf-Of (OBO) flow covers part of this, but the logic for “can agent B do X on behalf of agent A on behalf of user alice” needs a clear model. Casbin’s role hierarchies and domain RBAC could extend to agent hierarchies; we are working through the semantics.

The Traditional Roadmap Stuff​

Of course, we're not abandoning the basics. Some practical things on our list:

Language implementations catching up - SwiftCasbin and Lua-Casbin are still behind on features compared to the Go and Node.js versions. The in operator, WatcherEx, better caching for the g function - these need to be consistent everywhere.

New framework middlewares - go-zero has been requested repeatedly. Poem for Rust is gaining traction. Play Framework for Java has been on the wishlist forever.

Performance work - As policies get more complex for these new use cases, evaluation speed matters more. We need better benchmarking, profiling, and optimization across all implementations.

What we don’t know yet​

The AI agent authorization space is moving fast; we are learning as we go. Open questions:

• Should Casbin have first-class primitives for "agent identity" vs "user identity"?
• How do you handle authorization for tools that are dynamically discovered via MCP?
• What's the right caching strategy when policies might depend on real-time context?

If you are building in this space and hitting authorization problems, we want to hear from you. The best features come from real use cases.

Getting involved​

We have been a GSoC organization for years, and these AI-related topics are a good fit for summer projects. You do not need to wait for GSoC—if this sounds interesting, reach out on Discord or open an issue on GitHub.

The next few years are going to be wild for authorization. The problems are harder, but also more interesting. We're excited to figure them out together.

Introduction to RBAC​

RBAC restricts access based on the roles users hold. To see how hierarchical RBAC works, we look at Azure’s RBAC and then implement something similar in Casbin.

Azure’s hierarchical RBAC​

In Azure, the Owner role applies at different scopes. If I have Owner at the subscription level, I am Owner of all resource groups and resources under that subscription. If I have Owner at a resource group level, I am Owner of all resources in that group.

The image below shows Owner access at the subscription level.

Checking IAM for a resource group under that subscription shows inherited Owner access.

That is how Azure’s RBAC is hierarchical. Many systems use similar hierarchies. In this tutorial we implement a comparable model with Casbin.

How Casbin works​

Understanding Casbin’s building blocks (request, policy, matcher, effect) makes it easier to design and tune your RBAC model.

What is ACL?​

ACL (Access Control List) maps users to actions and actions to resources.

Model definition​

A minimal ACL model:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

1. request_definition — Defines the request format. E.g. alice, write, data1 means “Can Alice write data1?”
2. policy_definition — Defines the policy format. E.g. a policy alice, write, data1 grants Alice permission to write data1.
3. policy_effect — How multiple matching policies are combined (e.g. allow-override).
4. matchers — The condition that must hold: r.sub == p.sub && r.obj == p.obj && r.act == p.act.

Try it in the Casbin editor​

Open the Casbin editor and paste the model above into the Model editor.

Paste the following in the Policy editor:

p, alice, read, data1
p, bob, write, data2

and the following in the Request editor:

alice, read, data1

The result will be:

true

Visual representation of the ACL model, policy, and request matching​

What is RBAC?​

RBAC (Role-Based Access Control) assigns users to roles; roles have permissions on resources. A request checks whether the user’s role allows the action on the resource.

Model definition​

A simple RBAC model:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[role_definition]
g = _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && g(p.act, r.act) && r.obj == p.obj

1. role_definition — Defines graph relations (e.g. g for role–role or user–role). The matcher uses these to resolve roles and permissions.

Try it in the Casbin editor​

Open the editor and paste the model above.

Paste the following in the Policy editor:

p, alice, reader, data1
p, bob, owner, data2

g, reader, read
g, owner, read
g, owner, write

and the following in the Request editor:

alice, read, data1
alice, write, data1
bob, write, data2
bob, read, data2
bob, write, data1

The result will be:

true
false
true
true
false

Visual representation of the RBAC model, policy, and request matching​

The g (role-to-action) relation is a graph. In policy it is written as edges, for example:

g, reader, read
g, owner, read
g, owner, write

Hierarchical RBAC​

In hierarchical RBAC there are multiple resource types with inheritance (e.g. Subscription → ResourceGroup). A subscription sub1 can contain resource groups rg1, rg2. Similarly, there are subscription-level roles/actions and resource-group-level roles/actions, with inheritance between them. For example, the subscription role sub-owner might inherit to the resource-group role rg-owner: if I have sub-owner on sub1, I effectively have rg-owner on rg1 and rg2.

Model definition​

A minimal hierarchical RBAC model:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[role_definition]
g = _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && g(p.act, r.act) && g2(p.obj, r.obj)

Here g links roles/actions and g2 links resources (e.g. subscription to resource group).

Try it in the Casbin editor​

Open the editor and paste the model above.

Paste the following in the Policy editor:

p, alice, sub-reader, sub1
p, bob, rg-owner, rg2

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

And paste the following in the Request editor:

alice, rg-read, rg1

The result will be:

true

Visual representation of the RBAC model, policy, and request matching​

The g edges (role → action, role → role) can be written in policy as:

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

The g2 edges map subscription to resource group:

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

Subject Matching Visual representation​

Action Matching Visual representation​

Object Matching Visual representation​

Conclusion​

This tutorial showed how ACL, RBAC, and hierarchical RBAC can be expressed in Casbin. In a follow-up, we will implement this in a Spring Boot app and secure APIs with Casbin.

APISIX is a high-performance, scalable, cloud-native API gateway built on Nginx and etcd, and an Apache Software Foundation project. It ships with many plugins for authentication, monitoring, routing, and more. Plugins are hot-reloaded without restarts, so you can change behavior on the fly.

When you need authorization beyond simple checks, the authz-casbin plugin can help. It is an APISIX plugin built on Lua Casbin that enforces flexible authorization using models such as ACL, RBAC, and ABAC. Casbin is an authorization library (originally in Go, now ported to many languages); Lua Casbin is the Lua port. We proposed the plugin in the APISIX repo (#4674); after review and improvements, it was merged (#4710).

This post shows how to implement Role-Based Access Control (RBAC) in APISIX using authz-casbin.

Note: Casbin handles authorization only. Use another plugin or your own logic for authentication (identifying the user).

Создание модели​

The plugin authorizes each request using three parameters: subject, object, and action. The subject comes from a header (e.g. username: alice), the object is the URL path, and the action is the HTTP method.

Suppose we have three paths: /, /res1, and /res2. We want a model like this:

So: any user (e.g. jack) can access /; users with the admin role (e.g. alice, bob) can access everything; and non-admin users are limited to GET. Here is a model that does that:

[request_definition]
r = sub, obj, действовать

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _

[policy_effect]
e = где-то (стр. ft == allow))

[matchers]
м = (g(r.sub, p.sub) || keyMatch(r.sub, p. ub)) && keyMatch(r.obj, p.obj) && keyMatch(r.act, p.act)

Создание политики​

For the scenario above, the policy could be:

p, *, /, GET
p, admin, *, *
g, alice, admin
g, bob, admin

The matcher means:

1. (g(r.sub, p.sub) || keyMatch(r.sub, p.sub)) — The request subject either has the policy subject as a role or matches it via keyMatch. For keyMatch and other built-ins, see Lua Casbin BuiltInFunctions.
2. keyMatch(r.obj, p.obj) — The request path matches the policy object.
3. keyMatch(r.act, p.act) — The request method matches the policy action.

Enabling the plugin on a route​

After creating the model and policy, enable the plugin on a route via the APISIX Admin API. Using file paths:

curl http://127.0.0. :9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
        "authz-casbin": {
            "model_path": "/path/to/model. onf",
            "policy_path": "/path/to/policy. sv",
            "username": "username"
        }
    },
    "upstream": {
        "nodes": {
            "127. .0.1:1980": 1
        },
        "type": "roundrobin"
    },
    "uri": "/*"
}'

The username field is the header name that carries the subject (e.g. if the header is user: alice, set "username": "user").

To use inline model and policy text instead of files, use the model and policy fields:

curl http://127.0.0. :9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
        "authz-casbin": {
            "model": "[request_definition]
            r = sub, obj, act

            [policy_definition]
            p = sub, obj, действовать

            [role_definition]
            g = _, _

            [policy_effect]
            e = где-то (стр. f== допустить))

            [matchers]
            м = (g(r. ub, p. ub) || keyMatch(r.sub, p.sub)) && keyMatch(r.obj, p.obj) && keyMatch(r.act, p. ct)",

            "policy": "p, *, /, GET
            p, admin, *, *
            g, угла, администратора
            g, bob, администратор",

            "Имя пользователя": "Имя пользователя"
        }
    },
    "upstream": {
        "nodes": {
            "127. .0.1:1980": 1
        },
        "type": "roundrobin"
    },
    "uri": "/*"
}'

Using a global model and policy​

To use one model and policy for all routes, store them in the plugin’s metadata. Send a PUT request:

curl http://127.0.0. :9080/apisix/admin/plugin_metadata/authz-casbin -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -i -X PUT -d '
{
"model": "[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _

[policy_effect]
e = где-то (стр. ft == allow))

[matchers]
м = (g(r.sub, p.sub) || keyMatch(r. ub, p.sub)) && keyMatch(r.obj, p.obj) && keyMatch(r. ct, p.act)",

"policy": "p, *, /, GET
p, admin, *, *
g, alice, admin
g, bob, admin"
}'

Then enable the plugin on a route (it will use the metadata). Example:

curl http://127.0.0. :9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
        "authz-casbin": {
            "username": "username"
        }
    },
    "upstream": {
        "nodes": {
            "127. .0.1:1980": 1
        },
        "type": "roundrobin"
    },
    "uri": "/route1/*"
}'

The route then uses the shared model and policy from metadata. To change them, send another PUT to the plugin metadata; all routes using it will pick up the update.

Use cases​

• Per-route authorization — Attach the plugin to any route with your model and policy. Good when different routes need different permissions or when policies are large (each route only loads what it needs).
• Global model/policy — Store one model and policy in plugin metadata and reference it from many routes. Updating policy in one place (e.g. etcd) updates all those routes.

The full award letter is available here.

Google describes the program as:

Just as a Google Peer Bonus recognizes a fellow Googler who has gone above and beyond, an Open Source Peer Bonus recognizes external contributors who have made exceptional contributions to open source.

The 2019 winners announcement lists Yang and Casbin alongside other impactful projects and developers, including Git, TensorFlow, V8, CPython, LLVM, Apache projects, Angular, and Jenkins.

We are proud to see Casbin recognized for its work in open source and cloud security.

Спасибо за полёт!

The docs are still being improved. The site source is on GitHub: https://github.com/casbin/casbin-website-v2

Contributions and suggestions are welcome.

node-Casbin keeps the same usage and API as other Casbin implementations. Middlewares for Express, Koa2, and Egg.js are available, and a Sequelize storage adapter is included.

We hope it fits your stack. Feedback and contributions are welcome.

GitHub: https://github.com/casbin/node-casbin

Casbin Server is under active development by the core team. Current features:

• Written in Go.
• Manages many Casbin instances so you can centralize policy enforcement from multiple services.
• gRPC for all client communication; REST support is planned.
• A web admin UI for managing instances, models, policy storage, and load balancing.

Source code: https://github.com/casbin/casbin-server

Issues and pull requests are welcome.