AI Agent RBAC: Role-Based Access Control
AI agents need RBAC — not because you distrust them, but because prompt injection happens. RBAC is the last line of defense: even a compromised agent can only do what its role permits.
What is RBAC for AI Agents? Simply Explained
Role-Based Access Control (RBAC) for AI agents works like a permission system for employees: each agent has a role with specific rights. A 'read-only-analyst' agent can only read data, not write. A 'support-agent' can create tickets, but not delete. An 'ops-agent' can only execute pre-approved runbooks, no shell commands. RBAC is critical because prompt injection can cause an agent to do things it shouldn't — RBAC prevents such compromised agents from causing damage.
↓ Jump to standard roles, configuration, and FAQ
4 Standard Agent Roles
Can query data sources and generate reports. No write access to any system.
- ▸ database.query
- ▸ files.read
- ▸ reports.generate
- ▸ database.write
- ▸ files.write
- ▸ api.post
- ▸ shell.exec
Can read customer data, create tickets, send predefined notifications. No access to infrastructure.
- ▸ crm.read
- ▸ tickets.create
- ▸ notifications.send_template
- ▸ crm.delete
- ▸ billing.modify
- ▸ infrastructure.*
- ▸ shell.exec
Can read infrastructure state and trigger pre-approved runbooks. No free-form shell access.
- ▸ k8s.get
- ▸ k8s.scale_approved
- ▸ runbooks.execute_approved
- ▸ metrics.read
- ▸ k8s.delete
- ▸ shell.exec
- ▸ secrets.read
- ▸ iam.modify
Can scan and report. Cannot modify any security configuration or access sensitive data.
- ▸ trivy.scan
- ▸ openclaw.assess
- ▸ reports.create
- ▸ config.modify
- ▸ secrets.read
- ▸ network.modify
- ▸ users.read
Moltbot RBAC Configuration
# Moltbot RBAC configuration
agent_roles:
read-only-analyst:
description: "Data analysis agent — read-only"
tools:
allowed:
- database.query
- files.read
- reports.generate
denied:
- "database.*write*"
- "files.*write*"
- "shell.*"
default_deny: true # Deny everything not explicitly allowed
support-agent:
description: "Customer support agent"
tools:
allowed:
- crm.read
- tickets.create
- notifications.send_template
denied:
- "crm.delete"
- "billing.*"
- "infrastructure.*"
rate_limits:
tickets.create: {max: 50, window: "1h"} # Rate limit sensitive ops
require_approval:
- notifications.send_bulk # Human approval for bulk sends
# Bind agents to roles at deployment time
agents:
customer-support-prod:
role: support-agent
identity:
type: workload_identity # K8s ServiceAccount — not API key
service_account: moltbot-support-agent
namespace: moltbot-agentsFrequently Asked Questions
Why do AI agents need RBAC instead of just trusting the agent?
AI agents are not deterministic systems — even a well-designed agent can produce unexpected actions due to prompt injection, model drift, or ambiguous instructions. RBAC provides a security layer that is independent of the agent's behavior: even if a prompt injection causes an agent to 'want' to delete a database, the RBAC layer prevents the tool call from executing. This is defense in depth: the agent's prompt hardening tries to prevent malicious behavior, RBAC ensures that even if prompt hardening fails, the blast radius is limited to what the role permits.
How should I scope tool permissions for different agent types?
Follow strict least-privilege: 1) List every tool the agent needs for its normal operation. 2) Start with all denied. 3) Add only the minimum tool permissions for normal operation. 4) For sensitive tools (write, delete, modify): consider requiring human approval or rate limiting. 5) Never grant wildcard permissions (database.*) — enumerate specific operations. 6) Periodically audit: review what tools agents actually used (from audit logs) vs. what they're permitted. Remove unused permissions. The rule: an agent should not be able to do anything that wouldn't be permitted if the worst-case prompt injection succeeds.
How does Moltbot handle agent identity for RBAC?
Moltbot supports three identity types for agents: 1) Workload Identity (recommended for Kubernetes): Kubernetes ServiceAccount → IRSA (AWS) or Workload Identity (GCP/Azure). No API keys stored in the pod. Permissions managed at the RBAC layer. 2) Signed JWT: agent presents a short-lived signed JWT (1-hour TTL) issued by Moltbot's identity service. JWT includes role claim. 3) API Key (not recommended for production): static API key mapped to role. Avoid — keys can be exfiltrated by compromised agents. Moltbot enforces that agents cannot escalate their own permissions — role assignment is only possible via the Moltbot control plane, not from within an agent.
Should different instances of the same agent have different RBAC roles?
Yes, where possible. Context-based role variation: a support agent handling general inquiries vs. one handling VIP/financial customers should have different permission scopes. Environment-based variation: production agents should have more restricted permissions than staging agents. User-context-based variation (dynamic scoping): Moltbot supports dynamic permission scoping — the agent's effective permissions are the intersection of its role permissions and the permissions of the end user it's acting on behalf of. Example: agent role allows crm.read, but if the user only has permission to read their own record, the agent's effective permission is crm.read_own_record only.