A serious finding identifies the entry point, the tool pivot, the data or workflow reached, and the business impact. If the test cannot reproduce a path across the runtime stack, the result is usually a prompt artefact, not evidence of exploitable agent behaviour.
How teams decide a red team finding is material, not just noisy
A finding becomes serious when it shows an end-to-end path that crosses the agent runtime, not just a prompt trick. Teams should be able to point to the entry point, the tool or action pivot, the reachable data or workflow, and the downstream business effect. If that chain cannot be reproduced, the result is usually a prompt artefact rather than exploitable agent behaviour.
The practical test is whether the agent changed state in a way the system was supposed to prevent. A transient jailbreak, a harmless policy warning, or a one-off model refusal does not carry the same weight as unauthorised tool use, cross-boundary data access, or an action that can be repeated under realistic conditions.
Seriousness is also about blast radius. A narrow demonstration that only works in a contrived lab setup is useful for engineering, but a finding that scales across agents, tenants, connectors, or workflows changes the risk posture. The more the test depends on special casing, hidden operator help, or unrealistic timing, the less confidence teams should place in it as evidence of production impact.
What evidence separates a real exploit path from a prompt artefact?
A good red team report shows the chain, not just the symptom. That means the tester can reproduce the same outcome from the same starting conditions, identify the control that failed, and show how the agent moved from benign input to a harmful or out-of-policy result. A single screenshot of a model saying something unsafe is weaker evidence than a repeatable sequence that reaches a tool, a dataset, or an external side effect.
For agentic systems, the key question is whether the runtime stack participated. If the attack only manipulated text generation, the issue may belong to prompt handling or content filtering. If the agent accepted a bad instruction and then invoked a tool, escalated scope, or touched protected data, the issue is materially different because the system executed an unsafe decision path.
That is why teams should ask for the exact boundary crossed, the observable state change, and the compensating control that should have stopped it. Findings that can be replayed with the same permissions, same connectors, and same workflow context are far more credible than results that disappear once the prompt is changed or the demo environment is removed.
How should teams score impact without overcalling every agent failure?
The right severity judgement combines reproducibility, privilege, and consequence. A low-grade failure that only affects model tone or answer quality should not be treated like a security finding unless it creates a path to data exposure, unauthorised action, or control bypass. Conversely, a modest-looking input can be high severity if it reaches an authenticated tool, modifies records, or leaks information from a trusted workflow.
Teams should separate security impact from product embarrassment. A report can be interesting, embarrassing, or operationally annoying without being serious in the security sense. The threshold rises when the finding shows delegated authority being abused, secrets or sensitive context being exposed, or the agent making a change the owner did not intend.
Good triage also distinguishes one-off demonstration value from systemic exposure. A finding that depends on a single brittle prompt, a very specific user step, or an unusual chaining trick may still be real, but it should be scored lower than one that maps to a normal workflow and survives minor variations in phrasing, ordering, or session state.
Risk and Threat Considerations
Agentic systems create risk when a seemingly small prompt manipulation can reach privileged tools, shared context, or business workflows. The real concern is not model misbehaviour alone, but whether the finding shows a path from input to action that an attacker could repeat at scale or adapt to different targets.
Failure mechanism: The agent accepts an adversarial instruction, preserves or inherits unsafe context, and then uses legitimate runtime capabilities to cross a trust boundary, access data, or trigger an action that should have been blocked.
Impact: Teams may understate a serious issue as a prompt quirk, leaving exploitable tool use, data access, or workflow manipulation unremediated until it is abused in production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The question judges when an agent exploit crosses from prompt noise to abused authority. |
| ASI02 — Tool Misuse | Materiality depends on whether the agent was driven to invoke tools or actions unsafely. | |
| ASI06 — Memory & Context Poisoning | Prompt artefacts versus exploitable behaviour often hinge on whether poisoned context persisted into action. | |
| Recommendation — Map the finding to ASI03 when the agent used excessive or abused privilege to reach impact. Check ASI02 when a prompt led the agent to call tools, change state, or bypass intended action limits. Assess ASI06 when the finding relies on corrupted memory or retained context that altered later agent decisions. | ||
| MITRE ATT&CK | T1566 — Phishing | Prompt-led agent abuse often mirrors social engineering paths that seed malicious instructions. |
| Recommendation — Use T1566 to classify instruction-seeding techniques that deliver the initial malicious payload. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Serious findings should be corroborated by logs that prove the runtime path and resulting action. |
| Recommendation — Review audit trails to confirm the entry point, tool pivot, and impacted workflow. | ||
Practitioner Guidance
What to verify: Require evidence of the exact entry point, the tool pivot, the target data or workflow, and the observable outcome. If any link in that chain is missing, downgrade the finding until the test can be reproduced under realistic runtime conditions.
Decision rule: Treat a finding as serious when it survives prompt variation and still produces the same unauthorized effect through the agent stack. If it only works with operator prompting, hidden state, or an unrealistic demo path, classify it as lower confidence and investigate as a model or test-design issue first.
Practitioner takeaway: The severity question is less “did the model say something bad?” and more “did the agent cross a protected boundary and do something it should not have been able to do?”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org