A Primitive Is Not an Attack Path

Disclosure: This article is based on notes from an authorised security lab and was developed with AI assistance for structure and editing. It contains no machine-specific exploit path, credentials, or unpublished platform material.

A working primitive is a fact. An attack path is an argument.

That distinction sounds obvious until an assessment produces several promising results at once. An input is controllable. A credential authenticates. An internal service is reachable. A privileged operation appears to exist. Every observation can be correct while the story connecting them is still wrong.

The difficult part of a multi-stage assessment is often not finding another technique. It is proving that the capabilities already observed compose into one causal path.

This article presents the method I use to make that proof explicit. It applies to infrastructure, web applications, identity systems, and AI agents with tools. It also makes reports shorter, because a reader can see what was observed, what was inferred, and where confidence stops.

The story usually arrives before the evidence

Security work rewards pattern recognition. We see a familiar condition and quickly form a plausible narrative around it. That instinct is useful for generating hypotheses, but dangerous when it quietly becomes the conclusion.

Suppose an assessment establishes four facts:

attacker-controlled data reaches a component;
a valid identity is available;
another system is reachable from the current position;
a sensitive operation exists somewhere in that system.

It is tempting to describe this as a complete route to the sensitive operation. Several questions remain unanswered. Does the controlled data reach the relevant parser or decision point? Does the identity have the required authority? Is the reachable service the one handling the privileged operation? Does the action actually execute? Can its effect be observed outside the component that claims success?

Those missing links are not editorial details. They are the assessment.

Separate primitives from paths

A primitive is a capability demonstrated under stated conditions. Examples include reading a bounded resource, influencing an argument, authenticating as a particular role, reaching a service, or causing a defined state change.

An attack path is an ordered composition of primitives in which the output and conditions of one step satisfy the requirements of the next.

That gives us a practical model:

Verified impact = primitive × reachability × authority × execution × readback

The multiplication sign is deliberate. If any factor is zero, the claimed impact is not established.

This model also prevents a common reporting error: treating theoretical severity as observed impact. A component may expose a dangerous capability, but the assessment still needs to establish whether the tested actor could reach it, invoke it with sufficient authority, and produce the stated effect.

Build an evidence chain, not a highlight reel

I use a small evidence record for each material claim. It contains nine fields:

Claim — the conclusion being tested.
Observation — what was directly seen.
Evidence — the artefact or behaviour supporting the observation.
Alternative explanations — other causes consistent with the same result.
Discriminating test — the smallest test that separates those explanations.
Result — what happened when that test ran.
Confidence — confirmed, probable, possible, or not verified.
Provenance — who or what supplied the information.
Cleanup — what temporary state was removed.

The record does not need to become bureaucracy. A compact table or a few disciplined notes are enough. Its purpose is to stop the language of the report from becoming stronger than the evidence behind it.

1. Record observations without interpretation

Start with sentences that a second reviewer could verify:

"The service returned a success status."
"The account could authenticate to the interface."
"The resulting object was visible through an independent read operation."

Avoid folding an explanation into the observation. "The exploit worked" may hide several untested assumptions. "The service returned a success status and the object appeared in a separate readback" describes what actually happened.

2. Write competing hypotheses

For every important result, ask what else could produce it.

A success message may be optimistic UI state. A relevant answer from an assistant may come from its language model rather than a tool call. Access to one resource may come from inherited permissions rather than the route being tested. A state change may have existed before the test.

Competing hypotheses are not an admission of uncertainty. They are how uncertainty becomes testable.

3. Design the smallest discriminating test

The best next step is not always the most powerful exploit. It is the cheapest test that could prove the current explanation wrong.

Useful tests include changing one input while holding the others constant, using a unique harmless marker, comparing precondition and postcondition, checking the action through another interface, or repeating the operation with reduced authority.

This approach limits side effects and produces clearer evidence. If a benign marker proves that data crossed the boundary, there is no reason to begin with sensitive content.

4. Require independent readback

Self-reported success is weak evidence. A model can say that it called a tool. An API can return an accepted response before processing. A client can display a local update that never reached the server.

Whenever possible, verify the effect through a separate observation path. Read the created object back. Query the resulting permission state. Inspect the receiving system. Compare a trustworthy audit event with the initiated action.

The readback should demonstrate the effect, not merely repeat the original component's claim.

Dead ends belong in the result

A failed branch can be valuable when it closes a hypothesis.

The useful record is short: what assumption was tested, what evidence contradicted it, and what decision followed. This prevents the same attractive mistake from reappearing later and helps another reviewer understand why the final route is narrower than the initial possibilities.

Dead ends should not be inflated into achievements. Nor should they be deleted from the reasoning simply because they make the assessment look less linear. Real investigation branches. Professional reporting explains where those branches ended.

There is also an operational benefit. When evidence is organised by claim rather than chronology, abandoning one route does not destroy the value of the observations collected along it.

Provenance is part of technical accuracy

Security conclusions often combine direct observation, supplied documentation, another researcher's technique, automated analysis, and external assistance. Those sources do not all support the same claim.

Provenance should answer three questions:

Which parts were independently demonstrated?
Which parts came from a cited external source?
Which conclusions remain unverified in the current environment?

This is particularly important when external information completes a chain that the assessment did not independently establish. The correct result is not to erase the assistance or discard the earlier work. It is to draw the boundary precisely.

Attribution is not modesty theatre. It lets the reader evaluate reproducibility and prevents a valid partial result from being weakened by an overstated final claim.

The same method applies to AI agents

Agent security makes causal discipline even more important because natural-language output can look like evidence of action.

A successful prompt injection is a primitive. It may demonstrate influence over model behaviour. It does not, by itself, prove access to a tool, authority over a target resource, successful execution, or external impact.

The chain must still be tested:

Did attacker-controlled content influence the agent's decision?
Was the relevant tool actually available and invoked?
Did the tool enforce the requesting identity's permissions?
Did the downstream system execute the operation?
Was the effect confirmed independently?

This is where classic security engineering and AI red teaming meet. The model can propose an action, but the application must enforce what is reachable, which identity is used, what parameters are allowed, and which actions require approval.

OWASP describes excessive agency in terms of excessive functionality, permissions, or autonomy, and recommends limiting tools and their capabilities to the minimum required. The practical testing question is the same one used elsewhere in security: which boundary is enforced by code, and what evidence shows that it held?

Identity deserves its own place in the chain. NIST's work on software and AI agent identity and authorisation reflects the growing need to know which agent is acting, on whose behalf, with which authority, and under what constraints. A convincing agent response cannot substitute for that control plane.

A compact field workflow

The complete method fits into seven steps:

Inventory demonstrated primitives.
State the intended impact as a falsifiable claim.
Draw the required links: reachability, authority, execution, and readback.
List alternative explanations for each link.
Run the smallest safe test that separates them.
Record confidence and provenance.
Remove temporary state and verify cleanup.

This workflow is intentionally conservative. It does not make findings smaller. It makes them defensible.

A report produced this way can distinguish three outcomes cleanly:

Confirmed path: every required link has evidence.
Partial path: useful primitives were demonstrated, but one or more links remain open.
Rejected path: a discriminating test contradicted a required assumption.

All three outcomes can provide value. Only the first supports a claim of verified end-to-end impact.

The standard is defensibility

The strongest security work is not the chain that looks most impressive. It is the chain whose claims, limits, and provenance remain defensible after the excitement is gone.

Finding primitives requires technical skill. Turning them into a verified path requires something broader: causal reasoning, controlled tests, independent observation, and honest attribution.

That is also what makes the work transferable. Tools change. Products change. Agent frameworks change weekly. The obligation to prove how one observed capability becomes another does not.