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-09

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.

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.

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, 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
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
Security Analyst `security-analyst`	security: write · audit: read · insights: read	Works the Security / GRC surface; no Ops or Manage
Security Admin `security-admin`	security: admin · audit: read · insights: read · manage: read	Administers TATER Security (settings, integrations, controls)
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
AP / Finance Ops `finance-ops`	ops: write · assets: write	Works Ops finance/AP queues (queue-level scoping within Ops is a planned refinement)
HR Ops `hr-ops`	ops: write · assets: write	Works Ops HR queues
Ops Manager `ops-manager`	ops: admin · assets: admin · insights: read	Administers TATER Ops (catalog, workflows, schedules, settings)
Ops + Devices `ops-devices`	ops: write · manage: write · assets: write	Operators who work Ops 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
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 default (unrestricted). 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 per module - modules left at none grant nothing. Custom bundles behave identically to built-ins in resolution and enforcement, and are org-scoped: each organization maintains its own set.

Built-in ids are reserved - a custom bundle can clone a built-in but never overrides one.
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.

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?