Agents
An agent is an AI that takes part in your workspace under its own name. It declares incidents, raises and picks up work, pulls people in and reports what it found, and every one of those actions is recorded as the agent’s, not as the work of whoever set it up. An agent holds only the abilities you grant it, so it starts able to do nothing.
Go to Gateway → Agents. The page requires admin access.
Everything on this page is also available over the API and as MCP tools, to an admin. Both check a permission that cannot be granted to anyone, so an agent can never create another agent or issue itself a new token.
Creating an agent
Section titled “Creating an agent”Give it a name people will recognise on a timeline, such as Support agent, and a short line saying what it does. The slug is the short machine-readable name, filled in from what you type, and it is fixed once the agent exists because grants and the activity log record it.
Creating the agent hands you its token once, on the screen. Copy it then. It is never shown again, and if you lose it you issue a new one rather than recovering the old.
Configure your agent to send that token as a Bearer header, the same way any other Firefight credential works.
Authorization: Bearer ff_4kWm2xPqR8vNcT6yBhJd3fLzGaU9sEnQoXwAA brand new agent can authenticate and nothing else. The row says None granted, so it can do nothing until you give it something under Permissions, where it appears alongside your people and service keys.
What to grant it
Section titled “What to grant it”Start with what the agent actually needs and add to it. An agent that triages support tickets and opens incidents needs incidents: read and incidents: create. One that also works the incident needs incidents: update, which covers raising work, taking it, finishing it, escalating, inviting and linking.
Reaching a connected tool is always a separate grant, and can be limited to particular environments. See Permissions for how grants and environments work, and Approvals for making a risky ability wait for a person.
An agent never inherits anyone’s access. Creating it as an admin does not make it an admin.
Tokens
Section titled “Tokens”An agent can hold more than one token at a time, which is what makes rotation safe. Issue a new token hands you a second working credential while the first keeps working, so you update the agent’s configuration on your own schedule and nothing goes down in the middle. When the agent is running on the new one, open Tokens on its row and revoke the old.
Revoking a token stops it immediately. Nothing else moves: the agent keeps its name, its abilities and everything it has already done, because those belong to the agent rather than to a secret.
The Tokens dialog lists every working token with when it was issued and when it was last used, so you can tell which one is live before revoking anything. An agent with no working token cannot act, and its row says No token rather than looking like it is running.
Disabling and deleting
Section titled “Disabling and deleting”Disabling an agent stops it acting while keeping its row, its slug and its grants. The row stays on the list so you can switch it back on.
Deleting an agent takes its tokens and its abilities with it. What it did stays on the timelines it touched, so a past incident still names the agent that worked it.
Agents and service keys
Section titled “Agents and service keys”Both are credentials that act without a person behind them, and both start with no access. The difference is what the record says afterwards.
| Agent | Service key | |
|---|---|---|
| Where you make it | Gateway → Agents, the API, or MCP | Settings → API Keys, the API, or MCP |
| Who the timeline names | The agent, by name | The key, by name |
| Rotating the credential | Issue a second token, revoke the first | Create a second key, delete the first |
| Best for | An AI taking part in incidents | A pipeline or script calling Firefight |
Use an agent when something will appear on an incident timeline as a participant. Use a service key when something is plumbing, such as an alerting pipeline that declares incidents and never speaks again.
Seeing what an agent has done
Section titled “Seeing what an agent has done”Every governed action an agent takes lands in Activity, including the ones that were refused. Its work inside an incident also shows on the incident’s own timeline, where an agent is marked as a machine rather than shown with a person’s initials.
See Connect AI agents for what an agent can actually do once it is connected.