Permissions
Permissions decide who can use the capabilities your integrations provide, and where. Everything granted here is enforced by the gateway, whether the request comes from Slack, the dashboard, the API or an AI agent, and every governed action lands in Activity. Enabling a capability makes it available, granting it decides who may actually call it. The same grants cover Firefight’s own settings, so a member can be given runbooks or webhooks without being made an admin.
Go to Gateway → Permissions. The page requires admin access. Everything on it is also available over the API (/abilities, /principals, /permission_sets, /grants, /approval_rules) and as MCP tools, to an admin’s personal token.
The resources you grant here line up with what the API and MCP expose, so a permission means the same thing wherever the request came from.
What everyone starts with
Section titled “What everyone starts with”Some access needs no grant at all, so check here before granting anything.
| Who | What they can do with no grants |
|---|---|
| Admins and owners | Everything, including every capability your integrations provide |
| Members | See everything in Firefight, and declare, update and close incidents |
| Agents | Nothing |
| Service keys | Nothing |
Members can read what is in Firefight and take part in incidents, and that is the same whether they are clicking a button in Slack, using the dashboard, calling the API with a personal token, or working through an AI agent connected as them. Changing how the workspace is set up needs a grant or admin access, and anything that reaches a connected tool needs an explicit grant. Agents and service keys start with nothing at all, so everything they do is something you deliberately gave them, and neither inherits the access of whoever created it. An agent is an AI acting under its own name, which is what an incident timeline records when it takes part. A service key is for automation with nothing to say on a timeline, such as an alerting pipeline. Both appear on this page alongside your people.
Reading what people said in an incident channel is its own ability, Incident Transcripts, rather than part of Incidents. Reading an incident and reading every message in its channel are different asks, so granting the first never grants the second. It also needs the workspace to have turned transcript access on, which is a separate admin decision. See Incident conversations.
A few things cannot be granted to anyone: integrations, API keys, this Permissions page, and workspace settings. Those are the controls that decide access itself, so they stay with admins and owners.
The number next to each person is how many grants they hold, not how much they can do. Admins show as admin because their access does not come from grants.
When something is not allowed
Section titled “When something is not allowed”Firefight checks permissions the same way wherever the request comes from, so a person is told the same thing in Slack as an agent is told over the API.
In Slack, an action nobody is allowed to take comes back as a message only you can see, naming what was refused and telling you to ask an admin. Nothing happens to the incident. On the dashboard you are sent back to the page you were on with the same message, and a settings screen you cannot change never shows the controls in the first place. Over the API and MCP the caller gets a permission error naming the access it lacks.
Some actions are allowed but need a second person to say yes first. Those do not fail, they wait. Which ones, who decides and where they are asked is set in the Approval rules block on this page, described in Approvals.
Granting
Section titled “Granting”Pick who you are granting to, then choose Grant. You are granting one of two things.
A single ability is one capability, such as reading databases in PlanetScale. Search for it by name. Abilities are grouped by the connection that provides them.
A permission set is a named bundle of abilities granted in one step, covered below.
Either way, you then choose which environments the grant covers. Leave every environment unticked and the grant covers all of them.
Environments
Section titled “Environments”If a connection holds separate credentials per environment, a grant scoped to an environment only works there.
This is how you let different people and agents reach different environments through the same integration. Grant an AI agent’s service key the database abilities scoped to Development, and grant your team the same abilities with no environment restriction. Both use the same capability, and each reaches only what you allowed.
For this to work the connection needs credentials wired for that environment. A grant scoped to Production does nothing if the connection has no Production credentials, so set both up together. See Environments.
Permission sets
Section titled “Permission sets”Granting fifteen abilities one at a time does not scale past a couple of people. A permission set bundles abilities under a name and grants them together.
Create one with the + next to Permission sets, name it for what it lets someone do, such as Database read-only. Then tick the abilities it covers. Select all on a group takes every ability from one connection at once.
Grant the set the same way you grant a single ability, choosing environments as usual. The set says what someone can do, and the grant says where.
This is why one set granted twice beats two nearly identical sets. Grant Database read-only to an agent scoped to Development and to your team unrestricted, and when the tool adds a capability you only update the set once.
Changing and removing access
Section titled “Changing and removing access”Open the person or key to see everything they hold.
Each grant shows the ability or set, whether it reads or writes, and which environments it covers. Click the environment button to change the scope without regranting. The bin icon revokes the grant.
Revoking takes effect immediately.