Designing roles for AI agents: one role each

How should you design roles for AI agents?

Give each person one role that describes their whole job, and let restrictions decide which tools that job may reach. Elaichi enforces the first half: every member holds exactly one role, so each role has to be a complete persona rather than an add-on. Designing roles for AI agents starts one layer earlier than most access tickets assume. The thing being governed is a tool call, not a screen.

Support asks for Claude against Zendesk. Finance wants ChatGPT near Xero. Both tickets arrive in the same week, and IT has to answer them with one access model. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.

The roles inside each SaaS app do not carry over. A Zendesk light agent and an accounts payable clerk describe what a person may click in one product. An AI client crosses products inside a single session, through one address. The real question is which tools a member may reach through that address, across every account the company has connected.

Elaichi splits the answer into three layers, and keeping them apart is most of the work. Permissions (RBAC, role-based access control) say which actions a member may perform. Resource sharing says what a member can see at all, through a grant that lets someone view, use or edit one resource. Restrictions decide which connectors and which individual tools a target may reach. Roles are the first layer only, and rollouts get muddled when one role is asked to carry all three.

Why does Elaichi allow only one role per member?

Because one role per member keeps the answer to "what can this person do?" short. Elaichi enforces it with a unique index. You cannot stack Auditor onto Member, and you cannot bolt a small admin capability onto a support seat as an extra.

That is a deliberate departure from the textbook model. NIST's overview of role-based access control assigns each user one or more roles, and each role one or more privileges. Where one person can hold three roles, working out what they can do means reading a union nobody has reviewed end to end. In Elaichi, the answer is one role plus the grants that person holds. When somebody asks what a departed contractor could reach, the answer is short.

The cost is real. If your identity provider thinks in additive entitlements, one role per member feels narrow at first. Two teams that differ by one action cannot express that as an extra role on one of them. You express it with a restriction or with sharing instead. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything.

Underneath, permissions are plain action strings, 58 of them, such as tool:execute, restriction:manage, audit:view and connector:create. A role is a named set of those strings and nothing more exotic.

Which system role fits which job?

The six system roles in Elaichi form a strict chain: Guest, Member, Team Admin, People Admin, Org Admin and Org Owner. Each tier is built from the one below it and holds everything that tier holds. The relationship holds by construction, not by convention. Promoting somebody never quietly removes an ability they had.

The mapping to real jobs is direct:

• Guest. An outside contractor or a reviewer who needs to see one shared thing. Free seat.
• Member. The support agent, the account executive, the analyst, the engineer. This is the working seat, and most people hold it.
• Team Admin. A department lead who runs a team's shared connections and toolboxes. A toolbox is a saved set of connected accounts and their tools.
• People Admin. Whoever runs joiners and leavers, usually IT ops or HR ops.
• Org Admin. The platform owner who configures shared connections and custom connectors. It holds every permission except billing:manage and org:delete.
• Org Owner. The only role holding org:delete.

That last exclusion is deliberate. Deleting the workspace is Owner-only, so an attacker who lands an admin account cannot delete the evidence along with the workspace.

Two roles sit beside the chain rather than on it. Billing Admin belongs to whoever owns the card in finance and has no business inside tool calls. Auditor is read-only and free, so a compliance reviewer can read the audit log, the append-only record of what happened, without taking a license.

That split follows a familiar control. NIST SP 800-53's separation-of-duties control, AC-5, divides duties among different people or roles. It also keeps those who administer access control from administering audit functions. An Auditor seat fits that pattern: the reviewer reads the record and holds none of the access administration. Org Owner, Org Admin, People Admin, Team Admin and Member are the billable seats, and the two plans are on the pricing page.

Which roles can call a tool at all?

Among the system roles, only the five billable ones can. In Elaichi, tool:execute gates the whole MCP endpoint, ahead of every other check, and Guest, Billing Admin and Auditor do not hold it. Without it, tools/list comes back empty and every call fails with an in-band error that names the missing permission. The failure is legible rather than silent.

This is the cleanest line in the model. Three of the eight system roles cannot cause an action in a third-party account, by role, before a single restriction is evaluated. Those three are also the free seats, so cost and capability line up. The people who only review or only pay cannot act, and do not cost a license.

After that gate come the OAuth scopes. OAuth is the standard for delegated sign-in without handing over a password, and a scope is a permission the client receives when it signs in. There are four: mcp:read, mcp:write, mcp:destructive and mcp:tools. No scope reaches a tool classified forbidden. The mcp:tools scope does not replace the other three: a connected tool whose method is a delete still needs mcp:destructive as well. Access to a shared toolbox changes none of this, because the role gate is evaluated first either way.

One limitation belongs here rather than in a footnote. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. An MCP server never sees a user prompt, so it cannot apply that gate. On the endpoint, the protections are per-operation RBAC, the forbidden classification, output redaction, scope limits and an audit row for each call that reaches execution.

What mistakes do teams make when designing agent roles?

Three mistakes recur, and all three come from asking one layer to do another layer's job.

The first is expecting a role to widen what somebody can see. It does not. Members see what they own and what someone explicitly shared with them, and no org-level permission widens that, even for org owners and admins. If an Org Admin cannot see a team's connection, the fix is a grant, not a promotion.

The second is saving an allow rule that names nothing. In Elaichi, the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. It is the strictest rule you can express, and it is what you get by saving a new allow rule before filling it in.

The third is expecting a user-level restriction to loosen the role's rules. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. A member is governed by the role's rules and by rules aimed at them, and a tool is reachable only when both admit it. Within each layer, allow rules add up, block rules add up, and blocks always beat allows. To let one person past a role rule, they file an access request and an admin approves it. Why blocks match tool names but allows don't explains how the two rule types match a tool.

One permission needs separate thought when you assign roles: connector:create. It is flagged high trust, because a custom connector can be aimed at any address you give it. Treat it like production deploy rights, not like a convenience.

When does a role change take effect?

A role change takes effect within about two minutes. Elaichi resolves role membership and restrictions through a short cache, and the change lands on every surface: MCP, the console and the REST API alike. Grant revocation, member removal and suspension work differently. Elaichi re-reads those from the org store on every call, so they take effect on the next call.

That difference decides what you do during an incident. If an agent is writing to the wrong Salesforce account right now, suspend the member or revoke the grant. Do not downgrade the role and watch the clock. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

Removal also runs a preflight. It lists every connection the departing member owns. A private connection that a shared toolbox relies on blocks the removal until you transfer it to another active member or delete it. A transfer goes to one member, never to a team, the organization or the admin running the removal. A private connection that nothing beyond the member depends on cannot be transferred and is deleted with them. A shared connection stays in place unless you name an action for it. The contractor case is worked through in offboarding a member who holds agent access.

What does a sales, engineering and HR split look like?

Each department maps to one role, because a member in Elaichi holds exactly one role. Each role's approved apps are its allow rules, written against connectors in the catalog.

Allow rules on one role union, so one allow rule per app is fine. An allow rule is also that role's whole allowlist. A department loses any app its rules do not name, so name every app the role uses. Blocks always beat allows, which is why the blocks column holds the delete tools. Custom roles are a Gold feature.

Someone who works across two departments gets the role for their whole job, plus access requests for the rest. A user-targeted rule cannot add access, because it only narrows what the role allows. Map each identity-provider group to its role, since a SCIM group mapping can confer at most one role. A role or restriction change takes effect within about two minutes. For curating the app list itself with templates, see approved AI tools per team.

How do you set up roles for a first rollout?

Start with the system roles and change nothing for two weeks. You may need fewer custom roles than you expect, and the audit log will show which ones are missing.

1. List everybody who will point a client at the endpoint. Claude, ChatGPT and Cursor all use the same organization-wide address. On Claude Team or Enterprise, an owner adds it once under Organization settings > Connectors. Each member then connects and signs in (Anthropic's steps). For ChatGPT, follow the ChatGPT setup.
2. Assign Member to everybody who will act, and Auditor to everybody who only reviews. Auditor costs nothing.
3. Give People Admin to the two or three people who run joiners and leavers, and Billing Admin to finance.
4. Write restrictions against roles first, starting with blocks on destructive tools, use user-level rules only to narrow one person, and send exceptions through an access request.
5. Connect the accounts and read the audit log for a week. A call from an MCP client is recorded under the person who signed in, with surface mcp and the OAuth client named.
6. Create a custom role only when the log shows a persona that no system role fits.

That order is least privilege in practice. NIST SP 800-53 states the principle in control AC-6: allow only the access needed for assigned tasks. It applies to users and to the processes acting on their behalf. An AI client acting for a member falls under it. One of the control's enhancements asks for a periodic review of the privileges assigned to roles. A week of reading the audit log gives that review its first evidence.

If your identity provider is the system of record, map groups to roles through SCIM. SCIM is automatic user and group provisioning from your directory, so joiners arrive with the right role already set. SCIM itself leaves the meaning of a group to you. RFC 7643 says groups can express role-based access control models, but it defines no authorization model. What membership grants is left to the service provider. In Elaichi, the group-to-role mapping is where you make that decision. Emailed invites with the role preset, just-in-time SSO sign-in and verified-domain auto-join with a default role are the other three paths in.

When is a role design more than you need?

If eight people all need the same access to the same two apps, skip the design exercise. Put everybody on Member, keep the destructive tools restricted at the role level, and revisit it when a second team or a contractor arrives. A role model with one role in it is a spreadsheet with extra steps.

The same honesty applies a layer up. If nobody has connected an AI client to a company system yet, read when you do not need an MCP gateway yet before buying anything. If you would rather run the servers yourself, running your own MCP servers works through the real cost.

Role design earns its keep at the second and third team. That is when one person's access has to differ from another's, and somebody will be asked to explain why. For one team worked end to end, see how a sales team gets governed Salesforce access. The twelve teams Elaichi models are on use cases, and the 600+ connectors in the catalog are what your restrictions will name.