Permissions

Permissions decide who can use the capabilities your integrations provide, and where. Enabling a capability makes it available, granting it decides who may actually call it.

Go to Developer → Permissions. Managing permissions requires admin access.

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	Read Firefight’s own data, such as incidents, alerts and the catalog
Service keys	Nothing

Members can read what is in Firefight, but anything that reaches a connected tool needs an explicit grant. Service keys start with nothing at all, so everything they do is something you deliberately gave them. A service key is how you give a headless AI agent its own access, separate from any person’s, which is covered in Connect AI agents.

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.

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

If a connection holds separate credentials per environment, a grant scoped to an environment only works there.

This is how you let different people reach different environments through the same integration. Grant a contractor the database abilities scoped to Development, and grant your own 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

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.

Caution

Changing a set changes what everyone holding it can do, straight away. Deleting a set removes it from everyone it was granted to.

This is why one set granted twice beats two nearly identical sets. Grant Database read-only to a contractor scoped to Development and to your team unrestricted, and when the tool adds a capability you only update the set once.

Note

Permission sets are separate from the incident roles under Team → Roles. Incident roles say who is doing what during an incident, such as Incident Lead. Being given one grants no access.

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.