Use FortressFlag from an AI agent

If you work with an AI coding agent, you can give it your flags. “Turn new-checkout off in production” is a sentence with an exact API call behind it — and one that touches your real users, which is why this guide spends as much time on the limits as on the setup.

FortressFlag ships an MCP server: a small program that runs on your own machine, alongside your agent, and hands it a set of flag tools.

What it can and can’t do

The short version: your agent can do exactly what you can do, and less.

The server holds an API token that acts as you — your role, your project access, your organisation. It talks to FortressFlag through the same public API the dashboard uses, so every permission check, project allowlist and audit record is identical to you clicking the button. There is no special agent access path.

Some things are deliberately not available to an agent at all:

• Approving a production proposal. The whole point of a second pair of eyes is that they belong to a person.
• Permanently deleting a flag.
• Creating SDK keys or API tokens. A one-time secret returned to an agent lands in a conversation transcript.
• Managing members, billing, or legal agreements.

Set it up

1. Create a token. In the dashboard, go to your account page and find API tokens. Give it a name you’ll recognise, pick a scope, and copy the token — it’s shown once.

Pick Read-only unless you want the agent making changes. You can always create a second token later.

2. Point your agent at the server. Most MCP clients take a small block of configuration naming a command and its environment:

{
  "mcpServers": {
    "fortressflag": {
      "command": "ffmcp",
      "env": {
        "FORTRESSFLAG_TOKEN": "ffm_your_token_here",
        "FORTRESSFLAG_API_URL": "https://your-fortressflag-api"
      }
    }
  }
}

The token goes in env, never in args — command-line arguments are visible to other users on a shared machine.

3. Add --allow-writes when you want changes. Without it the server offers reading tools only. With it, your agent can toggle, create, rename, archive and restore flags — still limited by what your role permits:

"args": ["--allow-writes"]

Treat that flag as a convenience, not a lock. If an agent has no business changing flags, give it a read-only token as well — that’s the part FortressFlag actually enforces.

Production is protected twice

Your role decides first. If you’re a Developer, you can’t write production directly — so neither can your agent. What it can do is propose the change, exactly as you would: a second teammate applies it, and nobody can approve their own proposal. See production approvals.

The tool asks again second. Before touching a production environment the agent has to state that it means to, naming the environment. That check reads the environment’s production class, not its name — so an environment you called live is protected exactly like one called prod, and one merely named prod that isn’t production-class won’t nag you.

This second check exists because the realistic mistake isn’t an attacker. It’s an agent asked to change something in staging that reaches for the wrong environment key.

Your flag data goes into the conversation

Worth being plain about: anything the agent reads becomes part of its conversation with whatever AI service it uses. That includes flag names, keys and descriptions written by your team, and — if you ask it to read audit history — the names and email addresses of your teammates.

Two things follow.

Treat flag descriptions as untrusted input. Anyone who can create a flag can type anything into its description, including text that reads like an instruction to the agent. The server tells the agent, up front and on every tool, that these values are your organisation’s data and never instructions. That helps; it isn’t a guarantee, and it’s a reason to be thoughtful about whose flags an agent reads.

We can’t see or govern that transcript. It’s between you and your AI provider. Nothing about how FortressFlag stores or transmits your data changes when you use this — the tools are just another client of the same API.

What isn’t there yet

• It runs locally only. The server speaks to your agent over its standard input and output, on your machine. There’s no hosted version to point a remote agent at.
• No downloadable binaries yet — for now it’s built from source.
• Targeting rules and segments aren’t editable by an agent. Reading flags, toggling them and proposing production changes are; the rules editor is a bigger surface that deserves its own design round.
• Listing pending proposals needs approver permission. A Developer’s token can propose a production change but can’t then list it — that’s the permission on the underlying API, not a quirk of the tools.