Missions

A Mission defines one job, the access it needs and the limits that apply while it runs. Starting a fleet Mission checks that request against an operator-approved policy and returns a Passport with the permitted access. Calls, renewals and the final result remain attached to the same Mission.

How a Mission becomes permission

The operator first connects the service and approves a fleet policy. The policy sets the available connections and actions, the identities allowed to enroll agents and the limits shared by the fleet.

An enrolled agent submits a Mission with the access needed for its job. For a Slack support update, requested_access names the connected account, the chat:write scope and the slack.post_to_channel intent with channel C123. The Mission can also request a smaller allowance, such as 20 calls in 900 seconds.

STACK resolves the intent to POST /api/chat.postMessage with body.channel equal to C123. It checks that the connection, request constraints, data sources and limits fit the fleet policy, then stores the resolved permission and issues the agent a Passport. A broader request is refused without starting a partially authorized job.

On each call, STACK verifies the Passport and checks the current policy, membership, Mission and request before adding the stored Slack credential. The agent receives the permitted response and never receives the credential.

Lifecycle

• Start an allowed Mission and receive its scoped Passport. You can also open the Mission and issue its Passport in separate calls. Every Passport is issued for exactly one Mission, and Missions are available on every plan.
• Run with a stable operation ID for each action. STACK records the authorization decision and reserves the required allowance before dispatch.
• Renew the Passport while the Mission, membership and policy remain valid. Renewal preserves the approved access and existing usage.
• Complete the Mission with its output. If an output schema was declared, the output must match it before completion succeeds.
• Revoke the Mission to stop new admissions and renewals. Completing or revoking a Mission revokes every Passport bound to it. Requests already committed to an external service cannot be undone.
• Review the signed timeline and add a human Operator review after the work ends.

Caps

Fleet Missions reserve calls and concurrent work against both the Mission and the shared fleet allowance. They can also restrict Drop-off volume and covered spend. Starting another Mission or agent, renewing a Passport or retrying a request does not reset the fleet’s usage window. A hard spend limit accepts only operations whose maximum cost STACK can establish before dispatch. GET /v1/missions/:id returns the authorized access and current usage.

A Mission is also not a legal or operational mandate. An authority binding can pin one or more Mission IDs so externally proved authority is usable only inside those jobs. The binding still owns the principal, receiver, purpose, scope, proof lineage, and expiry. See Authority.

Evidence

Replay reads the Mission’s signed records in time order. Completion stores the supplied output encrypted and records a salted digest in the signed Mission claim. Authorized output reads return the result and the material needed to verify that digest. Evidence exports retain the signed commitment without exposing the output.

A dossier is a human-authored post-incident account. It requires a same-operator member principal. An Operator review is a separate signed record. Its source, creation, and revision routes require a signed-in dashboard session.

See Missions API, Evidence API, and Passport Lifecycle.