How Security Researchers Can Get Their Agentic Findings Heard: A Structured Interview Framework

Your agentic security finding is not a finding until someone with decision-making power understands it well enough to act on it. Most researchers stop at the proof-of-concept and assume the work speaks for itself. It does not.

This assumption is understandable. In traditional vulnerability research, a CVE number, a CVSS score, and a reproduction script carry most of the communication weight. The taxonomy exists. The audience knows how to read it. You file the report, patch coordination happens, disclosure follows.

Agentic systems do not have that scaffolding yet. When you find a prompt injection vector that lets an attacker hijack a ReAct-style agent's tool call sequence, there is no standardized severity framework that captures what that means operationally. The people you need to convince - engineering leads, product owners, occasionally a CISO who came up through network security - are often working from mental models built for static software. The burden of translation falls on you. If you do not have a structured way to carry that burden in an interview or briefing setting, your finding gets triaged as a low-priority theoretical risk and disappears.

The Misconception About How Agentic Findings Get Evaluated

Most researchers assume that technical rigor is the primary variable in whether a finding lands. It is not. The primary variable is whether the audience can map the finding to a failure mode they are already worried about.

This misconception comes from a reasonable place. In penetration testing and vulnerability research, technical precision is what separates a credible finding from noise. But in an interview or stakeholder briefing about agentic security, precision alone does not move people. What moves people is threat narrative - a clear line from attacker capability to system state to business consequence.

The agentic context makes this harder because the failure modes are compositional. A memory poisoning attack in a system with persistent context does not look like a single exploited vulnerability. It looks like a sequence of individually plausible actions that produce a catastrophic outcome. That is genuinely difficult to communicate to someone who is still thinking in terms of SQL injection or misconfigured S3 buckets.

Where Researcher Interviews Break Down in Practice

The most common failure mode is leading with the mechanism instead of the impact. A researcher will spend the first ten minutes of a briefing explaining how indirect prompt injection works across trust boundaries in a multi-agent pipeline. By the time they get to what an attacker could actually do with it, they have lost the room.

The second failure mode is underspecifying the preconditions. Agentic attack chains often require a specific confluence of tool permissions, context window contents, and agent configuration. If you do not name those preconditions clearly, the audience will assume the attack is either trivially preventable or purely theoretical. The OWASP LLM Top 10 documents several of these attack classes - prompt injection, insecure output handling, excessive agency - but even those descriptions require translation into a specific system's architecture before they mean anything actionable to an engineering team.

The third failure mode is not distinguishing between what you demonstrated and what you inferred. In agentic systems, the gap between a demonstrated proof-of-concept and the actual blast radius can be large. Overstating it kills credibility. Understating it kills urgency.

The Corrected Mental Model for Interviews

Think of the interview or briefing as a threat modeling session, not a presentation. Your job is to walk the audience through an attacker's decision tree, not to impress them with your exploitation technique. Practitioners working through agentic threat modeling exercises consistently find that framing findings as decision trees rather than exploit chains shortens the time from briefing to remediation action.

Structure your communication in three layers. First, name the capability the attacker gains. Second, describe the architectural condition that makes it possible - be specific about which component, which trust boundary, which tool permission. Third, trace one concrete path from that capability to an outcome the audience cares about: data exfiltration, lateral movement to adjacent systems, loss of human oversight in an automated pipeline.

This structure works because it separates what you know from what you are inferring, and it gives the audience something to push back on at each layer. Pushback is good. A stakeholder who argues with your threat narrative is engaged with it. One who nods politely has already mentally filed it under "follow up later."

What This Looks Like in a Real Briefing

Say you found a tool-call interception path in a LangChain-based agent where a malicious document in the retrieval corpus can redirect tool invocations. Do not open with the injection mechanics.

Open with: "An attacker who can influence what goes into this agent's retrieval context can change which tools it calls and with what arguments. That includes the tools with write access to your data store."

Then name the architectural condition: the agent treats retrieved content as trusted input when constructing tool call parameters, and there is no sanitization layer between retrieval and tool invocation. Then show the path: attacker poisons the corpus, agent retrieves the document during a legitimate user session, tool call is redirected, data is written or exfiltrated.

That sequence takes about ninety seconds to deliver. It is specific enough to be credible, concrete enough to be alarming, and structured enough that the audience knows exactly what architectural decision needs to change. Research on indirect prompt injection from Greshake et al. laid out this attack class early - the mechanics are documented, which means you can reference prior work without having to justify the basic threat model from scratch. For a deeper look at how prompt injection defenses are being implemented in production systems without compromising agent capability, practitioners at Stripe, Snap, and Sondera have documented their approaches in detail worth reviewing before any stakeholder briefing.

The Operational Move

Before your next briefing, write out your finding in the three-layer format above. If you cannot get through all three layers without making an unsupported inference, that is diagnostic. It tells you where your evidence is thin and where you need to either tighten the proof-of-concept or be explicit about what you are assuming.

This is not spin. It is the same epistemic discipline you apply when you write a disclosure report - applied to the communication layer instead of the technical layer. The field is young enough that the researchers who figure out how to make findings land are the ones who will actually shape how agentic systems get built and defended. That is worth treating seriously.