Permission Bundles (Granular RBAC)

Scope a member to just the TATER apps their job needs - "works the IT queue in Ops, no access to Security or Manage." Last updated 2026-07-22

What it is

Org roles (Viewer / Auditor / OrgAdmin / …) are coarse: whatever level a role grants, it grants across the entire platform. A permission bundle adds job-function scoping on top. A bundle is a named template that grants a per-module access level - for example, the built-in IT Task Queue Worker bundle grants ops: write and nothing else, so a member carrying only that bundle can work tickets in TATER Ops end to end but cannot open TATER Security, Audit, Manage, Insights, or Vault data at all.

A member can carry zero or more bundles. Their effective access is the union of their bundles - for each module, the highest level any of their bundles grants wins.

Safe by default - bundles narrow, never grant

Three rules make bundles safe to roll out gradually:

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.
Bundles only narrow. The existing role checks still run on top of the bundle check. A bundle can restrict what a role would otherwise allow; it can never grant beyond the role. Giving a Viewer the Platform Admin bundle does not make them an admin - it just doesn't restrict them.
SuperAdmin is always unrestricted. Bundles never apply to SuperAdmins - the all-access escape hatch, so you cannot lock yourself out.

The six 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, CMDB, on-call, expenses, travel, license rentals
`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

Twelve built-in bundles ship with the platform, mapped to common job functions. They are read-only - clone one to customize it.

Bundle	Grants	Intended for
Platform Admin `platform-admin`	admin on all six modules	Power users and platform owners - the all-access bundle
Contributor `contributor`	ops: write · security: write · audit: 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	Works the Ops IT task queue end to end. Ops only
AP / Finance Ops `finance-ops`	ops: write	Works Ops finance/AP queues (queue-level scoping within Ops is a planned refinement)
HR Ops `hr-ops`	ops: write	Works Ops HR queues
Ops Manager `ops-manager`	ops: admin · insights: read	Administers TATER Ops (catalog, workflows, schedules, settings)
Ops + Devices `ops-devices`	ops: write · manage: 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)
Vault User `vault-user`	vault: write	Access to the Vault password manager only
Read-Only (cross-module) `read-only`	ops: read · security: read · audit: read · insights: 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 twelve 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 baseline, bundles narrow within 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 bundle union 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 narrowed what the role would have allowed. 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?