Overview
AI vulnerability scope cannot be set by attack labels alone. In a selected study of 264 AI vendors, 36% had no public vulnerability-reporting channel and only 18% explicitly mentioned AI; these figures describe public-policy visibility, not private practice or remediation quality. The series distinguishes surprising behavior, security vulnerabilities, safety concerns, and incidents by linking an observed condition to a security property or material harm, its mechanism, context, evidence, and response route. It then applies that test to policy design, coordinated disclosure, remediation, deployment, and ownership across model providers, application vendors, deployers, and coordinators. The proposed boundary remains case-specific: sufficiently evidenced impact and an accountable route matter more than a category name, while important non-bounty concerns still need meaningful alternate handling.
Learning outcomes
- A reproducible or sufficiently evidenced condition—not surprising output alone—must connect AI behavior to a security property or material, unauthorized harm.
- Prompt injection, jailbreaking, hallucination, and harmful output require context; their labels do not establish impact, eligibility, or severity.
- Public-policy percentages show how vendors describe scope, not which risks are most severe or which policies produce better remediation.
- A usable policy makes testing permission, evidence, exclusions, safe harbor, routes, and ownership visible before a report arrives.
- Eligibility is distinct from patchability: mitigation, monitoring, coordination, and deployment can reduce risk when no direct model fix exists.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
How does an AI behavior become a vulnerability?
It becomes a vulnerability when a reproducible or sufficiently evidenced condition in an AI-enabled system lets an attacker or unauthorized party violate a security property or cause material, context-specific harm beyond their intended authority. The mechanism, preconditions, affected asset, and limits should remain explicit.
Are prompt injection and jailbreaking automatically in scope?
No. They are mechanisms, not complete impact judgments; scope depends on whether the behavior crosses an authorization, confidentiality, integrity, or other material boundary and on the evidence and context.
What do public AI disclosure policies reveal?
In the study's selected sample of 264 AI vendors, 36% had no public reporting or disclosure channel and 18% explicitly mentioned AI. Those figures describe what outsiders can see, not private practice, remediation quality, or the whole industry.
Who should handle an AI vulnerability that crosses organizational boundaries?
The report should reach the party that can reduce the immediate risk, while the receiving vendor preserves and forwards evidence when another party controls the underlying model or service. Coordinators can synchronize validation, remediation, deployment, and disclosure.
What should happen to an AI concern that is not bounty-eligible?
It should be routed to a named safety, abuse, model-quality, incident, or provider process with evidence expectations and escalation, rather than silently rejected. A security finding can still merit mitigation or coordination when no conventional patch exists.