👥 Role-based access for a multi-team org
Stack — Org: teams + members · Roles: per-resource permissions · Isolation: agents, tools, gateways, credentials · Output: least-privilege by default
Who it’s for — an org where support, finance, and platform teams share almyty but shouldn’t share everything. What it does — gives each team its own agents, tools, gateways, and credentials, with role-based access controlling who can view, edit, run, or approve — so a support engineer can’t touch the finance agent’s refund tools, and no one has more than they need.
Build it
- Create teams for your org units — Support, Finance, Platform — under one organization.
- Assign roles per resource: viewer, editor, operator, admin. A role governs whether someone can see a resource, change it, run it, or approve its actions.
- Scope resources to teams — the support agent, its tools, and its gateway belong to Support; finance’s refund tools stay in Finance.
- Keep credentials isolated — each team’s vault entries are theirs; a shared key never leaks across team lines.
- Combine with approval policies so a sensitive action requires an approver from the owning team, not just anyone.
Make it yours
- Give consultants a scoped, time-boxed role on one team’s resources.
- Pair with SSO/SCIM so roles map to directory groups and deprovision automatically.
- Every access decision is in the audit trail.
Uses — Enterprise · RBAC · Multi-tenant