← Back to Blog
·7 min read·Ruakiel Team

RBAC FOR AI AGENTS: WHO CONTROLS THE TOOLS?

Your AI agent has access to tools that can read databases, send emails, and mutate state. Without role-based access control, every agent is a superuser. Here is how to fix that.

RBACTool AccessMulti-Tenant

THE SUPERUSER PROBLEM

Most AI agent frameworks give the agent access to every tool in the system. If your agent can call a database query tool, it can query any table. If it can send emails, it can email anyone. There is no concept of “this agent should only have read access to the orders table and can only email the current user.”

This is the equivalent of running every microservice as root. It works in development. It is catastrophic in production.

THREE DIMENSIONS OF AGENT ACCESS CONTROL

Effective RBAC for AI agents must operate on three dimensions simultaneously:

  • Who is the user? The human whose request triggered the agent. Their permissions define the ceiling — the agent can never exceed the user’s own access level.
  • What role is the agent operating under? Roles define a specific tool allowlist. A support-focused role can access ticket tools but not billing tools, even if the user has billing permissions.
  • What is the agent trying to do right now? Task-based filtering further restricts tools to those relevant to the current objective. An agent executing a “look up order status” objective should not have access to the “refund payment” tool, even if the role allows it.
Effective tools = User permissions ∩ Role allowlist ∩ Task relevance ∩ Severity ceiling

HOW RUAKIEL IMPLEMENTS THIS

Ruakiel applies multiple filters in sequence before any tool reaches the agent:

  • Permission filter — validates the requesting user’s permissions against each tool’s requirements.
  • Role filter — restricts tools to those declared for the agent’s current role.
  • Task filter — limits tools to those relevant to the current objective.
  • Severity filter — enforces operation severity ceilings based on the action context.

Each filter is applied independently. No filter trusts the results of the filters before it. This is defense in depth applied to access control.

MULTI-TENANT ISOLATION

In a multi-tenant AI platform, RBAC alone is not sufficient. Tenant A’s agent must never access Tenant B’s tools, data, or configuration — even if a code bug bypasses the RBAC layer.

Ruakiel enforces tenant isolation at the data layer with database-level security rules and encryption at rest. Tool definitions, conversation history, and user data are scoped per tenant. Cross-tenant access is architecturally prevented — isolation is enforced at the infrastructure level, not just application logic.