Step Functions AI agent tools pin workflows but not runs

AWS made Step Functions workflows available as AI agent tools on Oct. 29, 2026, through Amazon Bedrock AgentCore Gateway. The agent decides when to run a workflow and what input to pass. Step Functions then runs each step exactly as defined, so the agent can't skip an approval or reorder a payment step. Existing Standard and Express workflows work without changes, and there is no Lambda function or MCP server to write.

The catch is in the connector's design. Four of its ten operations are pinned to one state machine you choose. The other six act on whatever execution ARN or task token the agent hands over, and only the gateway's IAM role limits those. If that role says states:*, an agent built to run refunds may be able to stop or read other workflows' runs.

What changed in Step Functions and AgentCore Gateway?

AgentCore Gateway connects agents to tools over the Model Context Protocol. It now has a built-in Step Functions connector, with the connector ID states. You add a target to a gateway, pick which operations to expose, and each one appears to the agent as a tool named after the target, such as orders___StartExecution.

AWS's example is a support agent that starts a refund workflow. Step Functions then runs the eligibility check, the manager approval and the credit steps in order. The agent can also look up its runs afterward. The feature is available in every Region that has AgentCore Gateway, and you pay standard rates for both services: Step Functions state transitions and Gateway tool calls.

Which Step Functions operations can an agent call?

The connector exposes ten operations, and they fall into three groups.

• Pinned operations. StartExecution, StartSyncExecution, ListExecutions and DescribeStateMachine run against the state machine ARN you set in the target. The agent never sees that ARN. If it tries to pass a different one, the gateway rejects the call with "cannot set parameter(s): [/stateMachineArn]."
• Execution ARN operations. DescribeExecution, GetExecutionHistory and StopExecution take an execution ARN from the agent. They aren't tied to the pinned state machine.
• Task token operations. SendTaskSuccess, SendTaskFailure and SendTaskHeartbeat complete or extend a paused step. IAM can't limit these to specific executions, so AWS's guidance is blunt: any agent with a valid task token can complete that task, and you should treat task tokens as secrets.

AWS's own wording is that pinning and IAM "are complementary controls, not alternatives." Pinning decides which workflow starts. IAM decides which runs the agent can touch later.

Should you expose Standard or Express workflows to agents?

The workflow type decides which tools actually work. Exposing a tool that the workflow type doesn't support creates a target that fails at call time.

Scroll sideways to see all 3 columns.

Question	Standard workflow	Express workflow
Start and get a result in one call (StartSyncExecution)	Not supported	Yes
Start, then check back later	StartExecution, then poll DescribeExecution	Start only; runs can't be looked up by ARN afterward
List past runs (ListExecutions)	Yes	Fails with StateMachineTypeNotSupported
Read or stop a run by ARN	Yes	Fails with InvalidArn
Pause for a person or system (.waitForTaskToken)	Yes	No callback pattern

For most business agents, Standard is the safer default. A Standard run can last up to one year and keeps an execution history. Refunds, account changes and anything with a human approval need the history, the lookup and the pause. Express fits quick, read-only lookups where the agent wants an answer in one call. An earlier post covered why a paused AI workflow needs a written contract, and the task-token step is where that contract lives here.

How should you scope the gateway's IAM role?

Start from the Step Functions tutorial's pattern. Its inline policy has two statements, because execution ARNs are a different resource type from state machine ARNs:

1. Allow StartExecution, ListExecutions and DescribeStateMachine on the one state machine ARN.
2. Allow DescribeExecution, GetExecutionHistory and StopExecution on that machine's execution ARNs only, in the form execution:<state-machine-name>:*.

Then check three things the documentation calls out:

• Every pinnable operation needs its pin. If you leave stateMachineArn out of an operation's settings, the target still creates, but that tool fails on every call.
• One role covers every target on a gateway. If two workflows need different IAM boundaries, AWS says to use a separate gateway for each. A refund workflow and a reporting workflow shouldn't share one.
• Run input and output are one parameter away. DescribeExecution returns metadata only by default, but includedData is a field the agent can set, and ALL_DATA returns the run's input and output. If a workflow's input carries customer data the agent shouldn't read, don't expose DescribeExecution on that target.

Only add the task-token operations if the agent is meant to finish a paused step. If a person approves refunds, keep the token with that person's tool, not the agent's. Pairing the agent that requests an action with a separate approver is the separation of duties pattern applied to Step Functions.

What still sits outside the connector?

Pinning and IAM control what the agent can reach. They don't decide whether a particular call should happen. For per-request checks on identity or arguments, AgentCore Gateway interceptors are the place to add policy. To keep one busy agent from starting hundreds of runs, Gateway rate limits can be set per target or tool.

Audit is simpler than it looks. Runs started through the gateway appear like any other execution, with the gateway's service role as the caller in CloudTrail. That shows the gateway started a run, so record which agent session asked for it on your side.

Recommended first step

Pick one Standard workflow that already has a human approval step, such as refunds or credits.

1. Create a dedicated gateway for it with IAM authorization.
2. Expose only StartExecution, DescribeExecution and DescribeStateMachine, each pinned or scoped as above.
3. Write the gateway role with the two-statement policy, and leave out the SendTask operations.
4. Run a test where the agent passes another workflow's execution ARN, and confirm IAM denies it.
5. Check CloudTrail for the run, then decide whether StopExecution or GetExecutionHistory earns a place.

If you want help choosing which workflows an agent may run and how to scope them, see process automation.

Sources and scope

• AWS What's New, AWS Step Functions workflows now available as AI agent tools, Oct. 29, 2026.
• Amazon Bedrock AgentCore Developer Guide, AWS Step Functions as connector target, read Oct. 30, 2026. Operation details apply to connector version 1.0.0.
• AWS Step Functions Developer Guide, Use your Step Functions workflows as tools for AI agents, read Oct. 30, 2026.

This post is based on AWS documentation. BaristaLabs has not tested the connector for this post, and AWS may change operation behavior in later connector versions.