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.

Apache APISIX can enforce Casbin authorization policies at the gateway with its built-in authz-casbin plugin. The plugin uses Lua Casbin and supports access control models such as ACL, RBAC, and ABAC.

This guide puts a small RBAC policy on the APISIX request path. You will verify allowed and denied requests, then update a shared policy through plugin metadata without changing the route.

The Casbin community originally proposed the integration in APISIX Issue #4674, and APISIX PR #4710 added the plugin.

Prerequisites and starting state​

This guide starts with a disposable Apache APISIX 3.17.0 instance already running. If you need a local instance, follow the APISIX Docker deployment guide and pin the APISIX image to apache/apisix:3.17.0-debian.

The instance must have:

• the data plane available at http://127.0.0.1:9080;
• the Admin API available at http://127.0.0.1:9180;
• the built-in authz-casbin and mocking plugins enabled.

You also need curl and jq. Set admin_key to the key configured for your Admin API:

export admin_key='<your-admin-api-key>'

Replace the placeholder before continuing. Confirm that the Admin API is reachable and the plugin is enabled:

curl --fail-with-body \
  "http://127.0.0.1:9180/apisix/admin/plugins/list" \
  -H "X-API-KEY: $admin_key" | \
jq -e '(["authz-casbin", "mocking"] - .) | length == 0'

The command should print true. Do not publish the Admin API to an untrusted network or reuse demonstration credentials in another environment.

Define the model and policy​

The plugin evaluates three request values:

• sub: the subject from the configured request header;
• obj: the request URI path; and
• act: the HTTP method.

Create model.conf:

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[role_definition]
g = _, _

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

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

Create policy.csv:

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

This policy allows any subject to send GET /anything. It also assigns alice the admin role, which can access every path with every method.

Store the shared policy in plugin metadata​

Load the files as JSON strings and write them to APISIX plugin metadata:

jq -n \
  --rawfile model model.conf \
  --rawfile policy policy.csv \
  '{model: $model, policy: $policy}' | \
curl --fail-with-body \
  "http://127.0.0.1:9180/apisix/admin/plugin_metadata/authz-casbin" \
  -H "X-API-KEY: $admin_key" \
  -H "Content-Type: application/json" \
  -X PUT \
  --data-binary @-

Plugin metadata provides one model and policy to routes that enable authz-casbin without defining their own route-local model and policy.

Enable authorization on a route​

Create a route and tell the plugin to read the subject from the user header:

curl --fail-with-body \
  "http://127.0.0.1:9180/apisix/admin/routes/casbin-demo" \
  -H "X-API-KEY: $admin_key" \
  -H "Content-Type: application/json" \
  -X PUT \
  -d '{
    "uri": "/*",
    "plugins": {
      "authz-casbin": {
        "username": "user"
      },
      "mocking": {
        "_meta": {
          "priority": 1000
        },
        "response_status": 200,
        "response_example": "{\"message\":\"authorized\"}"
      }
    },
    "upstream": {
      "type": "roundrobin",
      "nodes": {
        "127.0.0.1:1": 1
      }
    }
  }'

The route uses the model and policy from plugin metadata because it only defines the username field locally. A route-local model and policy, when configured, take precedence over plugin metadata.

The mocking plugin gives allowed requests a deterministic local response, so the example does not depend on a public upstream. Its route-local priority is lower than authz-casbin, which makes the authorization decision run first. The unreachable upstream is therefore not contacted. This priority override and mock response are test fixtures, not production recommendations.

Verify allow and deny decisions​

An anonymous request to the public path is allowed:

curl -i http://127.0.0.1:9080/anything

Expected status:

HTTP/1.1 200 OK
{"message":"authorized"}

bob does not have the admin role, so a different path is denied:

curl -i http://127.0.0.1:9080/anything/res -H 'user: bob'

Expected result:

HTTP/1.1 403 Forbidden
{"message":"Access Denied"}

alice has the admin role, so the same request is allowed:

curl -i http://127.0.0.1:9080/anything/res -H 'user: alice'

Expected status:

HTTP/1.1 200 OK
{"message":"authorized"}

Update the shared policy​

Add a direct permission for bob to policy.csv:

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

Run the plugin metadata command again. Routes that reference this metadata use the updated policy without changing their route configuration. Repeat the request:

curl -i http://127.0.0.1:9080/anything/res -H 'user: bob'

The expected result is now:

HTTP/1.1 200 OK
{"message":"authorized"}

Choosing the configuration scope​

Use plugin metadata when several routes should share one model and policy. Use a route-local model and policy when a route needs an independent authorization shape. For the complete configuration schema and file-based alternative, see the APISIX authz-casbin plugin reference.

Clean up​

Remove the test route:

curl --fail-with-body \
  "http://127.0.0.1:9180/apisix/admin/routes/casbin-demo" \
  -H "X-API-KEY: $admin_key" \
  -X DELETE

Remove the shared plugin metadata:

curl --fail-with-body \
  "http://127.0.0.1:9180/apisix/admin/plugin_metadata/authz-casbin" \
  -H "X-API-KEY: $admin_key" \
  -X DELETE

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.

Thanks for flying Casbin!

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

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/apache/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/apache/casbin-server

Issues and pull requests are welcome.