TL;DR: AI penetration testing has become necessary because prompt injection, model inversion, memory poisoning, and agent workflow manipulation create attack paths that traditional testing misses, according to Obsidian Security. As AI agents move deeper into enterprise systems, the security problem shifts from model accuracy to governance, privilege, and lifecycle control.
NHIMG editorial — based on content published by Obsidian Security: AI Penetration Testing: Finding and Fixing AI Weaknesses
By the numbers:
- 90%+ attack vector coverage across deployed AI systems is the benchmark mature AI security programmes should target.
Questions worth separating out
Q: How should security teams implement AI penetration testing for agents and models?
A: Start with the highest-risk workflows first, especially agents that can access SaaS data, APIs, or approval paths.
Q: Why do AI agents create access risk even when the model is accurate most of the time?
A: Because the risk is not only incorrect reasoning, it is incorrect action.
Q: How can organisations tell whether their AI security model is actually working?
A: They should test whether the control stack can explain who acted, what data was touched, and what purpose the action served.
Practitioner guidance
- Embed adversarial AI test cases into release gates Add prompt injection, model extraction, and multi-turn abuse scenarios to pre-production checks so vulnerable models fail before they reach users.
- Test the permissions behind every AI agent Map the service accounts, OAuth grants, and backend API permissions an agent can use, then validate whether those rights are broader than the business task requires.
- Link test findings to risk and remediation workflows Route penetration testing results into risk dashboards, ticketing, and audit trails so remediation speed and validation status are visible to security and compliance teams.
What's in the full article
Obsidian Security's full blog post covers the operational detail this post intentionally leaves for the source:
- The specific AI penetration testing workflow used to probe models, agents, and infrastructure across development stages
- Examples of adversarial input testing, API fuzzing, and red-team scenarios that can be adapted for internal programmes
- How the vendor links penetration testing outputs to AISPM, identity threat detection, and SaaS posture management
- The article's benchmark discussion on coverage, remediation speed, and false-positive rates for mature programmes
👉 Read Obsidian Security's analysis of AI penetration testing for models, agents, and infrastructure →
AI penetration testing and agent workflow risk: are controls keeping up?
Explore further
AI penetration testing is becoming an identity problem as much as a model problem. Once an agent can act on behalf of a person, service account, or SaaS integration, the attack surface shifts to delegated access and permission scope. That means the security question is not only whether the model can be fooled, but whether the identities behind it can be coerced into unsafe action. Practitioners should treat agent testing as part of identity governance, not a separate AI-only exercise.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: What should organisations do after an AI penetration test finds a privilege or leakage issue?
A: Reduce the agent’s access to the minimum required, remove unnecessary tool permissions, and rerun the same attack scenario after remediation. Then make the finding part of the normal governance record so access reviews, incident response, and compliance evidence all reflect the control failure and the fix.
👉 Read our full editorial: AI penetration testing is becoming essential for agent security