MCP role design for AI agents: one role only

What breaks when you copy SaaS roles into an agent rollout

Support asks for Claude against Zendesk. Finance wants ChatGPT near the billing system. Both requests arrive as tickets in the same week, and IT has to answer them with one access model. MCP role design for AI agents starts one layer earlier than either ticket assumes, because the unit governed is a tool call, not a screen. 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 agent 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 ACLs say what a member can see at all, through a grant of view, use or edit on a resource. Restrictions say which connectors and which individual tools a target may reach. Roles are the first layer only. Rollouts get muddled when one role is asked to carry all three.

Why exactly one role per member?

Elaichi gives each member exactly one role, enforced by 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 constraint forces every role to be a complete persona. Where a system lets one person hold three roles, answering what they can do means working out a union nobody has read end to end. Here the answer is one role plus the grants that person holds. When somebody asks what a departed contractor could reach, that question has a short answer.

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 a single action cannot express the difference as an extra role on one of them. You express it with a restriction or with sharing instead. A restriction targets a role or a user. restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything, because the org default is the absence of any rule, which means allow-all.

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

How does the Guest to Org Owner chain map to job functions?

The six system roles in Elaichi form a strict subset chain: Guest subset Member subset Team Admin subset People Admin subset Org Admin subset Org Owner. Each tier is built by spreading the tier below it, so the subset relation holds structurally rather than by convention. Promoting somebody never quietly removes an ability they had, and no tier in the middle holds a permission the tier above lacks.

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 the one most people hold.
• Team Admin. A department lead who runs the team's shared connections and toolboxes. A toolbox is a saved collection 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. ALL_PERMISSIONS minus exactly 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 remove the evidence along with the environment.

Two roles sit off the chain. Billing Admin belongs to whoever owns the card in finance and has no business inside tool calls. Auditor is read-only and free. A compliance reviewer reads the audit log and forwards it to a SIEM destination without consuming a license. The audit log is the append-only record of what happened, filterable by actor, category and time. Org Owner, Org Admin, People Admin, Team Admin and Member are the billable seats. Seat classes and the two plans are on the pricing page.

Which roles can call a tool at all?

In Elaichi, tool:execute gates the entire MCP endpoint, ahead of every other check. Guest, Billing Admin and Auditor do not hold it. Without it, tools/list comes back empty and any call returns an in-band error naming the missing permission, so 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. Cost and capability line up. The people who only review or only pay cannot act, and do not cost a license.

Above that gate sit OAuth scopes, the permissions a client is granted when it signs in. OAuth is the standard for delegated sign-in without handing over a password. There are four scopes: mcp:read, mcp:write, mcp:destructive and mcp:tools. A tool classified forbidden is reachable under no scope at all. mcp:tools does not replace the ladder. 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 write gate that inspects prompts in the agent window does not apply to the MCP endpoint and cannot, because an MCP server never sees a user prompt. RBAC per operation, the forbidden classification, output redaction, scope limits and full audit logging are what hold there.

Where MCP role design for AI agents goes wrong

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. A member sees only what they own or what was explicitly shared with them, and no org-level permission changes that, org owners and admins included. If an Org Admin cannot see a team's connection, the fix is a grant, not a promotion.

The second is writing an allow rule that names nothing. The allowlist stage in Elaichi engages on the presence of an allow rule, not on its contents. An allow rule listing no tools therefore denies everything. It is the strictest rule you can express, and people write it by accident when they create a rule and save before filling it in.

The third is treating a user-level restriction as an addition to the role's rules. A rule on a user replaces the role rules for that user rather than adding to them A user rule replaces the role's rules outright. Within whichever layer wins, allow rules union, block rules union, and blocks always beat allows. Which side of a rule matches the tool's advertised name and which side matches the pinned operation is its own subject, covered in how block and allow match differently.

One permission deserves separate thought at assignment time. connector:create is flagged high trust, because a custom connector can be pointed at any destination. Treat it like production deploy rights, not like a convenience.

When does a role change take effect?

about two minutes. Elaichi resolves role membership and restrictions through a short cache, so a change lands within roughly two minutes on every surface: MCP, the console and the REST API alike. Grant revocation, member removal and suspension work differently. Those are re-read from the org store on every single 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. removing or suspending a member revokes every live grant in the same transaction as the membership change.

Removal also runs a preflight. Personal connections referenced by a toolbox entry must be transferred to the org, a team or another member, or deleted, or the removal is refused. A private connection is never transferable, because a credential only its owner could use does not become somebody else's when they leave. The contractor case is worked through in what to do about contractor offboarding today.

Designing roles for your first agent rollout

Start with the system roles and change nothing for two weeks. Most organizations need fewer custom roles than they expect, and the audit log will show which ones are actually missing.

1. List everybody who will point a client at the endpoint. Claude, ChatGPT, Cursor and the Elaichi Agent all use the same organization-wide address.
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 rather than individuals first, starting with blocks on destructive tools. Reserve user-level rules for exceptions, remembering that a user rule replaces the role's rules.
5. Connect the accounts and read the audit log for a week. actor_kind is a recorded field, and ai_assistant is one of its values, so AI-driven actions are marked at the point of action.
6. Create a custom role only when the log shows a persona that no system role fits.

If your identity provider is the system of record, map groups to roles through SCIM (automatic user and group provisioning from your directory) and let joiners arrive with the right role already set. Just-in-time SSO sign-in and verified-domain auto-join with a default role are the other two paths.

When a role design is 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 blocked at the role level, and revisit it when a second team arrives or a contractor does. 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 and handle routing and credentials in house, the real cost of that is worked through in running your own MCP servers.

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