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 three questions, and the dashboard has one page for each.
| Question | Page | Who sees it |
|---|---|---|
| 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 three 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 first, and carries a count of requests waiting on a decision, so a responder sees at a glance whether anything needs them.
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, enable the capabilities you want available, and then grant them. 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, and webhooks.
- 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 those changes are recorded on the incident’s timeline rather than in Activity.