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. Separate customer administration and customer workspace switching require Business and approved MSP or consultant verification; 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. For managed customers, follow the Open a customer 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: the workspace risk limit (plus any exception for that app) and the app’s rules must allow the tool’s risk type, group or 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.
In a group or person's app access, choose specific tool calls to grant reads, writes, or high-impact operations within the workspace and app limits. Allow and Revoke actions show how many calls they affect. They apply to all matches for the current filters, including rows hidden behind Show more. Review the counts, select Done, then save the group or person.
Full includes current and future tools within the app's limits. Revoking an individual tool from Full changes that app to Scoped, keeping its other currently eligible tools. Access inherited from a group is shown separately; removing a direct grant does not remove the group's grant. Use a restriction when the tool must remain denied.
Tools outside the current limits do not count as effective grants. If saving will remove inactive selections, the editor shows a warning before you save.
Revoking a tool grant removes that grant. A deny is a restriction that takes precedence even when another group grants the tool.
Risk types and sensitivity tags can overlap. For example, a read can carry a personal-data tag. Newly discovered tools can initially receive conservative classifications until their behavior and data contract have been reviewed; a destructive classification does not by itself establish that a tool deletes records.
Each row shows the risk type, potential sensitivity, and the source of its classification when available. Automatic policy, metadata inference, and reviewed tool contracts are distinct sources. A source review of risk can retain conservative sensitivity labels. Older stored reviews can have unavailable source information. These labels do not show what a call returned.
Permissions use the stricter applicable risk classification, including a reviewed classification when an app's hints indicate lower risk. A saved grant does not override that limit. If an existing call becomes blocked, review the app's risk limit, rules, and restrictions before changing access.

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.
After saving a change, open the affected person from Users & groups and review their Access tab. For each app granted in full, the Granted by column shows whether the grant is direct or names the group it comes from, so you can tell an intentional group grant from access someone inherited. Then verify the change in Audit.

Workspace risk limit and app rules

Every tool has a risk type: Read, Write, Destructive, or Credential-sensitive. Two settings decide which risk types an app can use at all, before any grant is considered:
  • Workspace risk limit: the default for every app in the workspace. New workspaces start with Read, Write. Owners and admins change it from the Workspace risk limit summary on an app's Permissions page with Change workspace limit.
  • App rules: the risk switches on one app's Permissions page. They can only narrow what that app allows.

Allow a risk type for one app

To allow a risk type for one app without changing the default for every app, turn on that risk switch on the app's Permissions page. If the workspace limit excludes that risk type, Stackyapper asks you to confirm an exception for that app only. For example, allowing destructive tools for one app leaves the workspace default at Read, Write for every other app.
After you confirm, the app's summary shows the exception, for example Workspace default: Read, Write · This app: + Destructive (exception). The Change workspace limit dialog lists every app that has an exception.
For a private workspace app, open Tools & access and use App risk limit to review and confirm an exception for that app. This works before or after activation. Allowing a risk type does not activate the app or grant anyone access. Remove the exception from the same summary to restore the workspace default.
An exception can contain a risk type that the workspace default also allows. Removing that entry from the exception leaves the workspace default in effect; it does not block the risk type. Use app rules or restrictions to narrow access.
An exception only widens the workspace default for that app:
  • People still need a group or direct grant for the app or tool.
  • Restrictions still win over grants.
  • The app's own risk switches still apply. An exception has no effect while the app's switch for that risk type is off.
  • Destructive and write calls still ask for confirmation. Workspace data restrictions also continue to apply.
  • An exception applies to one app in one workspace. It never applies to other apps, and a managed customer workspace does not inherit exceptions from the managing workspace.
Only owners and admins who can change the workspace risk limit can add or remove an exception. Every change is recorded in Audit.
To remove an exception, select Remove exception in the app's summary. Tools of that risk type go back to the workspace default on the next request. Saved grants are kept. Whether a tool remains available depends on the workspace default and the other access rules.
If the workspace risk policy cannot be loaded, Stackyapper allows only reads and ignores exceptions until the policy loads again.

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.