Notifications
Clear all
Topic starter
15/08/2026 6:12 pm
TL;DR: AI security testing now has to cover prompt injection, model inversion, memory poisoning, and tool misuse because traditional penetration testing misses the attack surface created by LLMs and autonomous agents, according to Obsidian Security. For IAM and NHI practitioners, the key issue is not just model safety but governance of agent access, delegated tools, and the controls that bound their runtime behaviour.
NHIMG editorial — based on content published by Obsidian Security: AI Security Testing, protecting models and agents from adversarial exploits
By the numbers:
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams implement AI evaluation in production workflows?
A: Security teams should treat AI evaluation as a continuous control, not a pre-launch checklist.
Q: Why do AI systems create identity and access risk beyond traditional AppSec?
A: Because AI systems often act through delegated access.
Q: What do security teams get wrong about prompt injection defence?
A: They often assume better blocklists will solve the problem, but obfuscation simply changes the shape of the payload.
Practitioner guidance
- Map every AI agent to its real identity surface Inventory the service accounts, API keys, tokens, and delegated roles each agent can use.
- Add adversarial tests to MLOps release gates Run prompt injection, memory poisoning, and tool misuse tests before production promotion, then repeat them after any connector, prompt, or permission change.
- Tie security findings to risk ownership and remediation Feed AI test results into risk registers, incident workflows, and remediation tracking so findings do not remain isolated in security tooling.
What's in the full article
Obsidian Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step AI security testing workflows for development, staging, and production gates
- Tool category comparisons across open source, commercial, and cloud-native AI testing options
- Example red-team test cases for prompt injection, memory exploitation, and tool misuse
- Integration patterns for CI/CD and MLOps pipelines, including governance and audit handoff
👉 Read Obsidian Security's analysis of AI security testing for models and agents →
AI security testing for agents and models: where do controls fail?
Explore further
15/08/2026 6:19 pm
AI security testing is now an access control problem, not only a model safety problem. Once an agent can call tools, read memory, or access data stores, the test surface becomes an identity surface. That means security teams must judge whether an exploit path can expand rights, not just whether the model behaves incorrectly. The practical conclusion is that AI security testing belongs in governance discussions alongside IAM, PAM, and NHI lifecycle controls.
A question worth separating out:
Q: Who should own AI security testing findings when agents are connected to business systems?
A: Ownership should sit with the team that can actually change the exposed access path, usually a combination of MLOps, security, and the system owner for the connected tool or data source. If no one owns the agent's permissions, the organisation will record findings without shrinking blast radius or closing the privilege gap.
👉 Read our full editorial: AI security testing is becoming a core control for models and agents
