different ai agent rules per team

The Scopes

A Typical Persona Map

Failproof’s managed console lets admins assign policy sets by persona; ask us how persona assignments map to machine deployments in your setup. You can also script per-machine assignments yourself with fp fleet deploy.

Scripting per-Machine Assignment

Label machines right after enrolling (failproofai config --machine-label infra-alice-mbp); the flag renames a machine that is already connected, and hostnames rarely survive laptop replacement. fp fleet deploy replaces the machine’s set with the computed result: --add keeps what is there, while --set replaces it, so include the base policies when you use --set. Fleet commands exit with an error under an API key, so run this as a signed-in admin, not from unattended CI. Check the JSON shape of fp fleet list in your installed version before relying on the field names.

fp login                             # fleet commands need a signed-in session with policies:write
fp policies publish terraform-plan-only ./terraform-plan-only.policy.mjs
fp policies publish protect-route53 ./protect-route53.policy.mjs

# Deploy the infra-admin set to every machine labelled infra-*
for id in $(fp --json fleet list | jq -r '.[] | select(.label | startswith("infra-")) | .id'); do
  fp fleet deploy "$id" --yes \
    --add terraform-plan-only:enforce \
    --add protect-route53:enforce
done

When Scopes Overlap

• Built-in policies evaluate before custom ones, and the first deny stops evaluation. A repository cannot “allow” its way past a central deny.
• Policy parameters (for example allowPaths on block-rm-rf) come from the first scope that defines them, in project, local, user order.
• Which pack policies are on is machine-wide, not per repository, regardless of --scope.
• Repository policies are code that anyone with merge rights can change. Treat .failproofai/ like CI config and require review on it.

Credential-Keyed Rules Are Harder to Escape

Machine-based assignment assumes the right person is on the right laptop. Credential-keyed rules assume nothing: they apply stricter checks whenever a command names an elevated profile, whoever runs it. That is the better fit for rotating roles like on-call; see on-call guardrails.