RBAC for AI Agent Teams: Who Can Run What

When one person builds and runs every agent chain, permissions don't matter. You trust yourself. But the moment a second team starts using the platform -- or a junior engineer wants to experiment in the same environment where production chains run -- you need access control.

Role-based access control (RBAC) isn't bureaucracy. It's the difference between a team that ships confidently and one that's afraid to touch anything because someone accidentally deleted a production chain last Tuesday.

Why RBAC matters for agent platforms

Agent platforms are different from traditional SaaS tools. An agent chain can read files, call APIs, execute code, and send data to external systems. The blast radius of a misconfigured chain is significantly larger than someone editing a shared spreadsheet.

Without RBAC:

Anyone can modify production chains that handle customer data
Anyone can access API keys and secrets stored in the vault
There's no way to know who changed what or when
A new hire experimenting with a chain can accidentally trigger real API calls
Teams step on each other's work in shared namespaces

These aren't edge cases. They're Tuesday.

The four roles that cover 90% of teams

Most agent platforms need four roles. You can get fancy later, but these handle the majority of real-world access patterns:

Admin -- Full platform access. Manages users, orgs, billing, and global settings. Can do everything the other roles can do. Typically the team lead or platform owner. One or two people, not the whole team.

Chain Builder -- Creates and edits chain definitions, configures agents, sets up triggers and schedules. Can access secrets needed for chain configuration. Cannot manage users or billing. This is your engineering team.

Operator -- Can run existing chains, view results, approve decisions, and monitor execution. Cannot modify chain definitions or access raw secrets. This is your ops team, support team, or anyone who needs to trigger workflows without changing them.

Viewer -- Read-only access to chain results, logs, and dashboards. Cannot run chains or see secrets. This is management, auditors, or cross-functional stakeholders who need visibility without control.

The permission matrix

Here's what each role can actually do:

Action                  Admin   Builder   Operator   Viewer
─────────────────────────────────────────────────────────────
Create chains             ✓        ✓         -         -
Edit chains               ✓        ✓         -         -
Delete chains             ✓        -         -         -
Run chains                ✓        ✓         ✓         -
View chain results        ✓        ✓         ✓         ✓
Approve decisions         ✓        ✓         ✓         -
View secrets              ✓        ✓*        -         -
Manage secrets            ✓        -         -         -
View audit logs           ✓        ✓         ✓         ✓
Manage users              ✓        -         -         -
Manage orgs/billing       ✓        -         -         -
Configure schedules       ✓        ✓         -         -
Export data               ✓        ✓         ✓         -

*Builder sees secret names and can reference them in chains, but cannot view raw secret values.

Print this out. Tape it to the wall. It saves arguments.

Scoping by namespace and org

Roles alone aren't enough when you have multiple teams. A chain builder on the marketing team shouldn't be able to edit the data engineering team's production pipelines.

Multi-tenancy solves this by scoping permissions to organizations or namespaces:

Organization-level isolation: Each team gets their own org with separate chains, secrets, and users. Data doesn't leak between orgs. An admin in Org A has zero visibility into Org B.
Namespace scoping within orgs: Within an org, namespaces let you separate environments (dev, staging, prod) or functional areas (data-pipelines, content-ops, security-scanning). A builder can have full access in the dev namespace and read-only in prod.

The pattern that works: give builders full access in dev/staging namespaces and operator access in production. Changes go through a review process before hitting prod, similar to code review for deployments.

Chain-level permissions

Sometimes org-level scoping isn't granular enough. You need permissions on individual chains:

Edit access: Who can modify the chain definition, change prompts, add agents, or alter the execution flow. Limit this to the chain owner and explicit collaborators.
Run access: Who can trigger the chain. An operator might be able to run a reporting chain but not a chain that modifies infrastructure.
View access: Who can see the chain's configuration, results, and logs. Useful for cross-team visibility without cross-team risk.

A practical example: your customer support team has an operator role scoped to support-specific chains. They can run the "escalation triage" chain and the "ticket summarizer" chain but can't see or trigger the "database migration" chain that engineering maintains.

Secret access control

Secrets are the crown jewels. API keys, database credentials, third-party tokens -- if these leak, the damage goes way beyond your agent platform.

Layer your secret access:

Admins manage the vault. They add, rotate, and delete secrets. They set which roles and namespaces can reference each secret.
Builders reference secrets by name. When building a chain, a builder selects OPENAI_API_KEY from a dropdown. They never see the actual key value. The platform injects it at runtime.
Operators and viewers never touch secrets. They don't see secret names in chain configs. They don't know which API keys are being used. They just see results.
Secrets are scoped to namespaces. Production API keys only exist in the production namespace. Dev keys in dev. A builder with dev access can't accidentally reference a production credential.

This is the one area where you want to be strict from day one. Retroactively locking down secrets after everyone's had access is painful and requires rotating every key.

Audit trails

RBAC without audit logging is a lock without a camera. You know who has access, but you don't know what they actually did.

Every meaningful action should be logged:

Who performed the action (user, role, org)
What they did (created chain, ran chain, modified secret, approved decision)
When it happened (timestamp with timezone)
What was the result (success, failure, error message)
What changed (diff of chain config before/after edit)

This serves three purposes. Debugging: when a chain starts failing, you can trace back to the last edit. Compliance: regulated industries need proof of who accessed what. Accountability: when something goes wrong, you can reconstruct what happened without blame games.

Mentiko captures execution logs per agent automatically. Every chain run records the triggering user, input, output, duration, and any errors. Chain edits are versioned so you can diff configurations over time. For compliance-heavy environments, export audit logs to your SIEM.

How Mentiko implements RBAC

Mentiko's RBAC is built into the platform architecture, not bolted on:

Org-level isolation with data separation between tenants. Each org has its own chains, secrets, agents, and audit logs.
Four default roles (admin, builder, operator, viewer) that map to the permission matrix above. Custom roles are on the roadmap.
Secrets vault with AES-256-GCM encryption at rest. Secrets are injected as environment variables at runtime -- they never appear in chain definitions or logs.
Per-chain access control so you can share specific chains with specific users or roles without granting broad access.
Immutable audit log for every chain execution, decision approval, secret access, and configuration change.
Namespace support for separating dev/staging/prod within a single org.

Self-hosting adds another layer: your RBAC data never leaves your infrastructure. No cloud provider has access to your permission structure or audit logs.

When to skip RBAC

Not every team needs RBAC from day one. If you're:

A solo developer building and running your own chains -- just use an admin account. RBAC adds configuration overhead with zero benefit when there's one user.
A small team (2-3 people) with high trust -- you might get by with everyone as a builder. Add RBAC when you start onboarding people outside the core team or when you move to production workloads.
Experimenting or prototyping -- don't let permissions slow down exploration. Lock things down when the chains start touching real data or external systems.

The trigger to implement RBAC is usually one of: a new team starts using the platform, chains start running in production, or you handle data that has compliance requirements. When any of those happen, set up roles before the first incident forces you to.

Getting started

If you're adding RBAC to an existing setup:

Audit who currently has access and what they actually use
Map people to the four roles based on what they need, not what they have
Scope secrets to namespaces -- this is the highest-priority change
Enable audit logging before changing permissions so you have a baseline
Roll out role changes namespace by namespace, starting with production

Don't try to design the perfect permission system upfront. Start with the four roles, scope by namespace, lock down secrets, and iterate.

Need to lock down your agent platform? See our security architecture or get started with RBAC in the docs.