What breaks when an AI agent can replan and keep acting inside one session?

Why one session is the dangerous unit of control

An AI agent that can replan mid-session is not just “a user with automation,” it is an execution loop that can revise its own path after each tool call. That means the meaningful security boundary is the session, the approval point, and the policy check that sits in front of each step. Once a request is allowed to keep going, the agent can combine partial access in ways a human reviewer would only see after the fact.

In practice, that changes the question from “Did we grant the right permission?” to “Did we constrain what this actor can do before the next action?” This is why per-session trust is fragile: the agent can use one successful action to justify the next, accumulate context, and reach a state that was never approved as a whole.

For practitioners, the main implication is that session continuity itself becomes an attack surface. The risk is not only excess privilege, but also the ability to chain otherwise ordinary permissions into an unreviewed sequence of actions that crosses systems, data sets, or environments.

What breaks in human-paced IAM assumptions

Human-paced IAM assumes a person requests access, uses it slowly, and can be reviewed, interrupted, or revoked before the next material step. A replanning agent breaks that assumption because the loop can compress discovery, authorization consumption, and follow-on action into a single runtime cycle. The control gap is timing: by the time a reviewer notices, the agent may already have completed several dependent actions.

This also weakens controls that depend on “safe enough until review.” Standing approvals, broad tokens, and long session windows become much more dangerous when the actor can autonomously decide how to spend them. The agent does not need a new login for every step, which means the old governance cadence can lag behind actual behavior.

That is why a control model built around periodic human checks is a poor fit for autonomous execution. The issue is not only privilege scope, but how long the system lets the actor remain in a state where it can keep deriving new capability from the same session.

What security model replaces review-first governance

The safer model is issuance-first, step-bound, and revocable in real time. An agent should receive only the minimum access needed for the next action, with explicit constraints on duration, audience, and tool scope. AI Agent Authorisation Guide is useful here because it frames per-action policy, delegated authority, and just-in-time access as the right control shape for autonomous actors.

Where the agent can act through APIs or delegated tokens, the stronger pattern is to make every sensitive step separately enforceable and separately observable. That is why sender-constrained or exchange-based token designs matter, and why session design should assume compromise or misuse rather than long-lived trust. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) and RFC 8693: OAuth 2.0 Token Exchange both help explain how to reduce replay and shape delegation more tightly.

For autonomous sessions, good design means the control plane can answer three questions continuously: what is this actor allowed to do right now, for how long, and under what evidence of intent or approval. If those answers cannot be changed mid-session, the agent can outpace governance.

Risk and Threat Considerations

When an agent can replan inside one session, the main risk is compound action abuse: each permitted step can expand the next step’s options, so the attack surface grows during execution rather than before it. That creates exposure to overreach, unintended cross-system movement, and destructive action before detection or revocation can catch up.

Failure mechanism: A long-lived or broadly scoped session lets the agent chain tools, tokens, and context fast enough that policy checks happen after the harm is already in motion. A compromised prompt, bad objective, or mis-specified tool grant can then turn one approved workflow into a multi-step unauthorized sequence.

Impact: The result can be data access beyond the original intent, irreversible side effects, and audit trails that show individually permitted actions but miss the larger unauthorized outcome. In high-trust environments, this can look like normal automation until the blast radius is already expanded.

Practitioner Guidance

What to verify: Verify that every sensitive tool call is authorized at the action level, not just at session start. If the session token alone can carry the agent through multiple high-impact steps, the control is too coarse for autonomous execution.

Decision rule: If the agent can change plans mid-session, treat the session as ephemeral and revocable, not as a reusable trust container. Keep the approval boundary as close as possible to the action that creates material impact.

Common mistake: Do not rely on a single login, a broad bearer token, or a post-hoc review queue to govern an actor that can iterate faster than a human reviewer. The governance model must move at runtime speed, or it will only describe the compromise after it has already happened.

Practitioner takeaway: The critical shift is from “who was allowed in” to “what can this actor still do on the next step.” For replanning agents, timing and revocation are part of authorization.

Related resources from NHI Mgmt Group

• What breaks when an AI agent can acquire and use credentials inside one runtime session?
• What breaks when an AI agent can read and write identity infrastructure in one session?
• What is the difference between human identity governance and AI agent governance?
• When does AI agent access create more risk than it reduces?