Security

1.1 Where the work happens

A customer installs the FireFunc runner on computers it owns and pairs each one with a workspace. When an agent takes a task, the runner checks the repository out on that machine and starts an AI engine there — Claude Code, Codex, Copilot CLI, Gemini CLI, Cursor CLI or Antigravity — signed in to the customer’s own account with that engine’s vendor.

FireFunc writes the brief the engine starts from. Everything after that — the engine reading files, running commands and talking to its vendor — happens between the machine and the vendor. FireFunc runs no AI models of its own, so nothing it holds is used to train one.

A customer may instead give an agent an engine that runs in its vendor’s cloud — GitHub Copilot’s coding agent, Cursor’s cloud agents or a Claude Code routine. FireFunc then sends the vendor the brief with the key or connection the customer gave it, and the vendor works on the repository in its own cloud, under the customer’s account. The secret scan before a push and the local viewer below are the machine’s, and do not apply to those engines: with no scan of their changes, FireFunc never merges their pull requests on its own. Code is still taken out of what they report — their summary, their reasoning and why a run failed — before FireFunc stores it, and each removed block is marked “[code left out]”.

1.2 What FireFunc stores

• From the tools you connect: tickets and messages (titles, descriptions, comments, labels, assignees and the attachments people add); pull request and issue details from GitHub, including the paths of changed files and how many lines changed, but not the changes themselves; Sentry issues and events, with the file, function and line of an error but without its source lines or local variables; and what your systems send to your FireFunc webhooks, as it was sent, less any diff it carries.
• From the runner: each run’s status, branch and pull request link, and, if it failed, the reason in one line; each step it took, as one line (a file path, a command’s programs and subcommands such as “npm test”, a tool’s name, a website or search, or a remark from the agent), never the rest of a command, a file’s contents or a command’s output; the summary the agent wrote at the end; what the run used, as the engine counted it (tokens by model, turns, time, the engine’s own estimate of their price, whether the engine was signed in to a plan or an API key and whether the plan drew on its extra usage, the engine’s version, and the plan’s usage readings when the engine reports them); where the secret scan found something, if it did; and the machine’s host name, platform, runner version, the engines it found, how much of an engine’s usage allowance is used where it can read that, and the names of its sign-ins. Code is removed from the summary, the reason and the steps before FireFunc stores them.
• Written by FireFunc: the brief each run starts from, kept until 7 days after the run finishes.

The Privacy Policy lists each item, and says how long each is kept.

1.3 What never reaches FireFunc

• Your repository. The parts of tool events that carry code — the diff around a review comment, a CI check’s output, the source lines and variables in a Sentry stack trace — are removed before FireFunc stores an event. What people write into a ticket, comment or message is kept as they wrote it, code included.
• File contents, diffs, command output and the engine’s transcript. The runner can show them on the machine, in its local viewer.
• The keys and sign-ins the engines and tools use on the machine. The runner reports a sign-in’s name, state and expiry, never its token.

Runner 0.8.3 and later scan an agent’s change for secrets on the machine, before the change is pushed, so the change never has to be sent to FireFunc to be checked. A key or token of a known kind stops the push. A weaker match — a value assigned to a name like password, as often a test fixture as a secret — is pushed and reported, and FireFunc will not merge that pull request on its own: a person decides. The scan reports a file, a kind and a line for each finding — never the secret. An older runner reports no scan, and FireFunc does not merge its pull requests on its own either.

When an agent asks a connected tool a question in the middle of a run, FireFunc fetches the answer with the organization’s own connection and passes it to the engine. It does not keep the answer.

6.1 What an agent may use

What FireFunc gives a run is bounded by the agent’s grants, which are shown on its page: the connected tools it may read or write through FireFunc, the MCP servers put on its configuration, and the writes FireFunc carries out for it when the run ends. For an agent to write to a tool through FireFunc in the middle of a run, it needs a write grant for that tool and Writes switched on for the account under Organization → Connections; FireFunc carries out each such write and leaves a receipt on the task. The grants do not bound the machine: an engine on a paired machine also has that machine’s shell, files and network, and can reach whatever they reach — a command-line tool already signed in there, for one.

For engines whose command line takes a list of forbidden tools — today Claude Code and Copilot CLI — FireFunc names the tools it knows the run may not use and passes them as denied: the write tools a shipped connection withheld, every tool an organization’s own MCP server was seen to publish that was not ticked for agents, and — for an agent that may read that server but not write to it — every ticked tool not marked read-only. The organization marks each tool itself on Organization → MCP servers; where it has not, the server’s own mark is used, and a tool nobody marked counts as one that writes. Neither mark is something FireFunc checked. A tool FireFunc has never seen listed cannot be named. We say “denied” rather than “impossible”: we have not shown that every engine enforces its own list in every mode.

In FireFunc itself, creating, editing, activating, pausing and deleting an agent take one permission. Owners, Admins and Members hold it by default — Members through the organization’s Contributor role, which the organization can edit to take it away — and Viewers and Guests do not. Giving an agent steps that write to your tools takes a second permission, which the same roles hold by default. Each agent can be limited to a number of runs a day and a number at once, and each project to a daily budget of runs.

A workspace API key does what its scopes allow, chosen by the owner or admin who makes it, and only scopes that person’s own role holds when the key is made. With agents:write it makes and edits draft agents, which take no work, and pauses and resumes an agent that was switched on before. Switching an agent on, and editing one that is on, needs agents:activate, which is off unless ticked. Installing or writing a skill, and setting a project’s standing instructions, repositories or the work it claims, needs workspace:configure, also off unless ticked — with one exception: making an agent from a template also installs the skills that template names, from FireFunc’s own directory, as launching it from the gallery does. A skill goes into every run of every agent that carries it, so every skill change, that one included, is recorded in the audit log with the skill’s fingerprint, never its text. An app connected through FireFunc sign-in — Claude, for one — acts as the one person who connected it, in one workspace, with the scopes that person allowed and never more than their role allows; the role is checked again on every call. Through such an app, switching an agent on also needs a role that may activate agents: Owners and Admins by default, not the Contributor role. Otherwise what the app makes waits as a draft, with a link for a person to review it and switch it on.

6.2 Merging

Agents open pull requests, and FireFunc merges one in only two ways, each a person’s choice. The first is auto-merge, which is off unless a person whose role allows it — Owners and Admins, by default — switches it on for a project and chooses which kinds of work it covers. Even then, FireFunc merges a pull request only when all of these hold:

• its CI checks have passed, as GitHub reports them;
• no changed file is CI configuration, infrastructure code, a Dockerfile, a dependency lockfile, a database migration, a key or .env file, or under a path the project marks off-limits;
• every run that pushed to it reported the machine’s secret scan, the scan found nothing, and the pull request’s head is still the commit the last scan covered — FireFunc merges that commit and no other, so a commit added after the scan holds the merge for a person;
• the change is within the size the project allows.

The second is a merge step: someone who may give an agent steps that write to your tools can add GitHub’s “Merge a pull request”, which FireFunc carries out after the run. That merge keeps the same secret-scan rule and merges only the commit the scan covered; it refuses a draft or a conflicted pull request and, unless the step turns it off, requires the checks to have passed. It does not apply the project’s off-limits paths or size limit.

Either way the merge is made through GitHub, so the repository’s branch protection and code owners still apply.