Concepts

Workflows & steps

A grant says what an agent may do. A workflow says in what order, and under what conditions. It’s the structure that lets a multi-step agent plan be authorized step by step — so a run can’t skip ahead, jump a gate, or claim a scope the plan never gave a given step.

A workflow is a registered plan

Where a single tool call is one action, a workflow is the sequence they add up to — scan a manifest, plan a patch, open a PR. You register the plan with the Authority up front: its steps, the scopes each step needs, the dependencies between them, and any approval gates. Once registered, a run that declares it’s executing that workflow is held to the plan.

Figure 1. A workflow’s steps, each with its own scopes. Step 3 is privileged and sits behind an approval gate; the authority won’t mint for it until its prerequisites are complete and the gate has passed.

What the Authority checks per step

When a request names a workflow and a step, the mint becomes a check against the plan. The Authority confirms the step’s prerequisites are complete, that any approval gate on the step has been passed, and that the step is only claiming the scopes its definition granted it. A step can’t run before the steps it depends on, and it can’t reach for authority the workflow didn’t give it.

Note

Workflow tracking is optional per agent. With it off, an agent is still bounded by its grant; with it on, it’s additionally bounded by the plan — prerequisites, gates, and per-step scopes. It’s the difference between “may do these things” and “may do these things, in this order, once these conditions hold.”

Steps carry into the token

The current workflow_id and workflow_step ride inside the intent token’s intent object, alongside a hash of the steps completed so far (step_sequence_hash). That means a resource server can independently see which step it’s serving and detect a skipped one — the plan isn’t only enforced at mint, it’s carried on the wire.

▶Where workflow definitions come from — and the scaling tradeoff

Registering a workflow is a governance action: only authenticated administrators should be able to create or change one, and definitions should be validated for safety — no cycles in the step graph, sensible scope restrictions per step, approval gates on high-privilege steps. The Authority holds the workflow registry the same way it holds the agent registry.

There’s an honest tradeoff: every new workflow has to be registered, which is more governance surface than plain OAuth. The mitigation is automation — workflows can be inferred from an agent’s source and tools and registered from CI/CD, rather than authored by hand. draft-goswami-agentic-jwt §9.3

Keep reading