9 minmedium
The OWASP Top 10 for LLM Applications 2026: From Model Risks to Agentic Security | Akamai
The OWASP Top 10 for LLM Applications 2026 refines and reprioritizes existing AI security risks to reflect the industry shift toward agentic AI systems. LLM03 (Excessive Agency) and LLM08 (Hidden Context Exposure) receive greater prominence as AI models increasingly interact with enterprise systems, invoke tools, and execute business workflows. The article emphasizes AI reconnaissance as a critical early-stage attack behavior where attackers map application capabilities, tool schemas, and permissions before launching targeted prompt injection or unauthorized tool exploitation.
Conf:medium
Detection / Hunteropenrouter
What Happened
The OWASP organization updated its Top 10 security risks list for AI applications for 2026. The updated list keeps most existing risks but raises the priority of threats related to AI systems that can take actions, not just generate text. Modern AI applications can now access enterprise data, call external tools, and execute business workflows, which creates a larger attack surface. The article highlights that attackers often start by quietly probing an AI assistant to learn its capabilities, tools, and permissions before launching a targeted attack. Organizations building or using AI applications should consider runtime security controls that monitor both user inputs and AI responses to detect and block suspicious activity early.
Key Takeaways
- OWASP Top 10 for LLM Applications 2026 preserves core threats like Prompt Injection and Sensitive Information Disclosure while reprioritizing based on real-world incident data and production deployment trends.
- LLM03 (Excessive Agency) and LLM08 (Hidden Context Exposure) rose in prominence as AI models increasingly interact with enterprise systems, invoke tools via APIs, and execute multistep workflows.
- LLM08 formalizes AI reconnaissance as a risk category, covering disclosure of tool schemas, behavioral logic, permissions, roles, refusal mechanisms, and workflow rules that enable targeted attacks.
- Attackers increasingly probe AI assistants to map capabilities, tools, permissions, and guardrail boundaries before crafting application-specific exploits, making early detection of probing behavior critical.
- Akamai Firewall for AI provides inline runtime protection evaluating both user prompts and model responses, with a planned reconnaissance detector for capability discovery, tool enumeration, and workflow logic reconstruction.
Affected Systems
- LLM-based applications and AI assistants
- Agentic AI systems with tool integration and API access
- Enterprise AI workflows with access to sensitive data and business systems
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Reconnaissance: Attacker probes AI assistant with seemingly harmless questions to discover capabilities, tools, integrations, permissions, and guardrail boundaries
- Context Discovery: Attacker extracts hidden context including tool schemas, workflow logic, role definitions, and refusal mechanisms from model responses
- Exploit Development: Attacker uses gathered intelligence to craft targeted prompt injection or malicious tool requests that bypass application-specific controls
- Execution: Attacker exploits authorized tools, bypasses workflows, or triggers unauthorized actions leveraging the AI system's permissions and autonomy
- Impact: Sensitive data exfiltration, unauthorized record updates, or execution of malicious business workflows via the AI system's connected integrations
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No detection rules or queries are provided in the article. Akamai mentions a planned reconnaissance detector feature for Firewall for AI but does not share detection logic or signatures.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Low | The threats described involve AI application-layer interactions between users, models, and tools. EDR products typically do not inspect LLM prompt content, model responses, or API calls to AI platforms. EDR may provide visibility into process-level activity if AI tools invoke local executables, but the core attack surface is at the application layer. |
| Network Visibility | Medium | Network-level monitoring could capture API calls to AI model providers and tool integrations. If AI application traffic flows through an API gateway or reverse proxy, request and response payloads could be inspected. However, encrypted connections to AI providers may limit visibility without inline inspection capabilities. |
| Detection Difficulty | Hard | Distinguishing legitimate exploratory questions from reconnaissance probing is inherently difficult. Individual probing requests may appear harmless. Detection requires analyzing patterns across multiple interactions and correlating questions about capabilities, tools, permissions, and workflow logic. Application-specific context is needed to determine what constitutes suspicious probing versus normal user exploration. |
Required Log Sources
- AI application interaction logs (user prompts and model responses)
- API gateway logs for AI model provider traffic
- Tool invocation audit logs from AI application platform
- Application-level access control and authorization logs for AI workflows
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for users or sessions that submit a high volume of questions about AI assistant capabilities, available tools, or system permissions within a short time window, as this pattern may indicate reconnaissance activity preceding a targeted attack. | AI application interaction logs containing user prompts and model responses, session identifiers, and timestamps | Reconnaissance | High — legitimate users exploring an AI assistant's capabilities may exhibit similar questioning patterns, especially new users or administrators evaluating functionality. |
| Consider hunting for model responses that disclose tool schemas, function definitions, permission models, or internal workflow logic to users who did not explicitly request this information through authorized administrative interfaces. | AI model response logs with content analysis for tool schema patterns, API endpoint references, or internal configuration details | Hidden Context Exposure | Medium — some legitimate interactions may surface tool information as part of normal AI assistant behavior, especially in developer-facing or documentation contexts. |
| Consider hunting for sessions where reconnaissance-style questioning is followed by prompt injection attempts or unusual tool invocation requests, as this sequence may indicate a multistage attack progressing from probing to exploitation. | Correlated AI interaction logs with session timelines showing question patterns followed by tool calls or prompt injections | Execution | Medium — power users may naturally progress from exploratory questions to advanced tool usage in legitimate workflows. |
| Consider hunting for AI tool invocations that access sensitive data stores or trigger high-impact workflows without corresponding user authorization or role validation, as this may indicate excessive agency exploitation. | Tool invocation audit logs, access control logs, and AI workflow execution logs | Excessive Agency | Low to Medium — unauthorized tool access should be relatively distinguishable from authorized usage if role-based access controls are properly logged. |
Control Gaps
- Traditional WAF and network security controls do not inspect AI prompt content or model responses for injection attempts or reconnaissance patterns.
- Standard DLP solutions may not capture sensitive data exposure through AI model responses if traffic is not routed through inspection points.
- EDR products lack visibility into AI application-layer interactions between users, models, and connected tools.
- API security gateways may not enforce granular authorization on AI-initiated tool calls or workflow executions.
- Identity and access management systems may not account for AI systems acting as intermediaries with their own permissions and autonomy.
Key Behavioral Indicators
- Rapid sequential questioning patterns targeting AI assistant capabilities, tool availability, and permission boundaries within a single session
- Model responses containing tool schemas, function signatures, or API endpoint details in non-administrative contexts
- Prompt inputs containing encoded or obfuscated instructions designed to bypass guardrails or extract hidden context
- AI-initiated tool calls to sensitive data stores or high-impact workflow endpoints without corresponding user authorization events
- Sessions exhibiting a progression from exploratory questions to tool invocation attempts or prompt injection patterns
False Positive Assessment
High — distinguishing legitimate user exploration of AI assistant capabilities from reconnaissance probing is inherently difficult. Individual probing questions appear harmless, and power users may naturally progress from exploratory questions to advanced tool usage. Detection requires pattern analysis across multiple interactions and application-specific context to determine what constitutes suspicious behavior.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider auditing deployed AI applications for excessive permissions, tool access scope, and workflow autonomy to identify systems where LLM03 (Excessive Agency) risk is highest.
- Consider evaluating whether AI application traffic is routed through inspection points that can log and analyze user prompts and model responses for reconnaissance and injection patterns.
- If your AI platform supports it, consider implementing rate limiting on user interactions to slow down reconnaissance probing and provide more time for detection.
Infrastructure Hardening
- Consider implementing network segmentation between AI application components and sensitive enterprise data stores to limit the blast radius of excessive agency exploitation.
- Evaluate whether AI-initiated tool calls and API invocations are subject to the same authorization controls as direct user-initiated requests.
- Consider deploying inline AI security controls that inspect both user prompts and model responses at runtime, if available for your AI platform.
- Where supported by your architecture, consider implementing least-privilege permission models for AI systems so that compromised models have minimal access to sensitive data and workflows.
User Protection
- Consider evaluating whether AI assistants expose tool schemas, function definitions, or internal configuration details in responses to non-administrative users.
- If your AI platform supports it, consider configuring guardrails that restrict disclosure of system prompts, internal instructions, and workflow logic to end users.
- Consider implementing session monitoring for AI applications that handle sensitive data or have access to high-impact business workflows.
Security Awareness
- Consider incorporating AI interaction security into existing security awareness programs, covering risks of prompt injection and the importance of not sharing sensitive information with AI assistants.
- Consider training developers building AI applications on the OWASP Top 10 for LLM Applications 2026 risks, particularly LLM03 (Excessive Agency) and LLM08 (Hidden Context Exposure).
- Consider establishing guidelines for employees on what types of information are appropriate to share with AI assistants and what actions AI systems are authorized to take on their behalf.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping2 techniques
Tactic
