Give an AI agent scoped access to production flags

Why agents need their own scoped tokens

An agent that shares a person's login or an all-powerful API key can do anything that person can, and the audit log can't tell the two apart. Least privilege for agents means three things: a separate identity per agent, a scope that covers only the project, environments and actions the task needs, and a short life with a quick way to revoke it.

Flagger.gg has four kinds of credential, and only one is meant for agents:

Every token is stored only as a SHA-256 hash and shown once, when it's created.

Steps

1. Decide what the agent needs. A coding agent that ships its own changes usually needs read, create, target, rollout and kill. An on-call or monitoring agent may need only read and kill. Add request if the agent should be able to ask a person for changes it can't make itself.
2. Create one token per agent. In the console's Tokens page, or with the CLI as an org owner or admin, name the token after the agent so the audit log reads clearly, and pick its environments, actions and expiry:

   flagger tokens create --kind agent --project shop \
     --name "Claude Code, checkout repo" \
     --envs development,production \
     --actions read,create,target,rollout,kill,request \
     --expires-days 30

   The secret is printed once. Agent tokens last 90 days at most; a token made with no actions can only read.
3. Hand the token to the agent, not to the repo. Put it in the agent's environment as FLAGGER_TOKEN, or in the MCP client's Authorization header, so it stays out of version control.
4. Check what the token can do. flagger whoami --json prints the token's name, project, environments and actions. Over MCP, the agent only sees the tools its actions allow: a token with read and kill sees flags_list, flag_get, flag_eval, requests_list, request_get and flag_kill, and nothing that turns a flag on.
5. Protect the flags an agent must never flip. A person turns on the Protected switch in the flag's drawer in the console (admin tokens can set it through the API). Agents can then only kill it. They can't edit its description, and any other change is refused, or with approvals on becomes a request for a person.
6. Turn approvals on for production if you want a person in the loop. In the project's settings, approvals mode lets agents roll out in production up to a cap (10% by default) and turns anything wider into a request a person approves. See human approval for agent changes.
7. Review, renew or revoke. The Tokens page shows each token's last use and expiry. Renew an agent token for another 90 days, or revoke it, and its next call fails with 401 unauthorized.

What each action allows

A token needs the action for a change even to ask for it: an agent without rollout can't file a request to turn a flag on. The refusal is 403 forbidden and names the missing action.

What no agent token can do

• Approve or decline requests. Approval is for people only, and there is no approve tool in MCP.
• Archive or protect flags, change the project's policy, or make, renew or revoke tokens.
• Turn on a flag that carries a not-ready reason without passing confirmNotReady (--confirm-not-ready in the CLI); bulk changes refuse such flags.
• Write without a note. Every agent write records the token's name, the run, the note, the state before and after, the client and the IP (see the audit trail).
• Go past its rate limits: 30 writes a minute and, with approvals on, 5 changes to one flag an hour. Kill is exempt from both.

Where the scope stops

Agent tokens are scoped by project, environment and action, not by individual flag. To fence off single flags, protect them. Tokens last up to 90 days, rather than being minted for one session, so give each agent its own token and a shorter --expires-days if the work is short.

Other services handle agent access differently. LaunchDarkly's hosted MCP server, for example, signs in with OAuth and acts with the permissions of the member who authorized it, so you limit it with that member's role, including custom roles (LaunchDarkly's hosted MCP docs, checked 2026-11-02).

FAQ

How do I give an AI agent safe access to production feature flags?

Give it its own token, scoped to one project, the environments it works in and the actions it needs, with an expiry. Protect the flags it must never change, and turn approvals on so anything wider than a small rollout waits for a person.

Can I give an agent read-only access to flags?

Yes. An agent token with only the read action can list flags, read their history and explain evaluations, and its MCP client sees no write tools. A token created with no actions gets read alone.

Can an agent token approve its own change?

No. Only a person can approve, signed in to the console or using a flagger login user token. Agent and admin tokens can't approve.

How long does an agent token last?

90 days at most, or less if you set an expiry when you create it. You can renew it for another 90 days or revoke it at once from the Tokens page.

Can an agent turn off a protected flag?

Yes. Kill always works for anyone who can write, protected flags included, so an agent can stop a bad release. Any other change to a protected flag is refused or waits for a person.