Notifications
Clear all
Topic starter
02/08/2026 11:46 am
TL;DR: OWASP’s Q2 2026 update splits agentic AI, LLM and GenAI applications, and red teaming into separate landscapes, reflecting three different attack surfaces and control requirements, according to Straikerai. The distinction matters because agentic systems introduce runtime tool use, cross-session memory, and continuous decision-making that conventional model guardrails do not govern.
NHIMG editorial — based on content published by Straikerai: Three Landscapes, One Security Shift: What OWASP's Q2 2026 Update Is Really Saying
Questions worth separating out
Q: How should security teams govern AI agents that can choose tools at runtime?
A: Security teams should govern runtime agent choice as an access event, not as a simple application action.
Q: Why do agentic AI systems require different controls from LLM applications?
A: Agentic systems can act, not just respond.
Q: What breaks when red teaming is only done before release?
A: A pre-release-only approach misses the changes that happen after deployment, including tool updates, new integrations, memory changes, and behaviour drift.
Practitioner guidance
- Inventory agent reach and delegated scope Document every agent, tool, MCP server, and downstream system the workflow can touch.
- Separate LLM app controls from agentic controls Keep prompt and output guardrails for conversational use cases, but add runtime controls for tool invocation, context handoff, and behavioural drift where agents can act across systems.
- Move red teaming into continuous operations Run adversarial testing after deployment as well as before release, especially where tools, memory, or multi-agent delegation can change without a code change.
What's in the full article
Straikerai's full blog post covers the operational detail this post intentionally leaves for the source:
- Straikerai's breakdown of the three OWASP landscapes and how each maps to a different stage of the AI lifecycle
- Its discussion of discovery, adversarial simulation, and runtime enforcement across agentic workflows
- The article's explanation of why continuous red teaming has to follow changes in tools, memory, and downstream agents
- Straikerai's product-specific description of how its own controls map to the agentic security lifecycle
👉 Read Straikerai's analysis of OWASP's Q2 2026 agentic AI and red teaming landscapes →
Agentic AI and LLM security landscapes: what changed for teams?
Explore further
02/08/2026 12:57 pm
Agentic AI security is now a governance category, not a feature extension. OWASP’s separation of agentic AI from LLM security confirms that runtime agency changes the problem space. Once systems can call tools and coordinate actions, the core issue becomes delegated authority, not prompt quality. For identity programmes, that means agent behaviour has to be governed like access, with explicit scope and accountability.
A question worth separating out:
Q: How do IAM and NHI teams fit into AI gateway governance?
A: They should treat AI connectivity as part of the same control problem as workload identity and secrets management. The gateway becomes the enforcement point for access, audit, and policy, while IAM and NHI teams define the rules for who or what may call the models. Shared governance prevents AI sprawl from creating a second identity estate.
👉 Read our full editorial: OWASP’s Q2 2026 landscapes split agentic AI from LLM security
