Enterprise RBAC/ABAC for Cloudflare OS — centralized permissions for users, agents, MCP tools and data

[mariosxen]

Overview

I’ve been experimenting with Cloudflare OS and thinking about how it could be deployed as an internal AI platform inside an organization.

Cloudflare OS already has many of the security primitives needed for this: Gatekeepers, capability-based access, Cloudflare Access, MCP/MCP Portal, AI Gateway, resource scoping, and the existing permission/sharing model.

What I think is missing is a centralized enterprise authorization layer connecting these pieces together.

The goal would be to allow administrators to define exactly which users/groups can use particular agents, connectors, MCP servers, tools and resources — including the scope of data those tools are allowed to access.

Conceptually:

Identity Provider
↓
Cloudflare Access
↓
Cloudflare OS
↓
Verified User + Groups
↓
Agent
↓
Central Policy Engine (RBAC / ABAC)
↓
Gatekeeper
↓
MCP / API / Database / Internal Service
↓
Authorized Data

The problem

Imagine an organization connects Cloudflare OS to internal systems through MCP servers, APIs or Gatekeepers.

Some of those integrations may use service credentials that technically have broad backend access.

That should not mean every Cloudflare OS user who can interact with the connector automatically inherits everything that credential can access.

Instead, before executing a request, Cloudflare OS/Gatekeeper could evaluate:

Who is the user?
↓
Which groups/roles?
↓
Which agent?
↓
Which connector?
↓
Which MCP server?
↓
Which tool?
↓
Which resource?
↓
Which action? (READ / WRITE / EXECUTE)
↓
Which data scope?
↓
ALLOW / DENY

Most importantly, the LLM should never be responsible for enforcing these permissions. Authorization should happen server-side regardless of what the model attempts to call.

Example

An administrator might define:

Risk Team
├── User Profile READ
├── User Activity READ
├── Transactions READ
├── Verification Data READ
├── Financial Reports DENY
└── Pattern Analysis EXECUTE
Support Team
├── User Profile READ
├── User Activity READ
├── Transactions DENY
├── Verification Data DENY
├── Financial Reports DENY
└── Pattern Analysis DENY

Both teams could technically use the same MCP server or backend integration, but the authorization layer would expose/enforce different capabilities based on identity.

Identity-aware Gatekeepers

One particularly useful capability would be for Gatekeepers to receive trusted identity context from Cloudflare Access.

For example:

User:
employee@company.com
Groups:
Risk-Team
Region-A
Agent:
Risk Agent
Request:
get_transactions
Policy evaluation:
Risk-Team → transactions.read = ALLOW
Region-A → data_scope.region = A
Result:
ALLOW
Enforced scope:
region = A

The Gatekeeper would enforce region = A regardless of what parameters the agent/model attempts to provide.

This could potentially evolve beyond traditional RBAC into ABAC, using attributes such as:

• group
• department
• region
• environment
• data classification
• agent
• resource
• operation

Connector authentication

I think there are two important authentication models worth supporting.

1. Delegated user identity

For systems that already have per-user authorization:

User
↓
Cloudflare OS
↓
Gatekeeper
↓
OAuth / delegated identity
↓
Backend
↓
Backend applies the user's existing permissions

Cloudflare wouldn’t need to recreate the backend’s authorization model.

2. Service identity + Cloudflare authorization

For databases, legacy applications or internal services where delegated authentication isn’t available:

User
↓
Cloudflare OS
↓
Policy Engine
↓
Gatekeeper
↓
Service Credential
↓
Backend

The service credential might technically have broad access, but the Gatekeeper would only allow operations authorized for the requesting user/group.

This seems particularly important for enterprise AI because giving an AI agent access to a powerful service credential without a user-aware authorization boundary creates a very large permission surface.

MCP governance

MCP Portal and Gatekeepers already provide a strong foundation.

It would be great if administrators could centrally define policies such as:

Risk-Team
│
└── Internal MCP
├── search_user ALLOW
├── user_activity ALLOW
├── transactions ALLOW
├── verification ALLOW
├── financial_reports DENY
└── raw_query DENY
Support-Team
│
└── Internal MCP
├── search_user ALLOW
├── user_activity ALLOW
├── transactions DENY
├── verification DENY
├── financial_reports DENY
└── raw_query DENY

Rather than simply determining whether someone can access an MCP server, policies could potentially operate at:

User / Group
↓
Agent
↓
Connector
↓
MCP Server
↓
Tool
↓
Resource
↓
Action
↓
Data Scope

Administration

An /admin interface could expose this without requiring every organization to build its own authorization UI.

For example:

Group: Risk-Team
Agents
☑ Risk Agent
☐ Finance Agent
Connectors
☑ Internal Data
☑ Internal API
☐ Finance
MCP Tools
☑ User Profile
☑ User Activity
☑ Transactions
☑ Verification
☐ Financial Reports
☐ Raw Query
Data Scope
Region: A
Access: Read Only
[ SAVE POLICY ]

The UI itself isn’t the important security boundary — it would simply manage policies that Gatekeepers enforce server-side.

AI model governance

Since AI Gateway already provides centralized model routing, the same policy system could potentially control model availability:

Developers
├── Provider A ALLOW
├── Provider B ALLOW
└── Workers AI ALLOW
Support
├── Provider A ALLOW
├── Provider B DENY
└── Workers AI ALLOW

This could provide one governance model for both what AI can be used and what company resources that AI can access.

Auditability

It would also be valuable for every authorization decision to produce a structured event:

User: employee@company.com
Agent: Risk Agent
Connector: Internal Data
Tool: get_transactions
Resource: user/123456
Action: READ
Policy: Risk-Team
Result: ALLOWED
Timestamp: ...

Denied requests should be recorded as well.

This could provide security teams with an audit trail answering:

Who asked which agent to access what resource, through which tool, under which authorization policy, and was it allowed?

Why I think this fits Cloudflare OS

The interesting part is that Cloudflare appears to already have most of the individual pieces:

Cloudflare Access
→ Identity
Identity Provider
→ Users / groups
Cloudflare OS
→ Agents / execution context
MCP Portal
→ External tools
Gatekeepers
→ Security boundary
AI Gateway
→ Model routing/governance
Workers
→ Execution
D1 / Durable Objects
→ Potential policy/state storage

The missing piece seems to be the central policy layer connecting identity → agent → capability → resource.

Rather than every organization independently implementing its own RBAC database, authorization middleware, Gatekeeper logic and administration UI, it could potentially become a native Cloudflare OS capability.

Existing authorization work

I also noticed that Cloudflare OS already has capability-based permissions, sharing roles, named MCP tool grants and ongoing work around resource/binding-aware authorization.

So I’m not suggesting replacing the existing capability model.

I’m wondering whether these primitives could eventually be unified into an organization-wide RBAC/ABAC layer, with Gatekeepers remaining the enforcement boundary.

Something along the lines of:

Existing capability security
+
Cloudflare Access identity
+
IdP groups/attributes
+
MCP tool/resource grants
+
Gatekeeper enforcement
+
Central policy management
=
Enterprise AI authorization

Questions for the Cloudflare team/community

Is anything along these lines already planned for Cloudflare OS?

In particular:

1. Is organization-level RBAC/ABAC on the roadmap?
2. Could Gatekeepers receive trusted user/group context from Cloudflare Access for policy evaluation?
3. Could MCP permissions eventually be managed per user/group and per tool/resource?
4. Is binding/resource/data-scope authorization something the current permission model is intended to evolve toward?
5. Would Cloudflare consider a centralized admin UI/policy engine so organizations don’t have to independently build this layer?

I’d be very interested to hear how others deploying Cloudflare OS internally are approaching this problem.