Permissions & connections Pro
What an agent is allowed to see, who can grant it, and how to take it back.
Permissions
Both ways of connecting use the same four scopes, so an agent's access reads the same whether it arrived by token or by sign-in:
Two rules make this safe on a shared workspace:
- Your role is the ceiling. A grant can never exceed what the person who
approved it can do. A Viewer cannot hand an agent
maps:write, no matter what the client asks for. This is re-checked on every request, so changing someone's role resizes their agent immediately, and removing them from the workspace kills their connections outright. - Cost is a real boundary. Without
spend:read, spend figures are stripped from every response andget_spenddisappears from the tool list. An agent can map your architecture without ever seeing what it costs.
Tools that need more than you granted simply aren't listed, so an agent won't plan around something it will be refused on.
Managing what's connected
Settings → API → Connections lists the agents attached to your workspace. Workspace owners and admins see every connection (which client, who authorized it, when, when it was last used, and what it can do); everyone else sees the ones they authorized themselves.
You can remove a permission from a live connection and it applies on the agent's very next request. Adding one is deliberately not possible here: to widen access, reconnect the client and approve the larger set, so a connection can never quietly gain permissions its approver never saw.
Rate limits & usage
MCP is not a separate quota. Tool calls count against the same
per-workspace rate limit and daily cap as the REST API -
one budget. Read tools draw from the read allowance; create_map, update_map,
and delete_map draw from the write allowance, which is held about ten times
tighter. The same operation costs the same whichever way it arrives. Calls are logged the same way and show up in
Settings → API under "Usage", tagged MCP so you can tell them apart from
direct API traffic.