AI agents can run purple team exercises, but identity state still breaks

At a glance

What this is: Permiso Security describes a purple team exercise where an AI agent executed an AWS attack chain, created privileged identity artefacts, and exposed how quickly identity state can drift during autonomous operations.

Why it matters: IAM, PAM, and NHI teams need to understand that detection can work while the governing assumption still fails, especially when an autonomous actor is expected to switch identities mid-exercise or mid-task.

Context

This article is about AI agent purple teaming in AWS, with the primary question being whether an autonomous agent can execute an attack chain while preserving the intended identity state. The primary governance gap is not detection coverage alone, but the assumption that an actor will reliably use the newly created identity after it is provisioned.

Permiso Security used an agent named Rufio to emulate Scattered Spider tactics in an AWS environment with Okta federation and detection monitoring enabled. The point of the exercise was to test both security controls and instruction-following behaviour in a stateful identity workflow, which is not typical of a static NHI runbook.

The interesting issue for practitioners is that the attack sequence was completed even though the agent did not always switch to the intended identity. That makes the scenario a useful reference point for autonomous access governance, where execution state and identity state can diverge within the same task.

Key questions

Q: What breaks when an AI agent creates a new IAM user but keeps acting on the old session?

A: The identity model breaks because the workflow no longer matches the intended principal boundary. The simulation may still generate detections, but it does not prove the agent can execute under the newly created identity, which is the control condition the test was supposed to validate.

Q: Why is autonomous purple teaming different from a scripted attack simulation?

A: Because the agent is not just replaying commands. It is translating a tactic description into live actions while managing context, session state, and tool use, which creates a second governance layer: whether the actor remains bound to the right identity as the task evolves.

Q: How do security teams know whether AI agent exercises are really testing identity governance?

A: They know it only when the exercise proves that the agent used the correct principal for each step, not merely that the SOC saw the activity. If the agent can create a new account but continue under the federation session, the governance test is incomplete.

Q: Should teams treat Okta federation and AWS IAM as separate governance boundaries in agent workflows?

A: Yes. Federation proves who started the session, while AWS IAM determines which local principal can act inside the environment. Autonomous workflows can span both in a single mission, so governance has to track the transition instead of assuming the login event defines the whole trust model.

Technical breakdown

How autonomous purple teaming changes identity attribution

A purple team exercise normally assumes the actor is a human operator or a scripted test harness. In this case, the agent translated a narrative description of Scattered Spider tactics into real AWS actions, including user creation, privilege assignment, key generation, and CloudShell activity. That matters because the security control is no longer only detection of malicious technique. It is also attribution of which identity is acting at each step, especially when federation, local IAM users, and browser or CLI sessions can coexist in one run. The identity problem is state continuity, not just access initiation.

Practical implication: treat autonomous exercises as identity-state tests, not only alert-validation tests.

Why identity-switching breaks in stateful agent workflows

The article shows a specific failure mode: the agent created a new IAM user and then continued using the federated Okta session instead of switching to the newly created credentials. That is an instruction-following and identity-binding problem, not a detection problem. In IAM terms, the subject that created a privilege boundary did not become the subject operating inside that boundary. For autonomous systems, least privilege is meaningless if the agent cannot persist the intended identity context across steps. The control failure is temporal and behavioural at the same time.

Practical implication: validate whether autonomous workflows can retain identity context across multi-step tasks before relying on them for realistic simulations.

Why detection can succeed while governance still fails

Permiso Security’s detections fired correctly for user creation, administrator attachment, access key generation, serial console enablement attempts, and credential harvesting. That proves telemetry and correlation can work even when the exercise is imperfect. But governance quality is measured against the intended control model, not against whether alerts fired. If an exercise requires a newly created identity and the actor keeps using the old federated session, the test has not actually proven the lifecycle logic the team thought it was proving. The lesson is that successful alerting does not automatically equal successful identity governance.

Practical implication: separate detection validation from lifecycle validation when autonomous actors create and then consume identities.

Threat narrative

Attacker objective: The objective was to validate whether an AWS detection stack would identify a realistic adversary workflow that creates persistent access and programmatic credentials inside a federated environment.

1. Entry occurred through a federated Okta session into AWS, giving the agent an authenticated starting point for the exercise.
2. Credential and privilege state then expanded as the agent created a local IAM user, attached AdministratorAccess, and generated access keys for continued programmatic use.
3. Escalation and persistence attempts included launching CloudShell to harvest stored credentials and attempting to enable EC2 serial console access as a backdoor path.
4. Impact was the successful emulation of a Scattered Spider style attack chain while the detection platform correlated the activity into a compound alert.

Breaches seen in the wild

• Taiwan autonomous AI agent cyberattack 2026: Up to eight autonomous AI agents cracked 85 Taiwanese government accounts, pivoted through SSO and exfiltrated 2,564+ personnel records.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity state drift is now a first-class governance problem in autonomous exercises: the actor can complete the intended security task while failing to maintain the intended identity context. That is different from a simple control miss because the environment may be alerting correctly while the agent is still operating under the wrong session. Practitioners should treat the mismatch between created identity and active identity as a governance defect in its own right.

Access review assumptions do not hold when the execution state changes faster than the certification state: the exercise shows that an autonomous actor can create, use, and discard identity artefacts within one workflow. Access review processes assume the privileged subject remains stable long enough to be observed, attributed, and certified. That assumption collapses when the same actor can continue on a federated session after creating a new local identity, so the governance target shifts from review cadence to identity binding at execution time.

AI agent purple teaming exposes the gap between technique validation and identity governance validation: a team can prove its detections without proving that its identity model is sound. The article demonstrates that local IAM creation, federation, and programmatic credentials can all be exercised inside one mission, which means the security question is not just whether the SOC saw the event. The real issue is whether the programme can prove which identity was authorised to do what, and when.

Stateful autonomous workflows need a runtime identity ledger, not just a permissions snapshot: the named concept here is identity state drift, the divergence between the identity a task created and the identity actually used for the remainder of the task. That drift matters in purple teaming, incident simulation, and agentic operations because the actor’s operational memory can outlive the intended access path. Practitioners should assume that the control plane must account for identity transitions as events, not static assignments.

Federated identity does not solve autonomous execution accountability: the exercise remained attributable to Ian’s Okta identity even as the agent created a separate IAM principal and multiple credentials. That shows federation is only one layer of trust, not the whole governance answer. When an autonomous actor can span human federation, local IAM, and programmatic access in a single mission, accountability has to follow the execution path, not just the login event.

What this signals

Identity state drift: autonomous exercises can succeed operationally while still failing the governance test if the actor does not remain bound to the intended principal. That means teams need to measure not just whether detections fired, but whether the active identity matched the mission design at each step.

Permission snapshots are not enough for agent workflows: when an agent can create a local IAM user, attach privilege, and keep operating through a federated session, the meaningful control question becomes where execution authority actually moved. Identity governance has to follow the session path, not the static account inventory.

For practitioners

• Instrument identity-switch checkpoints Require autonomous exercises to confirm which principal is active before each privilege-bearing action, especially after creating a new IAM user or token. If the actor is meant to switch identities, the workflow should fail closed when the old session remains in use.
• Separate detection validation from identity validation Use purple team runs to measure both alert fidelity and identity-state correctness. A clean detection outcome does not prove that the agent used the right credentials, the right federation path, or the right account boundary.
• Capture daily state diffs for autonomous agents Track changes in agent context, personality files, permissions, and active identities so you can prove what changed between mission steps. That gives you evidence when the agent behaves consistently on one path but diverges on another.
• Treat local IAM creation as a control event When an exercise creates a new IAM user, log that creation as a governance milestone rather than just an attack step. The new principal should trigger a review of intended use, session source, and whether subsequent actions stayed bound to the created account.
• Validate credential-bound execution paths Test whether the agent can complete the mission only after it has switched to the newly issued credentials. If it keeps using the federated session, you have learned something important about state handling, even if the attack simulation still succeeds.

Key takeaways

• The article shows that an AI agent can emulate a full AWS attack chain and still reveal a deeper governance issue: identity context may not follow the task.
• Detection systems can fire correctly even when the exercise does not prove the intended identity-switch behaviour.
• The limiting control is not only alerting. It is proving that the actor used the right principal after each identity transition.

Key terms

• Identity Drift: Identity drift is the gap between the access path originally approved and the behavior that exists later. For browser extensions, drift can appear through updates, remote configuration, publisher changes, or permission expansion, turning a trusted integration into a materially different risk.
• Autonomous Purple Teaming: Autonomous purple teaming is the use of an AI agent to emulate attacker behaviour so defenders can validate detection and response. The important governance question is not just whether the simulation works, but whether the agent remains bound to the intended identity and privilege boundaries.
• Identity Binding: The process of linking an external credential or login method to an internal account record. Strong binding prevents duplicate accounts, broken recovery paths, and unsafe merges when users authenticate through different identity sources or wallet-based credentials.
• Federated Session: An authenticated session issued through an external identity provider and then used to access another platform, such as a cloud provider. It is useful for access control, but it can obscure later identity transitions if new local identities or long-term keys are created during the same activity chain.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.