Offensive Security With AI

AI is useful in vulnerability research when it helps with the slow parts: reading unfamiliar code, tracing call paths, organizing notes, comparing assumptions, and turning a rough idea into a smaller question.

It is not useful when it starts inventing certainty.

The workflow below is how I approach AI-assisted research in a way that stays disciplined. The human keeps the important responsibilities: scope, authorization, impact, cleanup, and judgment. AI helps move through the loop faster.

Operating Model

Before I ask an assistant to do anything, I want the work framed tightly enough that the next step is obvious.

The human owns:

• What is authorized.
• What is out of bounds.
• Whether a test is appropriate.
• Whether the evidence proves anything.
• When to stop.
• What gets documented.

AI is good at:

• Searching and summarizing source material.
• Finding repeated patterns across a codebase.
• Tracing one value through several call layers.
• Drafting a small probe or PoC.
• Explaining why a result did not match the hypothesis.
• Turning messy notes into a clean finding outline.

That split matters. The model can help chase a question. It does not get to choose the risk appetite.

Research Prep

Start with current state. A vague prompt creates vague research.

For a new track, I write down:

Field	What I Want
Target area	The feature, component, or behavior being reviewed
Source material	The files, docs, diagrams, or prior notes to start from
Exclusions	Anything that should not be tested, touched, or assumed
Known facts	What has already been confirmed manually
Hypothesis	The specific assumption being tested
Stop condition	What result means pause, scope down, or stop

If I cannot fill that table out, the research is not ready for automation yet.

Environment Thinking

I like to separate fast learning from higher-confidence validation.

The first pass should happen somewhere safe and controlled: an authorized lab, a local copy, or a review environment where mistakes do not create side effects for anyone else. That is where I want rapid iteration, messy notes, and small checks.

Only after the behavior is understood should the research move to a higher-fidelity authorized environment. The point is to confirm that the finding still matters in the way the real system is used, not to skip straight to the loudest possible test.

Keep source material current. Code changes, behavior changes, and old notes can lie.

The Six-Phase Loop

The phases are not strictly sequential. When a high-impact path stalls, scope down, document the highest confirmed impact as a standalone finding, and open a parallel track.

1. Static Analysis

Start from a feature area that is structurally likely to be risky.

Look for components that:

• Accept user-controlled input and send it somewhere else.
• Evaluate user-supplied strings as expressions, templates, or scripts.
• Execute OS commands or access the filesystem.
• Handle credentials, secrets, or sensitive tokens.
• Make authorization or ownership decisions.
• Proxy data between trust boundaries.

The goal is not to declare a bug early. The goal is to understand the shape of the path.

2. Identify The Sink

Find the exact call where user-controlled data reaches the dangerous primitive.

Useful questions:

• What is the parameter name?
• What method makes the dangerous call, and in which file?
• Where was the value first introduced?
• Is the same path reachable from more than one entry point?
• What assumption has to hold for this to be safe?

This is where AI helps a lot. It can trace call chains quickly across a large codebase. I still verify the path myself before treating it as real.

3. Map The Checks

Between input and sink, list the controls that are supposed to keep the path safe.

Check Type	What To Look For
Schema	Required fields, types, length, and shape
Allowlist	Known-good values or permitted operations
Denylist	Blocked strings, patterns, or behaviors
Authorization	Who is allowed to perform the action
Isolation	Boundaries between users, tenants, jobs, or execution contexts
Normalization	Encoding, decoding, escaping, parsing, and canonicalization
None	A field or path that passes through without meaningful review

The interesting bugs often live in mismatches. One field is checked. A neighboring field is not. One route uses the safe helper. Another route quietly bypasses it. Record which fields are validated and which are not because that comparison is the most common source of bypasses.

4. Build The Smallest Safe Probe

Write the smallest possible script that sends the hypothesis payload and observes the response or OOB callback. One file per hypothesis.

Conventions that keep PoCs workable:

• Config block at the top with clear placeholder values and no hardcoded live secrets.
• A cleanup function or mode that removes all test artifacts after the run.
• A comment stating what signal is expected and on which listener.

Start benign before testing for impact. Confirm the surface is reachable with a harmless payload first, like a type check, a math expression, or a read of a known-safe value. If the benign probe returns the expected result, the surface is confirmed and impact probes can follow.

A good probe answers one question. It does not try to prove the entire finding in one jump.

• Can the value reach this path?
• Does the system transform it?
• Does validation reject it?
• Does the output stay literal?
• Does the result change when one input changes?

The probe should have an expected signal before it runs. If there is no expected signal, the result will be hard to interpret.

5. Validate The Evidence

Results need interpretation. This is where rushed research gets sloppy. Include all listener output because even empty output is signal.

Observation	What It Might Mean
Input appears literally in output	Field may not be evaluated or interpreted on this path
SMTP received, HTTP did not	OOB HTTP may be blocked by an outbound filter; try alternate encoding
HTTP path contains command output	Execution confirmed at OS level; escalate to shell
Nothing received on any listener	Notification may not have fired; check whether the create step succeeded before blaming the trigger
Result is empty or undefined	Path may run but expression or state is wrong
Validation rejects the input	A boundary control is active; inspect what it actually enforces
Action succeeds but no signal	Trigger path, timing, or observation point may be wrong
Signal appears but is modified	A sanitizer, encoder, or policy layer may be changing the result
Result is inconsistent	Path may be asynchronous, cached, stateful, or dependent on context

AI can help explain possible meanings, but I do not let it pick the conclusion without evidence.

6. Escalate Or Scope

Every loop should end with a decision.

• Escalate if the evidence is real and the next step is still authorized.
• Scope down if a lower-impact issue is confirmed and useful by itself.
• Pivot if the blocker is clear and another path is more likely.
• Stop if the result is speculative, out of scope, or not reproducible.

The trap is leaving a track half-alive forever because it might become something bigger later. If the confirmed impact is useful, document it. If it is not useful, write down why and move on.

Do not ask the agent to keep pushing for escalation at the same time you are asking it to write up the confirmed finding. Pick one mode.

Directing The Agent

The agent is most effective when given a clear starting point and unambiguous feedback at each step. Vague instructions produce vague hypotheses.

Starting a research track

At the beginning of a session or when opening a new surface area, give the agent three things.

1. The specific area to investigate

Point at a feature, a file, or a question, not a general goal. The more specific the entry point, the tighter the initial code review.

Good: “Look at how SMTP notification targets evaluate the subject and body fields. I want to know if user input reaches a dangerous call.”

Too broad: “Find vulnerabilities in the notification system.”

2. The source files to read first

Reference the relevant file paths from your source code map. The agent will start reading there rather than searching the entire repo.

3. What you already know

If you have already done any manual review, share it. The agent should not re-derive what you already know. It should start from where you stopped.

Steering mid-session

Once the loop is running, use short directive prompts rather than open-ended ones. The agent has all the source context; it needs a decision, not a restatement of the problem.

When a probe returns unexpected results: Paste the listener output and state what you expected. Let the agent diagnose.

When a path is stalled: Say explicitly that you want to pivot rather than keep pushing the same direction.

When something works and you want to escalate: Name the impact level you want to reach next. The agent will design the escalation path.

When you want to scope down and write a ticket: Tell the agent the highest confirmed impact and ask for a standalone write-up.

What to paste back

Include all of the following, even when a probe fails:

• SMTP listener output (or [SMTP] nothing received)
• HTTP listener output (or [HTTP] nothing received)
• TCP listener output (or [TCP] nothing received)
• Full script stdout, including what the probe was and what it expected

The content of evaluated fields is the primary signal, not just whether output arrived. If a callback arrives 30+ seconds after triggering, the execution path is async and the trigger may have worked even if the HTTP response timed out.

What the agent does with it

Observation	Agent interpretation	Next action
Field contains expected evaluated value	Surface confirmed	Escalate to higher-impact probe
Field contains literal payload string	Expression not evaluated on this field	Find the correct trigger path or field
Field is undefined or empty	Expression evaluated but returned no value	Fix expression syntax or return value
Nothing on any listener	Notification never fired or expression errored silently	Check whether the create step succeeded first
HTTP path contains command output	Execution confirmed at OS level	Escalate to reverse shell
HTTP 400 on create	Field value rejected by schema validation	Inspect error body; adjust payload to pass validation

The Agent Feedback Loop

The loop works best when the human gives the assistant exact state.

Good inputs:

• The specific area being reviewed.
• The files or notes to start from.
• What has already been confirmed.
• The exact output from the last probe or review step.
• What was expected.
• What paths should be excluded.

Bad inputs:

• “It did not work.”
• “Find something worse.”
• “Try every bypass.”
• Multiple unrelated questions in one prompt.
• Secrets or sensitive data pasted into the conversation.

The human provides evidence. The assistant helps interpret and plan the next small move.

Prompts That Work

Starting a track:

Start with this feature area and trace how user-controlled input reaches sensitive operations.
Return the call chain, the controls in between, and the first assumption worth testing.
Do not generate exploit payloads.

When a result is confusing:

I expected this probe to show [expected signal], but it showed [actual signal].
Based on that result, is the hypothesis wrong, is the trigger path wrong, or is the evidence
inconclusive? Give me the next smallest safe check.

When a path is blocked:

We have tried this path and the control appears to be working. Identify the blocker precisely,
then suggest whether to scope down, pivot, or stop.

When something works and you want to escalate:

[Callback type] confirmed. What is the path from here to [next impact level]?

When it is time to document:

Turn these notes into a finding outline with confirmed impact only. Separate evidence from
speculation, list cleanup steps, and call out the open questions.

What I Avoid

• Letting AI decide that a finding is real before I can explain the evidence.
• Combining multiple theories in one probe.
• Treating a failed test as useless. Failed tests still narrow the map.
• Asking for a final write-up before the confirmed impact is clear.
• Keeping sensitive access material or private operational details in notes.
• Asking multiple unrelated questions in one message.
• Describing the desired outcome without the current state.

The point is not to make security research automatic. The point is to make careful research faster, cleaner, and easier to hand off.