Choose your setup - Failproof AI

Local enforcement

Set a machine up with no Cloud key and take a policy pack. Use this when you need immediate guardrails without sending session data to Cloud.

Failproof AI Cloud

Add centralized sessions, audits, online evaluations, dashboards, alerts, and fleet policy deployment.

Enterprise deployment

Use organization controls, scoped keys, private infrastructure, and deployment-specific security requirements.

Enforce locally

Run failproofai config without a key, then take a pack with failproofai policies add FailproofAI/policies. In a terminal, pick Not now — stay local when setup asks to connect to Cloud; with no terminal and no FAILPROOFAI_CLOUD_TOKEN, it stays local on its own. The daemon and hooks enforce on the machine, and no session data is sent to Cloud. To connect later, follow the steps below.

Recommended production path

Connect a non-production machine with transcript capture enabled.
Verify sessions and evaluations in Cloud.
Create an audit for a known failure mode.
Deploy the first policy in observe mode.
Expand to production after reviewing matches and false positives.

Connect a machine to Cloud

Dashboard
CLI

Go to Administration → Keys and create a key with events:add and policies:pull.
Copy the one-time secret to the target machine.
After running the CLI connection command, go to Admin → enforcement and confirm the machine appears.
Go to Observe → Events and confirm its first event arrives.

The key drawer shows the two grants needed by a connected machine: event ingestion and policy delivery.

The new API key drawer used to grant event ingestion and policy delivery permissions.

After connection, the machine should appear in enforcement with its desired and reported policy state.

The Enforcement fleet with an enrolled machine expanded to show its desired policy state and deployment status.

The first arriving event confirms that the daemon can deliver data to Cloud, independently of policy deployment.

The live event stream showing recent agent, model, and tool events.

Continue only after both the machine and its first event are visible.

Read the one-time secret into the shell. read -s takes it at a prompt that does not echo, so it never appears in a command or in shell history:

read -rs FAILPROOFAI_CLOUD_TOKEN && export FAILPROOFAI_CLOUD_TOKEN

Then set the machine up, choose its policies, and name it:

failproofai config

failproofai policies add FailproofAI/policies
failproofai config --machine-label checkout-runner-01
failproofai config --status

failproofai config does the whole setup — daemon, hooks for every agent CLI it finds, and the Cloud connection — then chooses no policies, which is what the second command is for.The label comes after connecting, not during: failproofai config --machine-label <name> renames a machine that is already connected, and on one that is not it does nothing but say so.Add --no-transcripts when transcript content must remain local.In CI, set FAILPROOFAI_CLOUD_TOKEN from the secret store instead of read -s, and keep shell tracing (set -x) off, or the trace prints the key.

On a machine that is already set up, failproofai config --connect <url> enrols it and nothing else. Do not use that form for a first install: it returns before the daemon or any hook is in place, leaving a machine that shows up in Cloud but collects and enforces nothing.

Connecting to Cloud verifies event ingestion and policy delivery independently. A key may therefore be valid but missing one required permission. Use failproofai config --status to see which capability is configured.

Cloud setup writes local credentials only after the relevant capability succeeds. A failed verification does not leave a machine looking connected when it is not.

Local enforcement

Failproof AI Cloud

Enterprise deployment

​Enforce locally

​Recommended production path

​Connect a machine to Cloud

Enforce locally

Recommended production path

Connect a machine to Cloud