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. A capability that is switched on is available, and permissions decide 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) and as MCP tools, to an admin’s personal token. Over the API and MCP every change here waits for an admin to approve it first. Approval rules are read over the API (GET /approval_rules) and MCP but changed only on this page, or by confirming the change in a Halon chat.

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

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 everything in Firefight apart from integrations, API keys, AI accounts, permissions and workspace settings, including the resource map in every environment. Use every connected capability that only reads, unless you chose otherwise for a connection. Declare, update and close incidents, ask Halon questions and start investigations, add to and correct what Halon remembers, and rename, pin, archive or delete their own chats with Halon
Agents	Nothing
Service keys	Nothing
Firefight’s own agents	Only what is granted to them on this page, listed below

Members can read what is in Firefight, take part in incidents and ask Halon, 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. They can also read through every connected tool, so Halon can look at logs, metrics and deploys for anyone who asks. Changing how the workspace is set up needs a grant or admin access, and a connected capability that changes something, such as restarting a service, needs a grant, usually the connection’s changes pack. Approval rules still apply to whoever holds it. Some tools can both read and change, such as an API request tool. A call to one that only reads, such as a GET, counts as a read, so members make it without a grant and no approval rule holds it. Agents and service keys make those reads once they hold the connection’s read pack. 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.

Firefight’s own agents are listed in their own section, Firefight agents, and each holds only what is granted to it there. Halon is the agent investigations run as. It starts with Resource Map in every environment, since a run finds what it investigates on the map first, and with Memory create and update, so a run can save what it learns (unconfirmed, like any memory Halon learns) and dispute a memory it finds wrong. It is also given each connection’s read pack when you connect it, so investigations can look at what you connect. Narrow or revoke any of those grants like any other, and a read pack you revoke stays revoked. Firefight issue sync is granted the tracker tools it needs when you choose an issue tracker, see Issue tracking. Firefight paging is granted, when you connect an on-call tool such as PagerDuty or Opsgenie, only the tools it pages someone through and keeps that page in step with its incident. A grant you revoke is not given back. See Halon on call. Firefight map sweep, Firefight health check and Firefight handbook sync hold no grants. They use only the tools that are switched on, and every call they make is in Activity under their name.

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. Members hold it without a grant, like every other read, and agents and service keys need it granted. It also needs the workspace to have turned transcript access on, which is a separate admin decision. See Incident conversations.

The resource map

Reading the resource map is its own ability, Resource Map. It covers the Map page and every MCP tool that reads the map, such as get_resource_map, find_resources and blast_radius, and it decides which resources a caller can find by name when it asks for logs, metrics, deploys or status through MCP.

Members can read the map in every environment without a grant. To limit a member to some environments, grant them Resource Map scoped to those environments, on its own or as part of a permission set. From then on they see only those environments. Change the grant’s environments to widen or narrow that, or revoke it to give them every environment back. An expired grant leaves them no environments at all rather than every one, so let it lapse only when that is what you mean. To take the map away at once, see Taking a default away. Admins and owners always see the whole map.

Agents and service keys read the map only once you grant them Resource Map. Scope the grant to the environments they need, or leave it unscoped for all of them.

A resource belongs to the environments of the connections that report it. One reported only by a connection set up for all environments, rather than per environment, is visible only to people who can read every environment. A resource someone cannot see is missing everywhere they look, on the Map page and in what an agent working for them reads. The same goes for what the workspace remembers about it and the instructions written for it. They are missing from the Memory page, and Halon leaves them out when it works for them, in a chat or in an investigation they started. A link from a resource they can see to one they cannot is left out. They can only add, confirm or dismiss links between resources they can see. The Map page says which environments they are seeing.

Asking Halon

Asking Halon a question and starting an investigation are one ability, Investigations with create. It covers asking in the dashboard’s Chat, mentioning @Firefight in Slack, /ff investigate, the Investigate button, and ask_halon and start_investigation over MCP. It also covers adding to an investigation, stopping one, answering Halon’s confirmations and applying a fix it proposes.

Members hold it without a grant. Once you grant it to a member, on its own or as part of a permission set, the grant decides instead. Asking is not tied to an environment, so leave the grant’s environments unticked. Admins and owners can always ask.

Every question is in Activity, wherever it was asked. An approval rule covering Investigations create holds a question asked in the dashboard or over MCP until someone approves it. A question asked by mentioning @Firefight in Slack is never held, since nothing in the thread could pick it up again once approved.

Holding it never widens what Halon does for them. A question acts with the asker’s own permissions, a fix’s steps run as whoever applied it, and an investigation reaches only what you grant the Halon agent.

Agents and service keys can ask Halon only once you grant them Investigations create.

Halon’s browser

Looking at a page in Halon’s browser needs no permission. Letting the browser send what a page would send, such as submitting a form, is its own ability, Let Halon send forms in its browser. Admins and owners hold it, and a member holds it once you grant it. Halon still asks the person every time before it sends, and approval rules can hold a send.

Reading connected tools

Members can use every capability that only reads on every connection, in every environment, without a grant. That covers the dashboard, Slack, the API with a personal token, MCP, and Halon when it works for them in a chat. Capabilities that change something are never held this way.

To decide for all members at once who reads or changes through a connection, use What members can do in each tool. To limit a member’s reads of one connection to some environments, grant them that connection’s read pack, or single read abilities, scoped to those environments. From then on the grant decides, the same way it does for the resource map. To take a connection’s reads away entirely, see Taking a default away.

Agents and service keys read a connection only once you grant it to them, and the connection’s read pack is the quickest way. The Halon agent is the exception, since it is given each connection’s read pack when you connect it. Revoke one to keep investigations away from that connection.

Taking a default away

Open a member and Held without a grant lists the defaults a member holds: reading the resource map, asking Halon, and one row for each connection with capabilities that read, named after its read pack. Choose No access on any of them and the member loses it straight away, everywhere, and is told so when they try. For a connection, that covers every capability that reads on it, including ones the tool adds later. A permission set that includes it does not give it back. Choose Restore to give them the default again. Both confirm with a message.

To limit rather than remove, grant the ability instead. A grant of Resource Map scoped to some environments limits the map to those, and granting an ability a member has no access to replaces the no access with that grant. Admins and owners cannot be given no access.

A few things cannot be granted to anyone: integrations, API keys, AI accounts, 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

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.

Asking an admin for a pack

When Halon is asked to change something through a connection you hold no grant for, it tells you that you do not have permission, which pack you need, such as Northflank: changes, and who your workspace admins are, so you can ask one of them directly. In the dashboard chat a card under Halon’s answer says the same, and in a Slack thread Firefight posts it as a message. Both carry Ask an admin.

Ask an admin sends every workspace admin a direct message in Slack naming you and the pack, with Give pack, and lists the request at the top of Gateway → Permissions under Waiting for a pack. Admins also see how many requests wait as a count on Permissions in the sidebar. Nothing is sent until you press it. Pressing it again, or being refused again, does not ask again for a day, so the admins hear about each pack once. Only the person who was refused can ask.

An admin answers with Give pack, in Slack or on the Permissions page, which grants the pack in every environment with no expiry, or with Dismiss. Granting the pack on the Permissions page in the usual way answers the request too. Either way you get a direct message in Slack saying who gave you the pack, so you can ask Halon again, or that the request was dismissed. If the change was refused in a Slack thread, a short note there says the same, and the card in the dashboard chat shows it too. Over MCP the error names the pack and the admins, with no button.

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

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. The dialog lists your own sets first, then the built-in packs, each with a line saying what it covers.

Either way, you then choose which environments the grant covers. Leave every environment unticked and the grant covers all of them.

Expires (optional) sets a date after which the grant stops working on its own. Leave it empty to grant indefinitely. An expired grant stays on the list, marked Expired, so you can see the access lapsed rather than wonder who removed it.

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.

Who can do what

The Who can do what panel at the top of the page gives one person a built-in pack in one step. Pick the Person and the Pack, then choose Give pack. A message confirms it. A pack given here covers every environment with no expiry. To narrow it to some environments or set an expiry, open the person below and change the grant. Only members are offered, since admins can already do everything.

What members can do in each tool

Below it, What members can do in each tool has one row per connection, with two choices: Members can read and Members can change. Each is a dropdown.

Choice	What it means
Everyone	Every member, including people who join later. This is where reads start
Nobody	No member, apart from anyone who reaches the tool through another grant. This is where changes start
Choose people…	Only the members you pick. A dialog asks who, and Edit people under the dropdown changes them later

Each choice saves as soon as you make it and confirms with a message, such as “Members can change Northflank.” Picking people grants them the connection’s read or changes pack in every environment, and the rows stay in step with the grants further down the page, so a change made in one place shows in the other. Choosing Everyone for changes also answers any member waiting for that pack under Waiting for a pack.

When members outside the choice still reach the tool through a permission set or a single ability, the row says how many and through what, and naming a set opens it. Under Everyone for reads, the row also says how many members are left out, such as by No access. Changes always follow your approval rules, whoever makes them.

Setup shows the same table in its Who can do what step, so what you chose there is already here. See Setting up your workspace.

Built-in packs

Every connection comes with three permission sets that Firefight keeps up to date for you, listed under Built-in packs. They are named after the connection.

Pack	What it covers
Northflank: read	Every capability on the connection that only reads
Northflank: changes	Every capability on the connection that changes something
Northflank: everything	Every capability on the connection, reads and changes
Changes everywhere	Every capability that changes something, on every connection, one pack for the whole workspace

When the tool adds a capability, it joins the right packs on its own, so whoever holds a pack gets it straight away. Renaming a connection renames its packs, and disconnecting it removes its packs and every grant of them. Changes everywhere takes in each new connection as you connect it.

You cannot edit or delete a built-in pack. Open one to see what it covers, and why it cannot be changed. To pick abilities one by one, make your own set. Grant a pack like any set, to a person, an agent or a service key, scoped to environments and with an expiry if you like. Granting Northflank: changes scoped to Development, for example, lets someone restart services there and nowhere else.

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.

To delete a set, open it and choose Delete set. Firefight asks first and says how many people, service keys and agents hold it, since they all lose it at once. A message confirms each change to a set: making it, ticking or unticking an ability, and deleting it.

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.

Note

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

Changing and removing access

Open the person or key to see everything they hold.

Each grant shows the ability or set, its risk level (read, write or destructive), which environments it covers and when it expires. Click the environment button to change the scope, or the expiry button to set, change or clear the date, without regranting. The bin icon revokes the grant once you confirm, and a message says it was revoked.

Revoking takes effect immediately.