Agent permissions and access rules

Toolstile permissions decide which tools, resources and prompts an agent may use from each MCP connection. Direct grants and assigned policies combine their allows, while a matching block in either source wins. Full access includes new supported capabilities the server adds later. Permission edits take effect after you save them; previews let you inspect proposed changes first.

Choose the workspace and agent

Each agent authorization belongs to one workspace. A personal connection and a team shared MCP entry have separate access settings, even if they connect to the same provider. Choose the workspace you intend to change before editing access.

Team owners, admins and custom roles with Manage agent access can configure individual agent grants. Joining a team or grouping agents under a device does not grant those agents access to shared entries. Each agent needs its own grant or policy assignment.

A device groups agent connections so you can manage them together. For example, your laptop may contain a coding agent and a research agent. Those agents can have different permissions, and revoking one agent's workspace access leaves the other's authorization in place.

Select capabilities or grant full access

Permissions cover more than tools:

• Tools are actions the agent can call, such as searching issues or updating a record.
• Resources provide content the agent can read. Rules can name a resource URI or match a resource URI template.
• Prompts are templates the server offers for structuring a request, such as a review checklist the agent can fill in.

A selected grant allows the capabilities you list. Tool and prompt entries use exact names; resource entries use URIs or URI templates. Enter one value per line in the relevant allow or block field.

Full access allows the connection's supported tools, resources and prompts, including new ones it adds later. Existing explicit blocks still apply. Full access applies to the selected MCP entry; it does not grant access to every connection in the workspace.

If you want to review new tools before an agent can use them, keep full access off and list the permitted names. A new tool then needs a matching allow before it is available. A resource matching an already allowed URI template can be permitted without a new rule.

Direct grants, policies and blocks

A direct grant applies to one agent authorization and one MCP entry. A reusable policy contains rules you can assign to multiple agents. An agent can receive access from its direct grant and assigned policies at the same time.

The rules combine as follows:

1. A matching block in any applicable source denies access.
2. Otherwise, full access or a matching allow in any applicable source permits the capability.
3. Without an applicable allow, access is denied.

A direct grant does not take priority over a policy. Removing an allow from one source may leave another source's allow in effect. To deny a capability that another grant permits, add a matching block or remove every applicable allow.

For example, suppose an issue-tracker connection exposes search_issues, create_issue and delete_issue. Your coding agent has full access through a policy, but its direct grant blocks delete_issue. It can use the other tools; deletion stays blocked. Adding delete_issue to a second policy's Allow list does not change that outcome.

These names are illustrative. Use the names exposed by your actual connection when editing its rules.

Edit and save access

For a single agent and connection, open Access in the selected workspace and edit that pairing. Check Allow all current and future capabilities for full access, or leave it unchecked and fill in Allowed names and Allowed URIs / URI templates. Add anything the agent must never use under Explicitly blocked, then choose Save access.

The Policies page shows how direct grants and policies combine. Its Direct grants view lets you pick an agent authorization and MCP entry, edit the rules, and preview the effective access together with any saved policy assignments. Save direct grant applies the change; Discard changes restores the saved rules. Editing fields or looking at a preview does not change active permissions, so check the save result before relying on a restriction.

In Reusable policies, saving an existing policy updates every agent assigned to it. Save a new policy before previewing it with an assigned agent. In Policy assignments, a proposed change stays staged until you choose Save assignment.

Reusable policies need Starter or above, and custom management roles need Team or above. On Free you manage access with direct grants and blocks, which work the same way on every plan. Check pricing for availability.

Understand what the agent can see and do

Toolstile filters discovery using the same permission rules it applies to execution. A blocked tool is omitted from the agent's tool list, and a call does not become permitted merely because the client remembers its name.

After saving changes, refresh the client's catalog or reconnect if it still shows an old list. Toolstile checks current access when forwarding requests, including membership and the selected upstream account's availability. A stale client display does not preserve a removed permission.

For shared MCP entries, capability grants apply across the entry's approved accounts, including accounts approved later. Your preferred account overrides the workspace default. If that selected account becomes unavailable, the entry stops being usable until you select an available account. See shared accounts before changing approvals or defaults.

An upstream account must also permit the requested action. Toolstile cannot grant access to a provider's records or actions beyond that account's rights. See connection authentication for the upstream sign-in steps.

Revoke access at the right scope

Revoke an agent authorization to stop that agent's access to the selected workspace. An access manager can revoke workspace authorizations, and a user can revoke their own. Removing a member also stops that member's agents from using the workspace.

Revoke your device to stop all agents grouped under it, across their workspaces. Only the device's owner can perform that broader action; a team administrator's authority stays within their workspace.

Revocation cannot undo a tool action the remote service has already performed. If an upstream credential has been exposed, revoke or rotate it with that provider as well. For an access failure, check troubleshooting; for capture and retention details, read security and data handling.

Separate management roles from agent grants

Owners manage billing, ownership and workspace deletion. Admins manage members, shared MCP entries and agent access. Custom management roles can delegate specific duties such as managing shared MCPs, managing agent access or viewing activity metadata.

A management role does not automatically grant the person's agents access to MCP capabilities. Viewing activity metadata also does not grant debug capture access: team captures remain restricted to owners and admins. Role edits require Save, just like permission edits.

If a plan change removes support for assigned policies or custom roles, the affected agents' access stays paused until a workspace admin explicitly converts it to supported settings. Review the proposed conversion and its blocks before saving.

Set up your first connection, or continue to shared accounts.