Notifications
Clear all
Topic starter
12/06/2026 12:09 am
TL;DR: OWASP’s updated 2025 Top 10 for LLM applications elevates prompt injection, sensitive information disclosure, supply chain exposure, and excessive agency as the most relevant risks for copilots, chatbots, and agents, according to Pomerium. Identity-aware, policy-backed access is now the control layer that determines whether prompt-driven systems can reach data or tools safely.
NHIMG editorial — based on content published by Pomerium: The OWASP Top 10 for LLMs and How to Defend Against Them
By the numbers:
- The OWASP Top 10 for LLMs names 10 distinct risk categories, including prompt injection, sensitive information disclosure, and excessive agency.
- OWASP published the first LLM-specific risk list in 2023, giving teams a baseline for prompt-driven application threats.
Questions worth separating out
Q: How should security teams control prompt injection in LLM applications?
A: Security teams should control prompt injection by restricting what the model can reach, not only what it can say.
Q: Why does sensitive information disclosure become an identity problem in LLM systems?
A: Sensitive information disclosure becomes an identity problem because the model can only expose what its connected accounts and routes allow it to access.
Q: What do security teams get wrong about LLM access control?
A: Many teams focus on the model output and miss the privilege scope behind the workflow.
Practitioner guidance
- Constrain every LLM route with explicit authorization Map each prompt-driven workflow to the exact data sources, APIs, and tools it may reach, then block all other paths at the access layer.
- Replace static secrets with short-lived, identity-bound access Use ephemeral credentials for model-connected services and avoid long-lived API keys in copilots, agents, and retrieval pipelines.
- Separate read, write, and action privileges in AI workflows Assign different permissions to retrieval, summarization, and execution steps so the model cannot move from reading content to changing state without a distinct control decision.
What's in the full article
Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:
- Identity-aware proxy setup for securing AI routes and internal applications
- Per-route policy examples for restricting tools and data sources by user or group
- Logging and monitoring details for denied attempts that may indicate prompt injection
- Step-by-step guidance for connecting an identity provider such as Okta or Azure AD
👉 Read Pomerium's analysis of the OWASP Top 10 for LLM security risks →
OWASP LLM risks: what IAM teams need to control now?
Explore further
12/06/2026 9:12 am
Identity-aware access is the control plane for LLM security, not a secondary safeguard. The article correctly frames prompt injection and sensitive information disclosure as the top two operational risks, but the governance lesson is broader: an LLM is only as safe as the routes it can reach. Once a model can query tools or internal systems, identity policy becomes the boundary that matters most. Practitioners should treat every LLM connection as an access decision, not a prompt-handling problem.
A few things that frame the scale:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: How do Zero Trust controls help with agentic and LLM risk?
A: Zero Trust helps by requiring continuous verification at the point where the model reaches a resource. Instead of trusting the application because the prompt was accepted, it evaluates each request against identity, policy, and destination. That approach is especially useful when output can drive tool use, because it prevents implicit trust from turning into unauthorized action.
👉 Read our full editorial: OWASP top 10 for LLMs exposes the access gap in AI security
