Agent-readable docs index: /llms.txt. Full docs in one file: /llms-full.txt. Download /docs.zip to grep all markdown files locally.

Understand access

Connecting an app and granting access are separate decisions; every tool call passes the full evaluation below at execution time.

Workspaces

Each company gets a workspace that holds everything you manage in the portal: users, apps, credentials, and audit history. MSPs can also create a separate customer workspace for each company they support; see Managed customers. Every request stays scoped to the selected workspace, and connecting provider credentials does not bypass the controls below.
Always confirm the active workspace before connecting an app or authorizing an AI client. Follow the Confirm Current workspace checklist.

How a request is evaluated

Every request passes through the same six layers, in order:
  1. Authentication: the person or service identity must be authenticated.
  2. Workspace resolution: the request must resolve to the intended workspace.
  3. Client admission: the AI client must be allowed to connect to the workspace.
  4. App connection and availability: the app must be available to the workspace and have a usable Organization connection or Personal connection.
  5. Grants and restrictions: group and direct policy must allow the app or exact tool, and no restriction may apply to it.
  6. Safety confirmation: the action's risk level and any required confirmation are evaluated against the current request.
Discovery is not a permanent authorization. Stackyapper checks the current policy again when the selected tool executes.
Restrictions win over grants. A tool restriction is not overridden by adding the same tool through another group or a direct grant.

Roles

Roles control administrative capabilities such as managing billing, apps, members, policy, and Audit. Roles do not by themselves mean that every provider tool should be available.

App grants and tool grants

An app grant is broad: it includes the tools currently allowed for that app. Use it when the group genuinely needs the application as a whole.
A tool grant is narrower. Prefer it for workflows that need only a few reads or when the app also exposes write-capable operations.

Groups and direct policy

Use groups for access shared by a job function or team. Use direct user policy for exceptions with a clear owner and review date.
Before saving a change, review Effective access for the affected user. After saving, verify the change in Audit.
The Effective access panel with Jordan Diaz and the tool autotask_update_ticket selected, returning Allowed via a direct or group tool grant, granted by the Service desk group on a healthy connection with no sensitivity rule blocking the call.
The dry run names which grant allowed the call, so you can tell an intentional group grant from access someone inherited. It never changes access.

Restrictions and confirmation

Restrictions are appropriate when an otherwise useful app exposes a tool a group should never use. Confirmation is a separate runtime safeguard for operations that require a decision before execution. Neither replaces provider-side least privilege: the credential itself should also be limited to the intended tenant and permissions.
Powered byHolocron