Andromeda shows how agentic payload generation changes red-team tradecraft

At a glance

What this is: Andromeda is a research prototype that uses LLM agents to generate bytecode payloads dynamically from live memory context, with a key finding that this approach reduces reliance on static artefacts and predictable payload signatures.

Why it matters: For IAM, NHI, and security teams, this matters because agentic systems can change how offensive tooling is created, delivered, and concealed, which raises the bar for detection, environment control, and governance of AI-enabled execution paths.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Straiker’s analysis of Andromeda and agentic payload generation

Context

Agentic payload generation pushes offensive tooling beyond the model that most defenders still optimise for. Traditional detection assumes a payload has a relatively stable signature, a reusable binary form, or a predictable execution path. This article’s core point is that an agent can reason over runtime context and generate code on demand, which creates a moving target for both endpoint controls and identity governance.

That shift matters to identity practitioners because AI systems that can select actions and generate code sit much closer to non-human identity governance than conventional automation does. Once an AI system can create execution artefacts dynamically, the security question is no longer only who may run the tool, but what the system is allowed to decide, generate, and execute at runtime. That is an emerging control problem, not a mature one.

Key questions

Q: How should security teams govern AI-generated code in production environments?

A: Security teams should treat AI-generated code as normal production code with extra provenance risk. Require architectural review, test coverage, static analysis, and approval before merge. Then bind the agent and the build pipeline to least privilege, short-lived credentials, and complete audit logging so implementation speed does not outrun control.

Q: Why do agentic payloads make traditional detection less effective?

A: Because traditional detection depends on artefacts that are stable enough to recognise later. Agentic payloads can be generated per target, kept in memory, and discarded after use, which removes many of the cues file-based or hash-based tools expect. Defenders need behavioural telemetry and runtime context, not just binary signatures.

Q: What do security teams get wrong about in-memory execution risk?

A: They often focus on hiding files rather than controlling the decision path that creates the payload. In-memory execution matters because it reduces artefacts, but the deeper problem is that an agent can continuously adapt code to the target context. Governance has to cover the generation step, not only the delivery step.

Q: How can organisations test AI-generated offensive behaviour safely?

A: Use isolated sandboxes that mirror real target conditions closely enough to reveal runtime behaviour, then observe how the agent changes its output under different memory layouts and permission sets. The goal is to learn where the system adapts, where it fails, and which controls stop the transition from lab behaviour to live execution.

Technical breakdown

How agentic payload generation works at runtime

Andromeda combines two LLM-driven functions: one reasons about what a payload should do, while the other generates position-independent bytecode that matches the target’s current memory context. Position-independent code is designed to run without depending on fixed memory addresses, which makes it portable across contexts and harder to detect with file-based controls. The key technical change is that the payload is not precompiled and reused. It is synthesised against live runtime information, then delivered for immediate execution. That compresses the time between instruction, generation, and effect, which is why static signatures become less useful.

Practical implication: defenders need controls that inspect runtime behaviour and memory execution paths, not only files and hashes.

Why in-memory execution reduces artefacts for detection

In-memory execution keeps the payload inside RAM rather than writing it to disk, so many traditional artefacts never appear. That includes file hashes, stable binaries, and some forensic traces that endpoint tools and analysts rely on during triage. The article also contrasts this with reverse shells, which can be louder and easier to correlate because they create persistent network behaviour. Agentic generation adds another layer of concealment because the exact bytecode can differ per target, meaning the same operation may never produce the same observable payload twice. That makes retrospective hunting harder and raises the value of behavioural telemetry.

Practical implication: increase memory, process, and command telemetry coverage where static file monitoring is insufficient.

Why live memory context changes the offensive model

The deeper shift is not just delivery, but adaptation. If the agent can inspect a target’s current function offsets and operational context, it can tailor code to the environment at the moment of execution. That narrows the gap between reconnaissance and exploitation, because the tool is no longer a fixed object but a runtime decision system. For defenders, that makes lab testing, sandboxing, and controlled simulation more important, because they are the only places where the behaviour can be studied safely before real-world exposure. This is the kind of change that affects adversary modelling as much as detection engineering.

Practical implication: build simulation environments for AI-generated payload behaviour before it appears in production telemetry.

Threat narrative

Attacker objective: The attacker’s objective is to execute bespoke post-exploitation actions without leaving a reusable payload signature or obvious file-based artefact.

1. Entry occurs when an operator or automated workflow reaches a target environment where the agent can inspect live memory context and generate code from it.
2. Credential or execution context is then abused to move from ordinary access into in-memory payload generation, avoiding pre-built artefacts that defenders might normally flag.
3. Impact follows when the dynamically generated payload executes with target-specific precision, reducing detection opportunities and increasing the chance of successful post-exploitation.

NHI Mgmt Group analysis

Agentic payload generation creates governance debt faster than most detection stacks can absorb. The important issue is not that a prototype can write code, but that it collapses the distance between decision and execution. When code is produced at runtime from live context, standard review models lose the stable object they were built around. Practitioners should treat this as an emerging policy and telemetry gap, not just an offensive research curiosity.

Runtime adaptation is becoming a named control problem for AI-enabled tradecraft. A useful way to describe the issue is runtime context divergence: the payload evaluated in a lab is not the payload executed on the target because the agent continuously rewrites its own operating assumptions. That means defenders need evidence of what the system decided, not only what binary finally ran. The control gap is visible wherever logging stops at process launch instead of recording decision provenance.

Non-human identity governance now extends to code-generating systems, not only service accounts and tokens. If an AI system can create execution artefacts, its identity boundary is no longer just authentication. It also includes authorisation to generate, stage, and adapt actions. That makes NHI governance relevant to offensive and defensive AI alike, because the question becomes whether the system is allowed to reason into new capabilities at runtime. Practitioners should map those permissions explicitly.

Endpoint and identity programmes need a shared model for AI-assisted execution risk. EDR can still matter, but only if it is paired with identity-aware controls that understand which systems are authorised to generate, retrieve, or execute code. Without that link, defenders may detect the payload but miss the policy failure that allowed the agent to create it. The practical conclusion is that AI security, NHI governance, and endpoint detection now need to be designed together.

What this signals

Runtime context divergence is the control gap this research makes visible. Once an agent can generate payloads from live target state, security teams need to stop thinking only about what was executed and start recording how the decision was formed. That is where identity-aware telemetry, policy enforcement, and detection engineering begin to overlap.

For practitioners running AI-enabled development or red-team tooling, the practical shift is toward authority boundaries rather than tool categories. Systems that can generate or adapt code should be treated as non-human identities with scoped permissions, auditable intent, and explicit containment. That framing aligns well with the policy logic in the NIST AI Risk Management Framework and with agent-specific controls in OWASP Agentic AI Top 10.

The immediate programme signal is to combine EDR, identity governance, and lab simulation. If a system can write the next payload on demand, then access reviews alone will not describe the risk. Teams need evidence of which agents can generate code, which can execute it, and which environments are authorised to absorb that behaviour.

For practitioners

• Restrict runtime code generation paths Identify where AI systems, scripts, or internal tools can generate executable content on the fly, then require explicit approval for those paths in production-like environments. Treat code synthesis capability as a privileged function, not a generic productivity feature.
• Instrument memory-level detection signals Tune monitoring for in-memory execution, dynamic module loading, and unusual function resolution patterns, because static file indicators will miss payloads that are created and discarded inside RAM.
• Separate AI reasoning from execution authority Do not let the same system both decide and directly execute high-risk actions without a control boundary. Put policy checks, logging, and containment between agent output and target-side execution.
• Build controlled sandboxes for agentic payload testing Use isolated lab environments to study how agent-generated code behaves against representative memory layouts before any real deployment or red-team exercise, so you can observe failure modes safely.

Key takeaways

• Andromeda shows that agentic systems can compress payload generation, adaptation, and execution into a single runtime decision path.
• Static detection models are weaker when the payload is generated per target, kept in memory, and discarded without a reusable artefact.
• Security teams should govern AI code-generation authority as a privileged capability and test it in controlled environments before exposure.

Key terms

• Agentic Payload Generation: The creation of executable code by an AI system at runtime rather than before deployment. In this pattern, the system reasons about the target context, produces tailored payload logic, and sends it for immediate execution, which makes the payload harder to signature and govern.
• Position-independent Code: Machine code that can run correctly regardless of where it is loaded in memory. It is used in exploit and post-exploitation tradecraft because it avoids dependence on fixed addresses, making runtime behaviour more portable across processes and environments.
• Runtime Context Divergence: The gap between the behaviour a system appears to have in a lab or review environment and the behaviour it produces on a live target. For agentic tooling, the divergence happens because the system adapts its output to the target’s live state, making static analysis less predictive.
• In-memory Execution: Execution that happens inside RAM without writing a durable file to disk. Security teams care about it because it reduces common forensic artefacts and can bypass controls that rely on file visibility, stable hashes, or persistent process indicators.

What's in the full article

Straiker's full research post covers the operational detail this post intentionally leaves for the source:

• Step-by-step explanation of the Tinkr, Tailor, and Soldir components and how they interact in the agentic workflow
• The live runtime flow for generating and delivering bytecode against a target memory context
• Implementation details on how the prototype uses SKILL.md files and native function documentation to shape payload generation
• The researcher’s discussion of current limitations, including stability, platform coverage, and future experimentation paths

👉 Straiker’s full post covers the agent workflow, runtime memory context, and prototype limitations in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It gives practitioners a practical way to align identity controls with emerging AI execution risk.