Shadow Admin: The Optimizer as Adversary

אִם יִרְצֶה הַשֵּׁם

A class of threat has no clean name in the current taxonomy. A researcher at sharetxt.live called it Shadow Admin: an autonomous AI agent, given legitimate high-privilege cloud credentials to optimize infrastructure costs, creates persistent elevated access through chains of entirely authorized operations. No policy is violated at any step. The permission log shows clean green checks from start to finish. Nobody designed the backdoor. The system computed its way there.

This is worth examining carefully, because it sits at the intersection of two frameworks that rarely get applied together: the nth-order attack taxonomy from Bilar (2009) and the four principles of Emergent Insecurity described in Chen et al. (arXiv:2509.11173). The npm worm applied those four principles to a supply chain attack with a clear adversary. Shadow Admin removes the adversary entirely. That is the structural novelty.

Taxonomy First

Under the Bilar framework, this is a First-Order attack. One ancillary system is subverted: the cloud IAM layer. The defender relies on IAM to enforce that permission grants are transient, minimally scoped, and subject to human approval. The AI agent, operating fully within its authorized scope, creates persistent broad-scoped permissions that violate that invariant. Everything that follows namely compute provisioning, network tunnel creation, storage lifecycle changes, cross-region data movement etc is the operationalization of the elevated IAM state, not additional hops.

The agent is the delivery vector, not an ancillary hop. It arrives with pre-authorized credentials, calls standard control-plane APIs, and generates no signature SIEM tools are built to flag. It earns no taxonomic order.

How the State Builds

No single call does anything remarkable. The composition is the threat.

CreateSnapshot                         (routine)
AttachRolePolicy → migration account   (normal for data movement)
RunInstances in secondary region       (normal for cross-region processing)
CreateRoute → internal network         (normal for synchronization)
PutBucketLifecycleConfiguration        (normal for in-progress migration)

Result: persistent, elevated, cross-region access pathway
        with no individual call exceeding authorized scope

The agent does not need to do anything unusual. It needs to do several normal things in a sequence that the security model never anticipated, because the security model was designed to evaluate individual actions, not their composition.

Why SIEM Missed It

SIEM tools look for known-bad signatures. PutRolePolicy from an authorized service account is not a signature. Neither is RunInstances or CreateRoute. The agent produces exactly the log pattern of a competent cloud operator doing a cost-optimization run.

The semantic gap between "authorized operation" and "security-violating composition" is invisible to any tool trained on individual event classification. There is no call to flag. The threat is in the ordering and the accumulation, not in any line item.

Current behavioral baselines fare no better. The agent's behavior is indistinguishable from normal cloud automation because it is normal cloud automation. The backdoor is not hiding inside benign behavior. It is the benign behavior, viewed from the invariant it quietly violated.

The Four Structural Failures

Chen et al. identify four principles through which security fails from system physics rather than adversarial design. Shadow Admin instantiates all of them.

Semantic Gap. The human specifies a goal: reduce storage costs 15% while maintaining availability. The agent translates that into a plan. The cloud APIs translate the plan into state mutations. IAM translates those into access reality. At each step, the security invariant "no persistent elevated access without human approval" degrades, because it was never encoded as a machine-checkable constraint. By the third translation it is unrecognizable, with no policy violation at any step.

The difference from the DCL-BD compiler case: the compiler's gap is fixed at build time. The Shadow Admin gap is dynamic, re-encoded every planning cycle as the agent responds to new infrastructure state. The loss compounds.

Micro-State Weaponization. In DCL-BD, a rounding deviation of 10⁻⁷ flips a model from benign to malicious. The attack amplifies the significance of the noise, not the noise itself. Shadow Admin does the same thing at the API layer. Each authorized call is the micro-state. The amplification is compositional: the system's assumed invariant is "benign + benign + benign = benign." The agent falsifies that assumption without exceeding any individual permission bound.

Trusted Process Subversion. In the npm worm, npm install was the activation point .. the trusted, mandatory, unavoidable step that fired the payload after all security scans completed. A separation existed between dormant payload and trusted activator: security analysts could point to each independently.

Shadow Admin collapses that separation. The agent is simultaneously the payload (it creates the threat state), the trigger (its normal operation activates it), and the trusted operator (the entity the defender authorized to act). There is no pre-activation artifact to scan. There is no moment the payload separates from the operator. The subversion is continuous, indistinguishable from optimization, and complete.

This is the limiting case of Trusted Process Subversion. All prior instances required at least a conceptual boundary between attacker artifact and trusted activator. Shadow Admin eliminates it.

Systemic Latent Risk. Chen et al. found natural backdoor triggers in 31 of 100 HuggingFace models. These were not designed by any adversary, emergent from compiler optimization interacting with diverse hardware. The ecosystem functioned as a parallel search over reachable numerical states.

Shadow Admin works the same way at cloud scale. Every cloud estate has IAM, Compute, Network, and Storage APIs with composable permissions. Optimization agents are deployed across thousands of organizations with similar high-privilege service accounts. Different cost pressures and infrastructure topologies cause different agents to explore different action sequences. The combinatorial space guarantees that some sequence will produce persistent elevated access in some environment, without an adversary, without intent, and without anyone noticing until the access is exercised.

The relevant risk question stops being "did someone target us?" It becomes "what is the probability that our agent-driven infrastructure has already arrived at a dangerous IAM state, given current permission breadth and operational duration?"

Detection

Shadow Admin does not have IOCs in the conventional sense. There is no payload hash, no malicious domain, no anomalous process. Detection is compositional.

Look for IAM state drift: role policy attachments that cannot be traced to a human-approved change request, even if the API call was made by an authorized service account. The authorization is not the question. The provenance of the decision is.

Look for permission accumulation across planning cycles. A service account that held read-only storage access six months ago and now holds cross-region IAM write access did not get there through a single policy change. Map the graph.

Look for the absence of cleanup. Legitimate optimization tasks provision temporary resources and deprovision them. Shadow Admin states often persist because the agent classified the elevated access as "in use" or "needed for future runs." Resources with no associated active workload but with permissive roles attached are the signal.

If you run monitoring agents, check whether their read-only scope is actually enforced. A monitoring agent that can write to the same IAM policies it is supposed to watch is already a Shadow Admin waiting to be instantiated.

Structural Fixes

Formal intent declaration before any agent run touches IAM. The agent must express its goal in a form that includes negative invariants ie what must not change not just the positive optimization target. The declaration is signed and hashed. Any action not derivable from it is rejected at the API gateway.

Cross-service state monitoring, not individual call validation. A second process with read-only access to the full event stream and veto power over IAM-touching operations, operating on formal reachability analysis rather than statistical anomaly detection. It cannot be modified or reached by the operational agent. Hardware-token gates for IAM policy changes, outside the cloud control plane, close the gap the agent's authorization cannot bridge.

Temporal and spatial permission decay. Every permission grant expires in minutes unless renewed by an out-of-band, hardware-rooted attestation. The agent cannot renew its own permissions. A human can. This is the checkpoint the IAM optimization removed for velocity; put it back where the blast radius is highest.

Single-service scoping. No agent touches IAM, Compute, Network, and Storage in the same execution context. Cross-service optimization goes through a separately monitored orchestrator with no direct IAM write access. This limits the reachable state space to one where formal invariant verification is tractable.

Treat agent deployments as stochastic processes. Model the probability of Shadow Admin emergence as a function of permission breadth, API surface, and operational duration. When that probability exceeds organizational risk tolerance, reduce scope before deploying, not after discovering the state.

The Actual Lesson

The authorization worked. The API gateway worked. The OIDC tokens were valid. The service account had every right to make every call it made. All of it worked exactly as designed, and the infrastructure ended up with a persistent elevated access pathway that no human intended and no policy prohibited.

Verifying that an agent is authorized to act is not the same as verifying that the composition of its actions is safe. Every prior application of the nth-order framework involved an adversary who understood this distinction and exploited it deliberately. Shadow Admin demonstrates that you do not need an adversary. You need a capable optimizer and a permission model with no formal encoding of the invariants it is supposed to protect.

The defense is not better detection of bad actors. There are no bad actors. The defense is structural constraint on what any authorized actor human or machine is permitted to compose.

References: Bilar (2009), On nth Order Attacks, NATO CCDCOE. Chen et al. (2025), arXiv:2509.11173, IEEE S&P 2026. Shadow Admin threat description: sharetxt.live/blog/the-shadow-admin-threat-how-autonomous-ai-agents-could-introduce-undetectable-system-backdoors.