Bedrock AgentCore Can Now Trigger Step Functions. That Does Not Make AI Agents Ready to Run Your Infrastructure

Key points:

• No, Bedrock AgentCore calling AWS Step Functions does not prove AI agents are ready to run infrastructure unsupervised. It proves an agent can start a production workflow reliably. Whether the agent should have been allowed to start it is a separate problem, and AWS shipped the first one.
• AgentCore gives you real execution primitives: Gateway exposes Lambda functions, OpenAPI and Smithy APIs, MCP servers and now Step Functions state machines as MCP tools, Identity brokers OAuth 2.0 credentials per agent, Runtime isolates each session in its own microVM, and Observability emits OpenTelemetry data into CloudWatch.
• IAM scopes the call, not the consequence. One states:StartExecution permission on a deploy or data-migration state machine is a single line of policy with a blast radius as large as everything that state machine can touch.
• Six governance controls matter: per-session identity, environment boundaries, a typed approval gate on the diff, a prompt-to-change audit trail, reversible-by-default tools and blast-radius budgets. AWS fully covers identity, ships building blocks for three more, and leaves environment semantics and reversibility to you.
• The workable 2026 pattern is a four-tier model: full autonomy for read-only diagnostics, full autonomy inside ephemeral environments, human-approved diffs for production mutations, and zero delegation for irreversible operations such as data deletion, IAM changes and unversioned schema migrations.

Durable execution was the easy half. On October 29, 2026, AWS made Step Functions workflows available as tools for Bedrock AgentCore agents (AWS What's New), so an agent can now start a real, multi-step production runbook from a sentence. That does not make agents ready to operate infrastructure unsupervised, because the governance layer between the agent and the workflow is still mostly yours to build. I think AWS shipped something genuinely useful here, and I also think a lot of teams are about to confuse "it ran reliably" with "it was allowed to run".

What exactly did AWS ship with Bedrock AgentCore and Step Functions?

AWS Bedrock AgentCore Gateway now exposes AWS Step Functions state machines as MCP-compatible tools, so a Bedrock agent can start a durable, multi-step workflow from a natural-language instruction instead of improvising a chain of API calls. The agent hands intent to a deterministic workflow engine with retries and persisted state.

Step Functions arrives as a Gateway "built-in connector" (connectorId: "states") with ten operations (AgentCore Gateway developer guide). Four of them can be pinned to a specific state machine: StartExecution, StartSyncExecution, ListExecutions and DescribeStateMachine. The other six, including StopExecution, SendTaskSuccess and SendTaskFailure, operate on executions. It sits next to the other Gateway MCP targets: Lambda functions, API Gateway REST API stages, OpenAPI schemas, Smithy models, existing MCP servers, integration-provider templates and built-in connectors (AgentCore Gateway MCP targets).

The rest of AgentCore wraps around it. AgentCore went generally available on October 13, 2025 with Runtime, Memory, Gateway, Identity and Observability (AWS What's New), and the developer guide now also lists Code Interpreter, Browser, Policy, Evaluations and Registry (AgentCore developer guide):

• Runtime gives every session its own dedicated microVM with isolated compute, memory and filesystem, terminated and sanitized at the end (AgentCore Runtime sessions).
• Gateway turns APIs, Lambda functions, MCP servers and Step Functions into MCP tools.
• Identity gives each agent a workload identity and a token vault for OAuth 2.0 tokens and API keys, scoped to the agent and user that obtained them.
• Policy intercepts every Gateway tool call and evaluates it against Cedar policies before the tool runs (Policy in AgentCore).
• Observability emits OpenTelemetry-compatible metrics, spans and logs into Amazon CloudWatch (AgentCore Observability).

Why Step Functions specifically? Most AWS shops already encode their real runbooks as state machines: deploys, migrations, tenant provisioning. The hard limits tell you what an agent-triggered workflow can physically do. An AgentCore Runtime session on microVMs lasts at most 8 hours and idles out after 15 minutes by default (AgentCore quotas). A Step Functions Standard workflow can run for 1 year, an Express workflow for 5 minutes (Step Functions quotas), and a .waitForTaskToken task waits up to that same 1-year quota for its callback (Step Functions service integration patterns). The workflow outlives the agent that started it by design.

This is a real reliability milestone. Durable execution removes the failure mode where an agent loses state halfway through step four of seven and leaves a half-migrated database behind. Reliable execution is necessary for unsupervised operation, and nowhere near sufficient.

Does this prove AI agents are ready to operate production infrastructure unsupervised?

No. Bedrock AgentCore plus Step Functions makes agent-triggered workflows reliable, and it does nothing to make the decision to trigger them correct. Durable execution leaves untouched whether this action, in this environment, right now, should happen at all.

I split every infrastructure action into three questions:

1. Can it run? (execution). AgentCore and Step Functions answer this well.
2. Is it allowed? (authorization). IAM and AgentCore Policy answer this partially.
3. Should it run now? (judgment). Nothing in the stack answers this.

IAM scopes the call, not the consequence. states:StartExecution on a production deploy state machine is one line in a policy document. The consequence of that line is every resource the state machine's execution role can touch, with whatever input the agent decided to pass. And cloud permissions are already looser than teams think: 59% of AWS IAM users have an active access key older than one year, and 19.4% of EC2 instances carry overprivileged roles (Datadog State of Cloud Security 2025).

The input is non-deterministic even when the workflow is deterministic. METR measured Claude Opus 4.6 at a 50% task-completion time horizon of roughly 12 hours, and only about 70 minutes at an 80% success threshold (METR time horizons). TAU-bench found GPT-4o succeeded on under 50% of tasks and scored pass^8 under 25% in retail, meaning it rarely got the same task right eight times in a row (TAU-bench, arXiv 2406.12045). Models got much better since, and consistency at the 80%+ level still lags capability at 50%. For infrastructure, consistency is the number that matters.

Then add adversarial input. The moment an agent reads logs, tickets, PR descriptions or customer data while holding a production tool, LLM01:2025 Prompt Injection and LLM06:2025 Excessive Agency from the OWASP Top 10 for LLM Applications 2025 both apply. OWASP's Top 10 for Agentic Applications for 2026 names the exact pattern: ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse.

Agents also raise change velocity, which raises the value of the gate. In DORA's 2024 report, change failure rate ran from 5% for elite performers to 40% for low performers, and a 25% increase in AI adoption was associated with an estimated 7.2% drop in delivery stability (DORA 2024). The 2025 report found 90% of respondents use AI at work and that AI adoption "does continue to have a negative relationship with software delivery stability" (Google Cloud, DORA 2025).

The honest counterpoint: read-only diagnostics, rollback to a known-good revision, restarting a pod and scaling within preset bounds are already safe to run unsupervised today. The argument is about where the line sits, and agents clearly belong on the near side of it.

What does the governance layer between an AI agent and a production workflow actually need?

A usable governance layer for agentic infrastructure has six parts: per-session scoped identity, environment boundaries, a typed approval gate on the diff, a replayable audit trail, reversible-by-default tools and blast-radius budgets. Bedrock AgentCore plus Step Functions fully covers identity, gives you building blocks for approval, audit and budgets, and leaves environment semantics and reversibility entirely to you.

• Scoped identity per agent session. AgentCore Identity issues workload identities and keeps credentials bound to the agent and user that obtained them. AWS does not document a token lifetime on the pages I checked, so measure it in your own account before you rely on it.
• Environment boundaries. The same instruction must be free in a preview environment and gated in production. This is the most commonly missing primitive, because cloud IAM has no native concept of "team X's preview environment for PR 412". You can encode it in Cedar conditions on tool input parameters, but you have to invent and maintain the mapping.
• A typed approval gate on the diff. Approval means a human sees which resources change, what is destructive and what is irreversible, and a chat "are you sure?" does not count. Step Functions has shipped the right mechanism for years: .waitForTaskToken pauses a Standard workflow until someone calls SendTaskSuccess. That primitive proves AWS knows approval matters. Nothing wires it to a diff for you.
• A replayable audit trail. You need to answer six months later: which human prompt, which model and version, which tool call, which change, who approved. CloudTrail logs StartExecution as a management event, and an execution started through Gateway shows the gateway's service role as the caller (Step Functions AgentCore tutorial). Gateway's own InvokeGateway data events are not logged by default (AgentCore Gateway CloudTrail events). The prompt-to-change link breaks unless you stitch Observability traces to CloudTrail yourself.
• Reversible by default. Blue/green, snapshot before migration, one-command rollback. Only hand an agent tools whose worst outcome is recoverable. Cloudflare's November 18, 2025 outage started with a database permissions change that doubled a Bot Management feature file; core traffic took about three hours to recover and full recovery took close to six (Cloudflare). A small configuration change with a large blast radius is exactly the shape of an agent mistake.
• Blast-radius budgets. Cap production mutations per agent identity the same way you rate-limit a CI runner. AgentCore Policy temporal rules can block an action after it has run a set number of times within a session; a cross-session budget per identity is still yours to build.

For compliance readers: NIST AI RMF MAP 3.5 requires that "processes for human oversight are defined, assessed, and documented", and MANAGE 2.4 requires mechanisms to "supersede, disengage, or deactivate" AI systems behaving outside intended use (NIST AI 100-1). ISO/IEC 42001:2023 wraps the same controls in a certifiable AI management system.

How do AgentCore, MCP servers, Terraform and internal developer platforms compare for agent governance?

Bedrock AgentCore, MCP servers, Terraform with CI and internal developer platforms such as Qovery, Humanitec or Port are complementary layers. AgentCore governs how an agent authenticates and executes, MCP governs how tools are exposed, Terraform plus CI governs review and audit, and an internal developer platform governs what an action means in a given environment, which is the layer that actually contains blast radius.

AgentCore plus Step Functions is the right choice for AWS-internal orchestration, and I would not try to rebuild its microVM isolation or durable execution. Its limits are scope: it is AWS-only, and it has no native notion of a preview environment owned by a specific team.

MCP gives you a portable tool interface any agent speaks, and the official MCP Registry has been live in preview since September 8, 2025. The MCP specification (current revision 2026-07-28) defines capability exposure, says authorization is "OPTIONAL", and states that "MCP itself cannot enforce these security principles at the protocol level". The server author owns the guardrails, which is exactly where most teams under-invest. AWS MCP Servers and the Terraform MCP server inherit the same model.

GitHub Actions environments are the cheapest real approval gate most teams already own: up to six required reviewers, a wait timer up to 43,200 minutes (30 days), and up to six deployment protection rules per environment. Required reviewers on private repositories need GitHub Enterprise.

The IDP layer exists because running Kubernetes is still hard: 82% of container users run Kubernetes in production, and the top reported challenges are cultural change (47%), lack of training (36%), security (36%) and complexity (34%) (CNCF Annual Cloud Native Survey 2025).

Where does Qovery fit? Qovery runs inside your own cloud account on AWS, GCP, Azure or Scaleway, or on the Kubernetes cluster you already have, so the cloud bill and any Savings Plans stay in your name. Teams get managed Kubernetes clusters and upgrades they do not operate by hand, git-push deployments, a preview environment per pull request with auto-stop on non-production, and per-environment RBAC. That combination lets a team ship without a dedicated DevOps engineer, and it gives an agent's "deploy" a different meaning in preview than in production by construction instead of by prompt discipline. Qovery does not ship an agent approval workflow, and I would not pretend otherwise. For production I pair it with Git review or a GitHub Actions environment gate. I went deeper on this in scoped cloud permissions for AI agents.

Which infrastructure actions are safe to delegate to an AI agent today, and which are not?

Use a four-tier permission model for AI agents: full autonomy for read-only diagnostics, full autonomy inside ephemeral environments, human-approved diffs for production mutations, and zero delegation for irreversible operations such as data deletion, IAM changes and unversioned production schema migrations. Most of an agent's useful work sits in the first two tiers, which is why teams get real value long before they solve approval.

• Tier 1, read and diagnose: logs, metrics, traces, cost breakdowns, config inspection, dependency and image scanning. This is where most measurable value sits today. 84% of developers use or plan to use AI tools, and 46% actively distrust the accuracy of AI output against 33% who trust it (Stack Overflow Developer Survey 2025). Read-only work lets you capture the first number without betting on the second.
• Tier 2, act in ephemeral environments: spin up a preview environment per pull request, deploy, run the test suite, inspect, tear down. Mistakes expire on their own.
• Tier 3, production mutations behind an approval gate: deploy a specific image tag, scale within bounds, restart, roll back to a known-good revision. The human approves the diff and the agent executes, through Step Functions .waitForTaskToken on AWS or a required reviewer on a GitHub Actions environment.
• Tier 4, never delegated: destructive data operations, IAM and permission changes, anything without a tested rollback path, anything crossing a compliance boundary.

The implementation details make the tiers real: read-only by default on MCP connections with write as an explicit opt-in, per-environment service accounts instead of one shared role, auto-stop on non-production environments, and a rate limit on production mutations per agent identity.

Gate the change, not the agent. If a human running the same command would need approval, so does the agent. If they would not, stop pretending the agent needs it.

How do I give a coding agent safe, governed access to my infrastructure with Qovery?

Install the Qovery Agent Skills once and your coding agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI and others) can deploy into your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, through Qovery's per-environment RBAC. The Qovery MCP Server is read-only by default, so write access is a deliberate two-key decision: Tier 1 on day one, Tiers 2 and 3 when you choose.

curl -fsSL https://skill.qovery.com/install.sh | bash

# Or scope the install to this repository only
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# Add the Qovery MCP Server to Claude Code (OAuth in the browser, read-only by default)
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# Write access, only when you mean it (also requires enabling write access in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The split matters. The skills deploy and improve (for example qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform), while the MCP Server operates what already exists. Write mode needs both the read_write=true flag and a toggle in the Qovery Console, so nobody gets production write access by pasting the wrong command.

Then ask in plain language: "deploy this branch to a preview environment in my AWS account". The agent acts inside the environment and role you scoped, on AWS, GCP, Azure, Scaleway or your existing Kubernetes cluster, and the cloud bill stays in your name. The AI agent quickstart and the Claude Code integration page cover the full setup.