Permission Bundles (Granular RBAC)

Give a member the job-function access their role does not carry - "a normal user who also runs the AP queue." Last updated 2026-09-17

What it is

Org roles (Viewer / Auditor / OrgAdmin / …) are coarse: whatever level a role grants, it grants across the entire platform. They are the blanket setting - a full administrator, an audit role, or a global reader. A permission bundle is a named template that grants a per-module access level, and it names the job its holder does on top of that blanket.

A member can carry zero or more bundles. Their effective access is the union of their org role's baseline and every bundle they hold - for each module, the highest level any of them grants wins.

So the AP clerk who also needs to be an ordinary employee is Viewer + AP / Finance Ops: they keep the global reader access every member has, and gain ops: write to work the finance queues.

How a bundle resolves against the role

A bundle states the job its holder does, and that reads in two directions depending on what their role already carries:

Viewer / Auditor - the bundle ADDS. The role's baseline (read across Ops, Security, Audit, Insights and Assets; Auditor also writes Audit) is kept, and the bundle's grants are added on top. This is what makes "an ordinary member who also does X" expressible.
OrgAdmin and above - the bundle SCOPES. An administrator already reaches everything, so naming their job can only mean "…and nothing else." Their access is the bundle union alone. An OrgAdmin carrying only Contributor keeps full working access to Ops, Security and Audit but is held out of org administration and the Manage module.
No bundles = nothing changes. A member with an empty bundle list keeps their legacy role-based access, exactly as before. Assigning the first bundle is what opts a member in to module scoping.
SuperAdmin is always unrestricted. Bundles never apply to SuperAdmins - the all-access escape hatch, so you cannot lock yourself out.

Vault and Manage are never in a baseline. The password manager and the module holding tenant credentials, org membership and the device fleet require an explicit bundle grant no matter how broad the role is - being a global reader does not make you a reader of those.

Inside the module a bundle grants, the bundle also settles what its holder may do: a grant of write or admin satisfies that module's role checks, so the AP clerk carrying AP / Finance Ops can actually approve a reimbursement rather than being admitted to the Ops module and refused every action in it. This applies only to the module the request targets — the same person is still refused a Security write — and it never confers SuperAdmin. It comes from the bundle, never from the role's baseline: an Auditor whose bundles say nothing about Audit still reads and writes there as an Auditor, exactly like an Auditor carrying no bundles, but does not administer it. Giving someone an unrelated job does not make them an administrator of a module they happen to be able to read.

Reimbursements are narrower. Ops is a single module, so a grant on it cannot tell an AP clerk from an IT technician. Only the AP / Finance Ops, Ops Manager and Platform Admin bundles include reimbursement work: seeing the AP queue and everyone's claims and receipts, approving, paying and re-routing requests, and running the Insights reports that total everyone's reimbursements. The other Ops bundles (IT Task Queue Worker, HR Ops, Client IT Technician, Contributor, Ops + Devices) keep their Ops work without it. An organization admin with no bundle keeps it; an admin whose bundles include none of those three does not. A custom bundle cannot confer it. Two things stay open to everyone: members see and cancel their own requests, and anyone a request is routed to for approval can open that request to decide it.

So are Ops scripts and schedules. The Script Library and Script Schedules run code on endpoints, so only the Ops + Devices, Ops Manager and Platform Admin bundles include them. That covers viewing, writing, importing and running scripts, creating and running schedules, and reading their job output and run history. The other Ops bundles (IT Task Queue Worker, AP / Finance Ops, HR Ops, Client IT Technician, Contributor) keep their Ops work without them, and TATER Ops hides those two pages from their holders. As with reimbursements, an organization admin with no bundle keeps them, an admin whose bundles include none of those three does not, and a custom bundle cannot confer them.

And so are remediation and hardening changes. In the Security module, only the Security Admin and Platform Admin bundles include these changes:

creating or changing org remediations (scripts pushed to devices);
setting hardening levels, and accepting hardening risks or drift;
running a control remediation.

Security Analyst and Contributor holders can still view remediations and hardening, and are told why when they try to change them. Organization admins and custom bundles follow the same rules as above. API keys are the exception: a key's bundles only ever narrow what its role allows, so a bundle never raises a key to any of these jobs, or to reimbursements.

Two modules are excluded, deliberately. A grant on manage or vault opens the module and stops there; the role ladder still decides what may be done inside. Ops + Devices grants manage: write to reach Live Shell, BitLocker and wake / file-push, and Manage also holds org members and roles, API keys, SCIM and tenant credentials — so elevating there would hand every holder the org's administration to buy them a remote shell. Vault User exists to give someone credentials and nothing else, and administering the password manager is not "nothing else".

Exclusive bundles - the module-only scopes

A few bundles exist precisely because their holder should not get the rest of the platform, and for those the role baseline is not applied at all - their access is the bundle union alone, whatever the role. Asset Steward, Asset Viewer, Vault User and Client IT Technician are marked this way, so an asset-only person still does not receive the ticket queue or personnel records, a credentials-only contractor still receives only credentials, and a co-managed client technician still never reaches anything of the MSP's. Custom bundles cannot be exclusive: an exclusive scope is really a role, and building one out of a bundle is how the two halves of the model drift apart.

Read-only action controls in Security

Security marks unavailable editing and administrative actions as read-only and shows a short explanation. The decision follows your selected organization, role and permission bundles. An Auditor can still perform actions permitted to Auditors, such as generating a SOC 2 draft; a bundle can grant additional actions within its modules. Tenant credentials and other organization administration retain their own role requirements.

You can continue browsing records, searching, exporting and using your personal preferences. While organization permissions are loading, editing controls stay disabled. If permissions cannot be checked, refresh the page. The API checks every submitted request, including record ownership and workflow requirements; an enabled control does not override those checks.

The application picker and shortcuts in My TATER, Manage, Insights and Vault use your resolved access for the selected organization. A licensed module can still be outside your permission grants. My TATER keeps personal tasks, approvals and self-service requests available.

Switching organizations clears the previous access decisions. If access cannot be loaded, the app shows a retry message instead of treating the failure as a permission denial. A hidden link is a convenience: every API request still checks authorization, including requests opened through a bookmark.

The seven modules

Access is scoped per module, and the modules map 1:1 to the platform's apps:

Module	App	What it covers
`ops`	TATER Ops	Tickets/Tasker, service catalog, CAB / problems / releases, on-call, expenses, travel, license rentals
`assets`	TATER Ops (asset register)	The CMDB - devices, who holds which machine, purchase cohort, return status. Split out of `ops` so an asset-only job does not carry the ticket queue, incidents or personnel records
`security`	TATER Security	Controls, scans, risks, vendors/TPRM, policies, monitoring, hardening, compliance roadmaps, external ticketing, the GRC suite
`audit`	TATER Audit	Audit engagements, control tests, evidence, access reviews, RFIs, independence
`manage`	TATER Manage	Users, API keys, SCIM, tenant credentials, the device fleet and remote operations, patching, software deploy, MSP admin - and permission bundles themselves
`insights`	TATER Insights	Reports, report schedules, analytics
`vault`	TATER Vault	Password manager and restricted documents

My TATER is intentionally not a module. It is personal and always available - see Personal pages always work below.

Each module is granted at one of four levels: none (no access), read (view), write (act / create / edit), or admin (module administration). Reads (GET) require read; mutations require write.

Built-in bundles

Fifteen built-in bundles ship with the platform, mapped to common job functions. They are read-only - clone one to customize it. Bundles marked exclusive replace the role baseline rather than adding to it (see Exclusive bundles).

Bundle	Grants	Intended for
Platform Admin `platform-admin`	admin on all seven modules	Power users and platform owners - the all-access bundle, reimbursements, scripts and remediation included
Contributor `contributor`	ops: write · security: write · audit: write · assets: write · insights: read	Members who do the day-to-day work but should not administer the org - excludes Manage (members/roles, bundles, settings, integrations, devices) and Vault entirely, and does not run Ops scripts or make remediation and hardening changes
Security Analyst `security-analyst`	security: write · audit: read · insights: read	Works the Security / GRC surface; no Ops or Manage, and no remediation or hardening changes
Security Admin `security-admin`	security: admin · audit: read · insights: read · manage: read	Administers TATER Security (settings, integrations, controls, remediations and hardening)
Auditor `auditor`	audit: write · security: read · insights: read	Works the Audit engagement workbench; reads Security for evidence
IT Task Queue Worker `it-ops`	ops: write · assets: write	Works the Ops IT task queue end to end; not reimbursements, scripts or schedules
AP / Finance Ops `finance-ops`	ops: write · assets: write	Works Ops finance/AP queues, including reimbursements: the AP queue, approving, paying, re-routing; not scripts or schedules
HR Ops `hr-ops`	ops: write · assets: write	Works Ops HR queues; not reimbursements, scripts or schedules
Ops Manager `ops-manager`	ops: admin · assets: admin · insights: read	Administers TATER Ops (catalog, workflows, scripts, schedules, settings, reimbursements)
Ops + Devices `ops-devices`	ops: write · manage: write · assets: write	Operators who work Ops, including its scripts and schedules, and also need the device-management primitives - Live Shell, remote control, BitLocker, wake / file push - which live in the Manage module (see the note below)
Asset Steward `asset-steward` (exclusive)	assets: write	Maintains the asset register - devices, assignment, purchase cohort, return status. Asset data only: no ticket queues, no incidents, no personnel records
Asset Viewer `asset-viewer` (exclusive)	assets: read	Look up who has which machine, without being able to change it
Vault User `vault-user` (exclusive)	vault: write	Access to the Vault password manager only
Client IT Technician `client-it-ops` (exclusive)	ops: write · assets: write	Co-managed client staff who work their own organization's ticket queue end to end - and never the MSP's pooled cross-client queue, reimbursements, scripts or schedules
Read-Only (cross-module) `read-only`	ops: read · security: read · audit: read · insights: read · assets: read	Look, don't touch, across the working modules

Why is Live Shell not in the ops module?

Remote shell (Live Shell), remote control, BitLocker key access, and wake / file push are device-management primitives: they act on the device fleet itself, so their API routes are gated to the manage module by design - regardless of which app surfaces them. An ops-only bundle therefore cannot reach them. To grant them to an operator, assign the built-in Ops + Devices bundle (one assignment covers both), or a custom bundle that grants manage: write.

Assigning bundles in TATER Manage

Open TATER Manage → Tenant Admin → Access Control. The page has two parts:

Permission bundles - the catalog. Your custom bundles are listed on top; expand Built-in bundles to see the fifteen read-only templates with their module-grant pills. Each built-in has a Clone button; custom bundles have Edit and Delete.
Members - every member of the active organization with their role and current bundles. Members with no bundles show role checks only (no bundle fence). The Org role + bundle scope column shows the server-resolved module levels for bundled memberships, special job markers, and custom bundles that inherit Assets from Ops. An unbundled Viewer is governed by the Viewer role, not granted administrator access. Global SuperAdmin status is not evaluated in this membership list; endpoint, ownership, role and job checks still apply. An unavailable scope means the API needs updating or the page needs reloading, not that access is denied. Click Edit bundles to open the assignment modal, tick the bundles you want, and save - the selection replaces the member's bundle set, and clearing every checkbox returns them to legacy role-based access. The User → button jumps to the same member's user record (name, global role, org memberships) so both halves of member management are one click apart; the Users edit modal links back to Access Control the same way.

Roles themselves are still set in Tenant Admin → Users - the role sets the blanket baseline, and bundles add the job on top of it (or, for an administrator, scope them to it).

Custom bundles

When no built-in matches a job function, create your own (Admin only). Click + New bundle (or Clone on any bundle to pre-fill from it), give it a name and description, and pick a level for each server-listed module, including Assets. Choosing none removes this bundle’s grant; another bundle or the role baseline may still supply access. Custom bundles are org-scoped: each organization maintains its own set. Cloning copies module grants; it does not copy a built-in’s exclusive scope or special job markers. The editor preserves grants it cannot display when saving an existing bundle.

Built-in ids are reserved - a custom bundle can clone a built-in but never overrides one.
Assets compatibility inheritance: a custom bundle with an Ops grant and no explicit Assets grant inherits the same level for Assets. Choosing Assets none removes the explicit grant and therefore does not suppress this inheritance. The member scope column names the source bundle. An explicit Assets level takes precedence for that bundle; other bundles and role baselines can still raise the combined level.
Deleting a custom bundle removes it from any members it was assigned to.
Bundle changes propagate to enforcement within about 30 seconds (the auth layer caches an org's custom bundles briefly).

How bundles interact with org roles

Think of it as two gates in series - a request must pass both:

Role gate (unchanged): can this role do this action at all? A Viewer still cannot delete a risk, bundled or not.
Bundle gate (only for bundled members): does the member's resolved map - their role baseline plus their bundles - grant this module at the required level? Reads need read, mutations need write.

So an OrgAdmin carrying only the Contributor bundle keeps full working access to Ops, Security, and Audit but is blocked from org-administration writes (org settings, members, feature flags) and from the Manage module - the bundle scoped what the role would have allowed. A Viewer carrying AP / Finance Ops goes the other way: they keep the global reader access the role carries, gain ops: write for the finance queues, and can perform the Ops actions that grant covers — while remaining a Viewer everywhere else, and outside Manage and Vault in every case. Enforcement is server-side across the whole API surface, and the MCP/AI tool surface is gated in parallel: each MCP tool maps to its module, so a bundled member's AI assistant is scoped exactly like their browser session.

Shared features are not module-scoped. A few features are used from more than one app, so no module gates them - in the browser or over MCP: change requests and the CAB workflow, projects and milestones, acknowledgement campaigns, comment threads, and Departure Watch. For these the role gate alone decides, together with the feature's own license or add-on, so a bundle - even an exclusive one such as Vault User - does not keep a member with the right role out of them. Personal requests (expenses, license rentals, travel exemptions) are covered under Personal pages always work.

API keys made by a scoped administrator

An API key is scoped by its own role and bundles, not by the person who made it. So an administrator whose access is scoped by bundles can only give a key access they have themselves:

Creating a key. If you name no bundles - which is what TATER Manage → API Keys does - the key gets your bundles. If the bundles or the role you choose would reach a module, or a level, that yours do not, the key is not created, and the message names what it would have reached. A Viewer or Auditor key can be refused even with your own bundles, because those roles add read access across Ops, Security, Audit, Insights and Assets.
Changing a key's role, and rotating a key. The same check applies. Rotating a key hands you its new secret, so you can only rotate keys that are within your own access. Renaming, unbinding and revoking a key are not restricted.
Reimbursements and client staff. A key can administer reimbursements only if you can, and a key made by someone holding Client IT Technician keeps that bundle.

Administrators without bundles, and SuperAdmins, are not affected. A key used in a different organization through the org_id connection parameter never acts above its own role there, and where the person who made it is scoped by bundles in that organization, never beyond their access there.

That is about API keys, and it is unchanged: a key stays bound to one organization, and a call on a key's connection that names a different organization is refused. It is separate from a signed-in AI assistant (no key), which can name another organization you belong to on a single call. That call runs under the role, bundles and groups you hold in that organization, and nothing from the connection's default organization carries over, so being scoped by bundles in one organization neither narrows nor widens you in another.

What a scoped administrator can hand out

An administrator whose own access is scoped by bundles cannot give anyone — including themselves — access they do not have. This applies wherever access is handed out, in the apps and through AI assistants alike:

Bundles. They can assign bundles within their own access, to anyone, including themselves. They cannot assign one that reaches further, and they cannot clear a member's bundles: a member with no bundles is unrestricted. What a member already reaches is not counted against the administrator, so giving an existing member another bundle in the administrator's own modules is fine.
Custom bundles. They can author or edit one that grants what they hold, not more. Deleting a custom bundle is refused when members hold it and nothing else, because deleting removes it from them and would leave them unrestricted.
Members and roles. They can lower a member's role. They cannot add a member, because a new member has no bundles, and cannot raise a member above their own access.
Provisioning. Creating an organization, setting the auto-provision role, running a live directory sync, and configuring SCIM or single sign-on are refused: each produces members who carry no bundles. The directory-sync dry run, which writes nothing, stays available.

Administrators without bundles, and SuperAdmins, are not affected by any of this. The staff roster and its directory sync are part of the Manage module, like org members and API keys.

Personal pages always work

Bundle scoping never cuts a member off from things directed at them personally:

My TATER is not a gated module. Every member keeps their personal dashboard, to-dos, reviews, approvals, requests, surveys, notifications, and preferences regardless of bundles.
Personal API routes are exempt. The mine-style routes that back those pages (my tasks, my tickets, my action requests, assignments/mine, expenses/mine, rfi/mine, …) bypass the module gate. They are safe to exempt because each is fenced server-side to the caller's own identity - they only ever return or act on the caller's own items, so the exemption cannot leak anyone else's data.
The app shell still loads. Startup reads (organizations, settings, feature flags) stay ungated for everyone so a scoped member can always sign in and land somewhere; the corresponding writes are org-admin actions gated to the Manage module.

Example: a member bundled to ops: none cannot browse the Ops queues - but an Ops ticket assigned to them still shows in My TATER → My Tasks, and an action request on their ticket still reaches them.

MCP tool reference

The same operations are available to AI assistants (Admin only), which makes bundle assignment automatable - e.g. an onboarding workflow that scopes each new HR hire to hr-ops:

Tool	Purpose
`list_permission_bundles`	List the bundle catalog - built-ins plus this org's custom bundles, with their per-module grants
`create_permission_bundle`	Create or update a custom bundle: pass `name`, `description`, and a `grants` map (e.g. `{"ops":"write","insights":"read"}`), or `clone_from` to pre-fill from an existing bundle
`list_member_permissions`	List org members with their assigned bundles and membership id - see who is scoped to what
`set_member_permission_bundles`	Assign a member's bundles: pass the membership id and the full desired set of bundle ids (replaces the existing set; an empty list restores legacy role-based access)

TATER Manage overview - the app hosting Access Control
People & Organizations - org membership and the legacy role model bundles narrow within
MCP Tool Policies - a complementary control: restrict which AI tools are available, per role or group
Settings reference - platform roles and org settings

Was this page helpful?