AWS Step Functions Now Run as AI Agent Tools: 10 Operations, IAM Risks and a Safe Pilot

30 October 2026 | Announcement: 29 October 2026 | Status: Available in supported Amazon Bedrock AgentCore Gateway regions. An AI agent can decide that a refund, approval, or onboarding action is needed. That does not mean it should improvise the steps of a regulated business process. On 29 October, AWS introduced a direct way to make existing AWS Step Functions workflows callable as AI-agent tools through Amazon Bedrock AgentCore Gateway. The agent chooses when to invoke a workflow and supplies its input; the state machine controls the actual sequence. This is an available product capability, not a future roadmap promise. AWS launch announcement, 29 October 2026.

What actually launched?

AgentCore Gateway now offers a built-in Step Functions connector that exposes selected workflow operations through the Model Context Protocol (MCP). Teams can expose existing Standard and Express state machines without rewriting their workflows, building a custom MCP server, or placing a new Lambda function in front of them solely to translate the tool call. The gateway manages tool schemas and authenticates to Step Functions using its service role. AWS documents the architecture, available operations, and limitations in the official connector guide.

The practical distinction is between an agent deciding and a workflow executing. An agent can request a refund, but a correctly designed Step Functions state machine still determines eligibility checks, required approvals, and the order of downstream actions. This does not automatically make a process compliant: those controls must already exist in the workflow, IAM policies, and application design. AWS uses a refund process as an illustration in its launch note.

What can an agent do? Ten operations, with important boundaries

The connector documents ten operations. Four are configured against a fixed state machine: StartExecution, StartSyncExecution, ListExecutions, and DescribeStateMachine. Six accept an execution ARN or task token supplied by the agent: DescribeExecution, StopExecution, GetExecutionHistory, SendTaskSuccess, SendTaskFailure, and SendTaskHeartbeat. Administrators select which operations become available as tools; this is not a blanket grant to operate every state machine. The AWS operation matrix is the authoritative reference.

For the four state-machine operations, configure parameterValues.stateMachineArn to pin the intended state machine. AWS says a target can be created without this value, but the tool then fails when invoked. Pinning also prevents the agent from changing that state machine ARN in a call. The other six operations cannot be pinned in the same way, making the gateway service role's IAM policy especially important. Follow the target configuration documentation rather than copying a broad-permission example into production.

Three security details architects should not miss

1. Pinning a workflow is not a complete permission boundary

StartExecution can be pinned to a specific state machine, but DescribeExecution, StopExecution, and GetExecutionHistory accept execution ARNs from the caller. Scope the gateway service role to the appropriate execution resources, and do not give an operational agent states:* by default. The AWS security guidance explicitly distinguishes pinned and unpinned operations.

2. Task tokens are sensitive authorization material

The callback operations SendTaskSuccess, SendTaskFailure, and SendTaskHeartbeat cannot be restricted to individual executions through IAM resource-level permissions. AWS says these permissions require "*" and the task token is the effective control. Treat tokens as secrets: restrict their delivery, do not place them in broadly accessible logs or prompts, and expose callback tools only to an agent that truly needs them. This limitation is documented in the connector IAM section.

3. Standard and Express workflows do not behave identically

StartSyncExecution works with Express workflows, while ListExecutions and the documented post-start execution inspection operations apply to Standard workflows. The wait-for-task-token callback pattern also requires Standard workflows. A design that assumes every tool works with every state machine will fail. Choose the workflow type based on audit-history, execution-duration, callback, and response requirements; use the Standard-versus-Express compatibility table.

Where this matters for enterprise AI and SAP teams

Employee onboarding: A governed agent could start an existing IT-provisioning or document-collection workflow, then report its execution status. Finance operations: A support agent could initiate a refund workflow whose eligibility checks and approval gates remain encoded in Step Functions. Incident response: An operations agent could query recent execution failures and point an engineer to the failed step. These are architecture patterns and pilot ideas, not claims that AWS has shipped a native SAP SuccessFactors or S/4HANA connector with this announcement. AWS describes business-workflow and operational-assistant examples in its use-case documentation.

For an SAP landscape, integration with SuccessFactors, S/4HANA, or SAP Integration Suite would still require separately designed APIs, credentials, network connectivity, data mapping, and authorization checks. A Step Functions workflow may call those interfaces, but this AWS release does not itself grant SAP permissions, bypass SuccessFactors role-based permissions, or replace SAP integration governance. If HR data is involved, start with synthetic records and verify data minimization, logging, consent or other applicable legal bases, and who approves each irreversible action.

Availability and cost: do not mistake 'available' for 'free'

AWS states that the connector is available in every AWS Region where Amazon Bedrock AgentCore Gateway is available, with the gateway calling Step Functions in the same Region. This is not a claim of availability in every AWS Region worldwide. AWS also says standard charges apply for Step Functions and AgentCore Gateway. Confirm your exact regional support, execution volumes, tool-call rates, and any additional model or service charges before estimating a production budget. See the availability and pricing statement and official setup tutorial.

A safe 30-minute pilot: prove the guardrails before the demo

Step 1: Choose one low-risk existing Standard state machine that uses synthetic inputs and does not modify real employee, customer, or financial records. Step 2: In the same supported AWS Region, create an AgentCore Gateway target with connector ID states. Expose only StartExecution and, if needed, narrowly scoped execution-status operations. Pin the state machine ARN. Step 3: Configure the gateway service role with the least privileges needed and grant the calling identity bedrock-agentcore:InvokeGateway. AWS's end-to-end tutorial specifies prerequisites and shows the tool invocation flow.

Step 4: Run a successful test, an invalid-input test, and an unauthorized-execution test. Confirm the workflow preserves its approval gates, that the agent cannot substitute another state machine, and that IAM blocks attempts to inspect or stop unrelated executions. Step 5: Inspect the execution history, gateway access controls, error handling, and incurred charges. Do not expand to production data until a process owner and security reviewer approve the outcome. The connector's tool and IAM documentation defines what these checks should cover.

What the announcement does not prove

It does not demonstrate that an arbitrary AI agent will always select the right workflow, supply correct parameters, or avoid unsafe requests. It does not automatically create human approval steps, confer application-level authorization, make callback tokens safe to expose, or provide a native integration to every enterprise application. Those outcomes depend on agent design, workflow logic, IAM, input validation, and testing. The AWS launch note confirms the connector; the technical documentation explains its boundaries.

Bottom line

The useful shift is not 'AI can now run any business process.' It is more specific: AI can invoke a deterministic workflow through a supported, managed MCP connector, while the workflow retains control of the prescribed steps. That separation is promising for enterprise agents because it gives architects a place to enforce repeatable controls. The first production decision should therefore be about authorization, workflow ownership, and exception handling, not the sophistication of the chatbot. Start with one synthetic workflow and prove that the agent cannot step outside its allowed actions. Official launch announcement.

Primary sources and implementation references

AWS What's New, 29 October 2026; Amazon Bedrock AgentCore: Step Functions connector operations and IAM limitations; AgentCore Gateway target configuration; AWS Step Functions tutorial for agent tools.