Your AI Agent Has an IAM Role. That's Not a Feature It's an Uncontrolled Blast Radius.

Why traditional identity models fail non-deterministic systems, and what enforcement actually looks like at the platform layer

At 2:14 AM on a Friday, an agentic remediation system I was responsible for made fourteen sequential API calls to AWS in eleven seconds.

The agent had detected an anomalous CloudWatch alarm. It retrieved a relevant runbook. It synthesized a remediation plan. Then it executed that plan — and each execution step produced a new signal the agent interpreted as requiring another action. Fourteen calls. Eleven seconds. No circuit breaker.

The IAM role didn't care. Every call was authenticated. Every call was authorized. The cloud provider executes what it receives. It has no concept of whether the call was generated by deterministic application code or a language model in a hallucinated reasoning loop.

We got lucky that night. The blast radius was contained to a single ECS cluster not serving production traffic. But the architectural failure was real, and it had nothing to do with the quality of the agent's reasoning.

The Category Error We're Building On

There's a widely-shared mental model in teams deploying infrastructure agents right now: if the model reasons well, the system is safe. Improve the prompt. Add a system message. Constrain the reasoning with better instructions.

This is the wrong level of enforcement.

Traditional IAM was designed for deterministic code. When you write an application that calls ec2:TerminateInstances, you know exactly when that call will be made, with what parameters, under what conditions. The call path is static. The IAM policy is a guard on a known, bounded behavior.

A language model doesn't have a call path. It has a reasoning trace that produces a call path at runtime one that changes based on the prompt, the context window, the retrieved documents, the tool call history, and whatever the model decides is the next logical step. The IAM role the agent holds doesn't know any of that. It knows the API call that arrived. It executes.

This means that when a prompt injection payload appears in a retrieved document a log file, a ticket description, a runbook that's been tampered with the execution authority the agent holds becomes the blast radius of that injection. The same IAM role that handles legitimate remediation handles the injected command. The cloud doesn't distinguish.

Prompt engineering is not a security control at this layer. It is a probabilistic influence on model behavior. Probabilistic is not deterministic. Infrastructure security requires deterministic enforcement.

The Three Failure Modes in Practice

Reasoning loops that become API storms

A model gets into a state where each tool call result is interpreted as evidence that another tool call is needed. Without a runtime circuit breaker, this generates hundreds of API calls before a human notices rate limit exhaustion on critical APIs, unbudgeted cost spikes, and potentially self-inflicted service degradation on the infrastructure the agent was supposed to protect.

Prompt injection through context retrieval

An agent retrieving context from a knowledge base, ticket system, or log aggregator is reading content that may have been authored by an adversary. A log line containing an instruction to scale all ASGs to maximum capacity is not a theoretical threat. Agents that pass retrieved content directly into their reasoning context without sanitization are vulnerable. The IAM role has no "was this call generated by an injection payload?" check.

Authority conflation

The agent finds a valid path to resolve an alert and executes it. The path has side effects — deleting a deployment that was intentional, terminating an instance running a scheduled batch job, modifying a security group that breaks a dependency. The agent had authority. The action was within scope. Nobody had established that "synthesizing a remediation plan" and "executing against live infrastructure" are two separate authority levels that should be enforced separately.

What Deterministic Enforcement Actually Looks Like

The principle: an AI agent should be allowed to reason, synthesize, and recommend. The decision to execute passes through a deterministic policy engine with no LLM in the critical path.

This isn't new. It's how safety-critical systems have always been designed. The novel problem is that most teams deploying infrastructure agents haven't made this separation explicit in their architecture.

Separation of Intent and Action

The agent produces a proposed action: a structured object describing what it wants to do, to what resource, with what parameters. That object passes to a policy engine — a deterministic validator with no LLM involvement — that checks: Is this resource tagged production? Is this action class permitted at the current error budget level? Has this resource been modified in the last N minutes?

Approved: execution proceeds. Rejected: the agent receives a structured refusal, the attempt is logged, and the agent has no path to self-authorize beyond what the policy engine allows.

Runtime anomaly detection with automatic authority severance

Tool-calling behavior is tracked at runtime: calls per minute, cost per session, resource types touched, action class frequency. When a metric crosses a threshold — more than twenty API calls in sixty seconds, more than ten distinct resource modifications in a session, cost exceeding a per-session budget the circuit breaker severs tool calling authority for the session and pages the on-call engineer.

The agent doesn't get a warning. Its tool access is revoked at the infrastructure layer. It can continue reasoning and producing recommendations. It cannot execute.

Isolated runtime containment

Any agent executing commands against infrastructure should run in a short-lived sandbox with scoped credentials, network egress restrictions, and a maximum session lifetime. When the session ends, the credentials expire. The blast radius of any single session is structurally bounded by the sandbox's resource scope not by the agent's self-restraint.

The Architecture Change That Mattered

After the fourteen-call incident, we made three changes. None of them touched the model.

A runtime session monitor tracked API calls per sixty-second window per agent session. Above fifteen calls, the session's IAM role was suspended via a resource-based policy update and an alert fired. The agent could still reason. It could not execute.

A pre-execution policy gate sat between the agent's proposed action and any live API call. The gate checked resource tags, action class, and a cooldown registry preventing the same resource from being modified more than once per ten minutes. Every gate decision approved or rejected went to CloudWatch with full context.

Agent execution moved into short-lived ECS tasks with session scoped IAM roles assumed at task start and automatically expired at task end. No persistent credentials. No carry-over between sessions.

The agent's reasoning didn't change. The architecture around it changed. That distinction is the entire point: the safety guarantees needed for autonomous infrastructure agents cannot be delegated to the model. They have to be built into the system.

The Question for Platform Teams

If you're deploying autonomous agents that touch live infrastructure, the design review question isn't "does the model reason well enough to be safe?"

The question is: if the model reasons incorrectly — bad prompt, stale context, prompt injection payload, hallucinated tool-calling loop — does your platform architecture bound the blast radius, or does the agent's IAM role determine it?

If the answer is "the IAM role determines it," you have an uncontrolled blast radius.

The controls exist. The architecture patterns are established. The question is whether we build them before the incident, or after.

How is your team decoupling the agent's reasoning layer from your cloud infrastructure permission boundaries? The more specific the implementation detail, the more useful for everyone building in this space.