SANS AI security guidelines expose the need for enforceable access

At a glance

What this is: This is Pomerium's analysis of SANS Critical AI Security Guidelines, with the core finding that AI security guidance only matters when access, monitoring, and governance are enforced where requests are made.

Why it matters: IAM, PAM, and NHI teams need to treat AI access as an authorization problem across humans, services, and agents, because policy without point-of-access enforcement leaves Shadow AI and model tampering unchecked.

Context

The security gap in this article is straightforward: AI governance frameworks can describe what should happen, but they do not enforce what actually happens at the moment an identity requests model access or data access. That makes identity controls central to AI security, especially where humans, services, APIs, and agents all need to interact with the same system.

Pomerium's piece frames SANS Critical AI Security Guidelines through access controls, monitoring, and GRC, but the underlying issue is broader than one vendor's approach. The article argues that AI systems become governable only when authorization, logging, and policy checks sit in the request path rather than in an external policy document.

That is a familiar failure mode for identity teams. When AI usage is dispersed across internal tools, retrieval layers, and connected systems, the programme must govern who can act, what can be touched, and how those actions are audited.

Key questions

Q: What breaks when AI security is measured but not enforced?

A: When measurement is not tied to enforcement, organisations get visibility without risk reduction. Reports may identify overexposed data or excessive permissions, but nothing changes until those findings are translated into access changes, control owners, and deadlines. That gap is where AI maturity programmes usually stall.

Q: Why do AI agents need continuous authorization instead of one-time login checks?

A: AI agents can change behavior quickly, so a one-time authentication event does not prove the next action is still appropriate. Continuous authorization matters because the system must reassess context, intent, and policy at each tool invocation. Without that, an agent can keep operating after its original trust boundary has become stale or unsafe.

Q: What are the signs that AI governance is failing in the enterprise?

A: Common warning signs include rapid growth in AI use without matching policy coverage, sensitive files being copied into personal accounts, and a large share of AI apps carrying high or critical risk. Another indicator is weak visibility into who is using which tools and what data they are sending. If teams cannot answer those questions, governance is not working as intended.

Q: How should teams implement RAG in production AI systems?

A: Teams should treat RAG as an architectural pipeline, not a toggle. Start with clear source selection, careful chunking, and embeddings tuned to the query domain. Add retrieval limits, prompt structure, and evaluation loops so the system stays grounded as data changes. The goal is to improve answer quality without creating latency, cost, or noise that weakens user trust.

Technical breakdown

Why point-of-access enforcement matters for AI requests

AI access control is not just about authenticating a user or workload once. In this context, every request to a model, connected tool, or retrieval layer can change risk because the requester may be human, service, or agent, and the action may expose sensitive data or modify model behaviour. That is why least privilege and Zero Trust are relevant here: policy has to be applied at request time, not inferred from system design. The practical difference is that authorization must accompany the action path, including connected devices, APIs, and applications.

Practical implication: enforce per-request authorization for AI-connected resources instead of relying on standing access.

How retrieval-augmented generation changes data protection

Retrieval-augmented generation, or RAG, depends on augmentation data that can directly influence model outputs. If that data is altered, poisoned, or broadly exposed, the model can produce misleading or unsafe responses even when the model itself is unchanged. This moves the security problem from the model alone to the data feeding it. In governance terms, the control boundary expands to the vector store, its read and write permissions, and the auditability of every change. A simple allow or deny model is not enough when data integrity determines output trust.

Practical implication: treat augmentation data as sensitive governed input, not as ordinary application content.

Why logging and anomaly detection are part of AI authorization

Monitoring in AI systems is not a passive observability exercise. The article's emphasis on logging, anomaly detection, and drift monitoring reflects a need to know which identity requested an action, which policy allowed it, and whether the behaviour still matches intent over time. That is especially important when internal LLM applications touch sensitive data, because governance failures often show up as unexpected access patterns rather than as direct compromise. This is where AI access control and AI auditability converge: without traceable decisions, compliance and investigation both fail.

Practical implication: log the requesting identity, the policy decision, and the permitted action for every AI interaction.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI governance breaks when policy sits outside the request path. The article correctly identifies the gap between written governance and enforceable control. Access policy only matters when it is evaluated where the human, service, or agent requests the action, because that is the point where privilege becomes real. The practitioner lesson is that AI security needs enforcement, not just standards language.

Point-in-time authorization is the new control plane for AI access. SANS' guidance on least privilege and Zero Trust reflects a wider shift in identity architecture. AI systems are not governed by one-time onboarding decisions, because each request can change the blast radius of sensitive data or tool access. The implication is that identity teams must design for decision-time control rather than assume static trust boundaries.

RAG creates an identity-adjacent data trust problem, not just a model problem. Once augmentation data can influence outputs, access to that data becomes part of the security perimeter. The article shows why read and write permissions, change logging, and explainability have to be tied together. Practitioners should treat the retrieval layer as governed evidence, not a neutral cache.

Shadow AI is a governance failure before it is a technology failure. The article's warning that enterprises cannot simply ban AI use is directionally correct. Unmanaged adoption grows when teams lack enforceable policies that match how employees already work. The governance task is to make approved AI use visible, bounded, and auditable enough that unmanaged use loses its appeal.

Model registries and AI bills of materials need access governance, not just inventory discipline. The article highlights traceability and rollback, but those artefacts also become sensitive control objects. If the registry itself is not governed, then provenance data, dependencies, and rollback paths can become another exposure surface. The implication for identity teams is to secure the metadata around AI systems with the same seriousness as the systems themselves.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.

What this signals

Point-of-access enforcement: AI governance will keep failing wherever teams separate policy from the request path. The control question is no longer whether an organisation has an AI policy, but whether that policy is evaluated for every model invocation, retrieval query, and connected tool action.

For identity teams, the practical shift is to treat human, service, and agent requests as first-class authorization events. That means your AI programme needs the same discipline you would apply to privileged access, with explicit decision points, traceable logs, and scope-aware policy enforcement.

The article also reinforces a broader programme truth: Shadow AI grows fastest where governance is visible but unenforceable. If you cannot prove who can act, what they can touch, and why the request was allowed, then AI security is still aspirational.

For practitioners

• Move AI authorization to the request path Require a policy decision for each human, service, or agent request before the model, API, or retrieval layer returns sensitive context.
• Separate model access from augmentation data access Apply distinct permissions and audit trails to model invocation, vector database reads, and vector database writes so data tampering cannot hide behind normal AI use.
• Log identity, policy, and outcome for every AI action Capture who requested the action, which rule allowed or denied it, and what the system returned so reviews can reconstruct AI behaviour after the fact.
• Inventory Shadow AI at the access boundary Map where internal LLM applications, connected tools, and agents already have access, then reconcile those paths against approved policy and ownership.
• Secure AI governance metadata as a control object Treat model registries and AI bills of materials as sensitive records, because provenance, dependency, and rollback information can expand the attack surface.

Key takeaways

• AI security guidance only becomes real when access decisions are enforced at the moment a request is made, not after the fact.
• RAG and AI governance expand the identity boundary to include retrieval data, logging, and policy traceability.
• Identity teams should focus on request-time authorization, auditable monitoring, and controlled access to AI governance metadata.

Key terms

• Point-of-access enforcement: A control pattern where identity policy is applied at the moment a request is made, before any resource is returned or action is executed. In AI systems, this is the difference between governable access and post-hoc logging, especially when humans, services, and agents can all trigger the same workflow.
• Augmentation data: The external or enterprise data that a model retrieves to shape its response, often through RAG or connected data stores. Because this data can change model output without changing model code, it must be treated as a protected input path with explicit access controls, logging, and change accountability.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• AI bill of materials: An inventory of the components used by an AI development environment, including models, plugins, hooks, skills, and agent integrations. It gives security teams visibility into what is operating in the stack so they can assess trust, dependency risk, and governance coverage.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.