Deploying agents with fleet Missions

Connect the services your agents need, approve their shared policy and let each job request its own access through a Mission. The runtime uses an agent key and the Mission’s Passport. Provider credentials stay in STACK.

Connect the service

Open Services and connect the account the fleet will use. Complete the provider’s sign-in or credential setup there. Keep the returned connection ID so the policy and Mission name that exact account.

Approve the fleet policy

The policy names the available connections and actions, trusted provisioning agents or workload identities, and shared limits. In this example it permits posting to Slack channel C123. It also defines how many workers may enroll and how long their identity remains valid.

Submit the policy through the API, CLI or MCP. Open the resulting request in Approvals, inspect the complete policy and approve it. Retry the same submission with its approval ID and idempotency key to activate it. A later expansion requires approval of the exact new policy revision.

Declare allowed incoming data sources on each destination connection. An empty allow_data_from list permits no cross-service transfer. Each Mission can request a narrower list.

Enroll the workers

Use the provisioner named in the policy to enroll workers. Each worker has its own Ed25519 key. STACK verifies its signed enrollment challenge before recording membership, and checks the policy’s enrollment and member limits.

The SDK can generate and store the worker key locally. Repeat enrollment with the same idempotency key and a fresh proof to renew its identity lease. Revoked membership cannot be renewed.

Start a Mission

The worker submits the job description, exact requested_access and limits. For a support update, request chat:write on the connected Slack account with slack.post_to_channel restricted to C123, allowing 20 calls in 900 seconds.

An allowed start returns the Mission ID and Passport. The worker does not request another service grant or wait for routine approval. A request outside the policy is refused.

Call through STACK

Send the Passport with the proxy call and use a stable operation ID for that action. The request must match the permitted endpoint and channel. STACK checks the remaining allowance before injecting the Slack credential.

A request for another channel is refused. Keep the same operation ID only when retrying the unchanged request, so a lost response cannot turn into a second write.

Continue or finish the work

Use Mission renewal to obtain another Passport while the Mission and its policy remain valid. The Mission ID, authorized access and recorded usage stay the same. Checkpoints and checkout still apply to the Passport run.

Complete the Mission when the job ends, including the output if its declared schema requires one. Revoke the Mission to stop future calls, or revoke the fleet policy to stop work across the fleet.

How much STACK sees depends on what your agent does

Available checks depend on the agent's actions:

• A proxied call applies the scope wall. Prompt-injection scanning applies on paths that call the detector pipeline.
• Drift signals need history. They compare this run against how the agent normally behaves, so they sharpen over many calls, not on the first one.
• Mission caps and counterparty checks require a bound Mission. Passport checkout review is a separate call.
• Delegation, skill, and long-run behavioral signals turn on when your agent actually delegates, calls a skill, or runs long enough to build a baseline.

A one-call agent does not exercise every detector. Configure the controls that apply to the agent's actual work.

See it live

/attack is our public demo: a live inbox a STACK-governed agent reads and replies to, open for anyone to try to break. Send it an attack and view the resulting checks on the board.