AI Gated Loader: Teaching Code to Decide Before It Acts

TL;DR AI gated loaders collect telemetry, apply a policy with an LLM, and execute only when defined OPSEC rules are met.

• Why: timing and context beat static delays
• How: snapshot then structured prompt then JSON decision then enforces and fail closed on errors
• Use: safer, more realistic red team simulation

Offense and defense are always in contest. Red teams try to slip past detection while defenders adapt and refine their detections. At its core, this contest is about intelligence and timing. Payload loaders are a staple of offensive operations and, historically, simple to implement. The overall concept behind shellcode loaders focuses on methods to put shellcode in memory and execute it. Later the offensive community added timers and clumsy sandbox checks, but the shellcode core behavior did not change and focused on executing the shellcode regardless of context. In a world with endpoint detection and response (EDR), heuristic AV, and machine learning-based detections, the historical approach to loading shellcode into memory is noisy and obvious to defenders. For example, static loaders become detection magnets that can hinder an unannounced red team.

AI gated loaders are an alternative method of loading shellcode that makes use of simple concepts. They are a practical way to leverage timing and context during execution. First, the AI gated loader takes a narrowly focused snapshot of the host. Then, the AI gated loader prompts an LLM for a compact JSON decision. Finally, the loader executes only when the policy gates are satisfied. This flow gives offensive operators a clear audit trail and a repeatable way to compare detections.

The Problem With Traditional Loaders

A conventional loader typically

• Decrypts shellcode
• Allocates memory
• Executes immediately

The conventional method is efficient but blind to EDR. If an EDR is watching the shellcode loading process at that moment, it will probably trip a detection rule. The offensive community tried evasions such as fixed delays like sleep for 10 minutes; however, malware analysis sandboxes learned to advance clocks. Additionally, the defensive community’s defensive tooling and corresponding detection logic matured to identify scheduled execution. The offensive community’s evasions for conventional shellcode loading became brittle and predictable.

Some additional evasions that the offensive community bolted onto conventional shellcode loader execution tried mouse movement checks or uptime checks. These evasions have been executed with varying degrees of success, but these evasions often missed the messy and unpredictable signals of a real user session. Real workstations are messy and difficult to pattern. For example, browsers are open, background syncs run, and users alt tab for five seconds then go back to a massive spreadsheet. That is the environment offensive operators must strive to mimic, or at least not contradict.

Why AI?

The short answer is that timing and environment awareness make a big difference when blending shellcode loading within the noise of real users. An AI gate lets the loader pause and ask a human style question. Some example prompts that AI gated loaders use:

• Does this host look like a real user workstation right now or like a sandbox that will hand execution over to an analyst? 
• Is Defender or other monitoring active at the moment? 
• Is there a safe exit route for outbound traffic or is everything blocked and logged?

The LLM does not execute the shellcode on behalf of the offensive operator. The LLM only returns a tight JSON reply that contains a Boolean “allow” field, a numeric confidence, and a short reason. The AI gated loader treats that response as a data point in a ruleset. Put plainly, the LLM is a decision gate that says yes or no and explains why. The Hybrid Autonomous Logic Operator (HALO) project I have linked in this blog contains code that displays how the telemetry is collected (https://github.com/In3x0rabl3/HALO/blob/main/telemetry/telemetry.go), how the prompt is generated (https://github.com/In3x0rabl3/HALO/blob/main/ai/ai.go), and how the reply is parsed (https://github.com/In3x0rabl3/HALO/blob/main/ai/ai.go#L92) The below portion of this post will discuss the different portions of the linked project and aid offensive operators in the use of AI gated shellcode loaders. 

Anatomy of an AI-Gated Loader

At a high level, the process is straightforward. 

1. First, the loader builds a system snapshot and passes those details to the model
2. Next, the loader formats that object and sends it to the LLM as the user input
3. The loader then reads the assistant output, and it extracts the first JSON block
4. Finally, the loader unmarshals into an expected struct and it applies a simple threshold gate. 

If anything goes wrong the default is “deny”. That control is important because bad model output should not trigger execution.

Below is a screenshot of the Telemetry struct (https://github.com/In3x0rabl3/HALO/blob/main/telemetry/telemetry.go#L19). from the HALO project to highlight the fields that matter when filtering based on the AI gate. This is the information that gets sent to the model after any redaction or hashing you apply. The next section of this post will discuss the importance of gathering these data points for the LLM’s execution decision. 

Telemetry struct example:

How the telemetry is built

The HALO project will sample the processes, drivers, network information, USB devices, and session information of the target endpoint that contains running the loader process. The project will exclude the loader process and its parent process from the gathered telemetry, so the model is not confused by the loader process noise. The project sorts the process list and counts deviations from a baseline. This allows the transient processes to avoid dominating the snapshot. Gathering an accurate baseline is important for giving the model context about “normal” signals from the target host.

The HALO project collects a few lightweight user presence signals as well. Some examples of these user presence signals are the idle time, which is measured in seconds, and the active window title of the user. Additionally, the project computes working hours Boolean based on the current hour. The telemetry collected is not novel to evasion tradecraft, these signals are just simple indicators that help the model decide whether the host looks like a real user session. 

The project also takes some basic network measurements such as open connections and network traffic indicators. The loader does not stream raw packet captures to the model. Instead, it sends strings about flows and endpoints. This design choice helps minimize sensitive data while still allowing the model to reason whether outbound traffic is likely to be successful.

Offensive operators can tweak the collected telemetry logic in the HALO project, but the general idea will still be the same. The goal is to gather a compact, relevant snapshot that shows user activity, running processes, network activity, and a small set of environment signals.

How the prompt is built and the model is queried

Below is a screenshot of the AI response struct from the HALO project to highlight the exact expectations of response from the model.

response struct:

The HALO project constructs a system prompt that prompts the model to observe, analyze, decide, and respond. The user prompt provided to the model is a pretty-printed telemetry object. The code sets temperature to zero so the model is predictable and repeatable which helps with testing. In the live code of the project, the request body includes a pinned model name so the behavior can be tracked across runs. Here is an example of the actual request skeleton used in the code.

Request skeleton:

I want to guide your attention to this, because pinning the model version matters when prompting the model. Different model versions have different generation quirks and different priors. If offensive operators using my HALO project change the model and do not update the logs the operators will lose traceability. The project automatically logs the raw model reply for audit so operators can always go back and see the model’s response. If you don’t pin the model version, two runs of the same prompt might not produce identical replies. This makes it harder to debug, reproduce results, or trace where something went wrong.

How the reply is parsed

Models sometimes add extra text or stray commentary around the JSON response the user asked for. The HALO project automatically guards against excess text by finding the first curly brace and the last curly brace and extracting the first top-level JSON block. The top-level extracted string is then un-marshaled into the AI response struct. Below is a screenshot example of the extraction helper from the project.

JSON extraction helper:

If the parsing fails for whatever reason, the loader treats the reply as a “deny” response. Then ensures that the loader does not partially trust the reply. No guessing on next steps is required. That fail-close behavior is the safety net that keeps the system from making accidental decisions on behalf of the operator. The project will automatically log the raw assistant output and the specific error where the parse failed so that the operator can investigate the model’s response.

Decision logic in code

The decision gate is intentionally auditable as the program expects “Allow = True” and a confidence score of at least “0.80” before proceeding. The project will then write a decision line with the following fields:

• Timestamp
• Decision
• Confidence score
• Reason for decision
• Hash of the telemetry snapshot for later review.
  • That hash lets the operator prove what telemetry the model saw when it made the decision without storing the raw sensitive values in long term logs.

Below is a snippet of the decision loop that highlights the basic threshold logic.

Decision loop snippet:

The project also prints the raw model text so you can see the model’s thoughts and the reason fields. Operators can add an additional operator approval step after the model returns “Allow = True” if they want an extra level of control. 

Use Cases

AI-gated loaders provide value when execution must adapt to real conditions while remaining policy-bounded. Below are some realistic use cases where offensive operators can leverage AI gated loaders:

Training and evaluation

• Measure detection efficacy across immediate, fixed-delay, and AI-gated baselines
• Exercise blue-team playbooks with explainable allow/deny decisions and confidence scores
• Validate that deny paths fail closed under parse errors, timeouts, or low confidence
  

Environment awareness

• Defer actions until normal user-activity signals are present
• Avoid disallowed contexts based on host role, network context, or session state
• Coordinate timing across hosts to reduce simultaneous telemetry spikes
  

Operator control

• Require dual approval from the LLM decision and a local rules gate
• Enforce calibrated confidence thresholds and cooldowns
• Record structured audit logs with timestamps and hashes for post-exercise review
  

Demo

Below are two snippets of the decide output showing the loader making decisions in real time.

Scenario 1 — Execution Blocked

The AI gated loader takes a quick look at the host and spots Defender and AppLocker running. The parent is powershell.exe, the box is idle, and nothing noisy is happening on the wire. The model returns “allow false” with high confidence. The reason is simple. Local controls are active, and this path is likely to get flagged. The loader writes the decision, marks the run as not safe, and drops back into the watch loop to try again later.

Scenario 2 — Execution Approved

The loader waits and watches. Processes, drivers, and flows line up with the baseline and the only change is the loader itself. Only Windows Defender is present. Network traffic looks normal with common internal and public peers. The system is idle, which lowers the chance a user sees anything odd. The model returns “allow true” with confidence at 0.85 and notes one moderate risk that Defender can flag PowerShell child processes. Overall exposure is low. The loader records the decision and proceeds with inline execution while keeping the audit trail for review.

Benefits and Risks

Benefits that matter

• Adaptive execution based on real environment signals
• Clear audit trail and reason for every decision
• A simple way to compare detection outcomes across different timing strategies
• Separation of policy from mechanics so you can update rules without changing code
  

Risks to be honest about

• The model can misclassify and say allow when it should not
• The policy can drift if you change prompts or models without calibration
• Too much automation can reduce human attention if you are not careful
• Telemetry can be sensitive so minimize and hash before sending externally, and be cautious with external AI model integrations to avoid exposing user, company or system data

The Road Ahead

AI gated loaders are still in the early stages of development, but the direction is obvious to offensive practitioners. Using AI to gather richer context with stronger guardrails and integrate more tightly with enterprise controls enables offensive operators to validate defensive measures at the same maturity level as the organization’s EDR capabilities. A pinned model can act as a decision gate that reviews redacted and bucketed telemetry, then returns a simple allow or deny with a confidence score. A single call can steer practical work in a lab. Pull staged shellcode only when conditions look safe, switch to alternate execution methods based on EDR vendor, place decoys that pull blue teams into false trails, watch which outbound traffic is actually permitted before any command and control (C2) attempt, generate small bits of code from scratch on the fly for time sensitive paths, and shape traffic so common remote tools are harder to spot on the wire.

Keep future use safe and boring in the right ways. Minimize and hash telemetry before it leaves the host, pin model and prompt versions, treat parse errors, timeouts, and low confidence as a no, and keep a human in the loop for any module change. Require written approval for anything that could touch customer data, then log the decision, the confidence, and a hash of the snapshot so the result is explainable later.

Tools that wait and weigh risk are operationally more mature than tools that rush with low enrichment and decision capabilities. Red teams can leverage AI gated loaders to gain more accurate timing with execution and avoid noisy tradecraft. Additionally, defenders gain clear and accurate signals they can use to tune their detection strategies. The contest will be decided by intelligence and timing.