The gateway
The gateway is the part of Firefight that stands between anyone acting, a person, an API key or an AI agent, and anything that action touches. It answers four questions, and the dashboard has one page for each.
| Question | Page | Who sees it |
|---|---|---|
| Which AI agents act under their own name | Agents | Admins and owners |
| Who may do what, and where | Permissions | Admins and owners |
| What is waiting for someone to say yes | Approvals | Everyone |
| What was done, by whom, and whether it was allowed | Activity | Admins and owners |
All four live under Gateway in the dashboard sidebar, and everything on them is also reachable over the API and MCP, so an agent can administer access the same way an admin does. Approvals is the one members see, and it carries a count of requests waiting on a decision, so a responder sees at a glance whether anything needs them. Admins also see a count on Permissions when someone has asked for a pack.
Why one gate
Section titled “Why one gate”An AI agent connected to your workspace can read a database, open a ticket or change a routing rule through the same connections your team uses. Giving it a login to each tool means trusting it with everything that login can do. The gateway is how you avoid that.
You connect the tool once and its capabilities arrive switched on. Your members can use the ones that read, and you grant the ones that change something, usually with a connection’s built-in pack. A grant says who may call a capability and in which environments. An agent holds only what you gave it, never what its creator can do. When a capability is sensitive, an approval rule can hold the call until a person approves it. And whatever happens, it is written down.
The same gate governs Firefight’s own settings. A member who is not an admin can be given runbooks or webhooks without being given everything else, and the change they make is recorded like any other.
What the gateway covers
Section titled “What the gateway covers”The gateway checks every action a person or machine takes outside of responding to an incident.
- Connected tools. Every capability from an integration, whether called by a person on the dashboard or by an agent over MCP.
- Workspace configuration. Statuses, severities, types, incident roles, custom fields, forms, runbooks, the catalog, alerts and alert sources, routing rules, webhooks, the handbook and workflows.
- Halon. Asking Halon and starting investigations, chats, what Halon remembers, reading the resource map, reading incident transcripts, sending what a page would send in Halon’s browser, and posting as Firefight in a channel.
- Approvals themselves. Approving or denying a request is an action with its own permission.
Declaring, updating and closing incidents is something every member can do. The gateway does not stand in the way of that, and when a person does it from Slack or the dashboard the change is recorded on the incident’s timeline rather than in Activity.