SANS AI security guidelines expose the need for enforceable access

At a glance

What this is: This is an analysis of how SANS AI security guidance translates into enforceable access control for AI systems, with the key finding that policy only matters when it is applied at request time.

Why it matters: It matters because IAM teams must govern human users, service accounts, and AI agents through the same access controls, logging, and policy enforcement model if they want AI adoption to remain auditable and defensible.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read Pomerium's analysis of SANS critical AI security guidelines

Context

AI security is increasingly an identity problem, not just a model-security problem. Once models connect to enterprise data, tools, and workflows, the real question becomes whether each request is authenticated, authorised, logged, and bound to policy before access is granted.

That is why access control, monitoring, and governance matter together. A security programme can define AI policy on paper, but if the policy is not enforced at the point of access, the organisation still has the same audit and containment gaps it already faces with unmanaged machine identities.

For teams already wrestling with NHI sprawl, this is a familiar pattern. The challenge is extending zero trust, least privilege, and lifecycle discipline to AI-linked access without treating every tool-using system as if it were a human user.

Key questions

Q: How should security teams enforce access controls for AI systems?

A: Security teams should enforce access controls at the point of request, not after the model has already responded. That means authenticating the caller, resolving policy in real time, and logging the decision for auditability. The same model should cover humans, service accounts, and agents so AI access does not become a separate governance island.

Q: Why do AI workflows create the same governance problems as NHIs?

A: AI workflows often depend on service credentials, connected data sources, and delegated tool access, which makes them behave like non-human identities from a governance perspective. If those access paths are not inventoried, scoped, and logged, the organisation loses visibility and control. The risk is not the model alone. It is the identity path around it.

Q: What should organisations do when RAG systems can reach sensitive data?

A: Organisations should treat retrieval permissions as a security boundary and separate them from general application access. Read scopes should be narrow, write access should be tightly controlled, and every retrieval path should be auditable. If augmentation data can influence outputs, it needs the same governance attention as other sensitive enterprise data.

Q: Who should own governance when humans, services, and AI agents all access the same resources?

A: Ownership should sit with the identity and security functions that already govern access policy, logging, and lifecycle controls. The key is to maintain one control plane for identity decisions, even if multiple actor types use it. That avoids duplicated rules, inconsistent audit trails, and gaps between AI operations and existing IAM programmes.

Technical breakdown

Point-of-access enforcement for AI requests

AI access becomes governable when policy is evaluated at the moment a request is made, not after the model has already acted. In practice, this means the system must authenticate the calling identity, resolve the applicable policy, and authorise the action before data is returned or a tool is invoked. That pattern matters for MCP and A2A flows because the request path often combines human context, service credentials, and agent-driven execution. Without a request-time decision, you are left with logs, not control.

Practical implication: move AI access decisions into the enforcement layer so every request is checked before execution.

Why RAG and augmentation data need identity controls

Retrieval-augmented generation depends on data that can directly shape model output, which makes the retrieval path part of the security boundary. If a vector store, augmentation database, or connected data source is over-permissioned, tampered with, or poorly logged, the model can be steered toward misleading responses without the core model itself being compromised. That is why least privilege, write separation, and auditable change history matter here. The protection target is not only the model. It is the data path that informs the model.

Practical implication: treat augmentation data as sensitive access-controlled input, not as a passive content store.

Monitoring, drift, and explainability in AI operations

Effective monitoring for AI security is broader than simple uptime or model accuracy. Security teams need to know which identity requested the action, what policy allowed it, what data was touched, and whether the behaviour is drifting away from intended use. That requires continuous logging, anomaly detection, and traceability for both authorised and suspicious activity. In governance terms, monitoring closes the gap between policy intent and runtime behaviour, which is where most AI control failures will show up first.

Practical implication: align logging and anomaly detection to identity, policy, and data access so drift becomes visible early.

NHI Mgmt Group analysis

AI security becomes enforceable only when identity policy moves into the request path. SANS is right to focus on access controls, monitoring, and GRC, but the operational issue is simpler: if the authorisation decision happens after the request, the control already failed. That is the same lesson NHI teams learned with service accounts and API keys. The implication is that AI governance is not a separate discipline from identity governance, it is an enforcement problem at runtime.

Point-in-time governance was designed for systems that stay still long enough to review. That assumption fails when AI requests are dynamic, context-dependent, and mediated by service or agent identities that can call tools mid-session. The implication is that review cadences alone cannot prove control over AI behaviour, because the relevant decision may already be gone by the time an auditor looks.

RAG introduces an identity blast radius that most model-centric controls do not measure. Once retrieval stores, vector databases, and connected data sources can shape model output, over-permissioned access becomes a model integrity issue, not just a data access issue. The implication is that practitioners must govern the data path with the same seriousness they apply to privileged identity paths.

Shadow AI is often a visibility problem before it is a model problem. The article correctly notes that organisations cannot credibly assume AI will not be used. Unauthorised usage usually appears first as unmanaged access, unclear ownership, and missing audit trails, which are governance failures rather than technical novelty. The implication is that AI adoption must be measured as an identity inventory and policy enforcement problem.

AI governance boards without enforcement are reporting structures, not security controls. The article points to model registries, AIBOMs, and formal oversight, but those artefacts only matter if they connect to access decisions and audit evidence. The implication is that practitioners should measure whether governance outputs change runtime authorisation, not whether the paperwork exists.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For teams building stronger lifecycle controls, the Ultimate Guide to NHIs is the clearest next step for rotation, offboarding, and visibility planning.

What this signals

Identity enforcement will become the dividing line between credible AI governance and paper governance. Teams that cannot prove request-time authorisation for AI access will struggle to demonstrate control when regulators, auditors, or incident responders ask who approved what. The operational benchmark is not whether AI exists in the environment. It is whether the identity path into AI is visible and enforceable.

With only 5.7% of organisations reporting full visibility into their service accounts, according to our Ultimate Guide to NHIs, the same visibility gap is likely to surface quickly in AI integrations unless teams inventory them as identity assets.

RAG governance will force security teams to treat data stores like privileged access points. If retrieval layers can shape model behaviour, then unscoped access to those stores becomes a control problem, not a content problem. That shifts programme priorities toward tighter entitlement review, stronger logging, and a clearer link between data governance and identity governance.

For practitioners

• Bind AI access to authenticated identities Require every AI request to present a verifiable identity and apply policy before data retrieval or tool execution occurs. Include human, service, and agent identities in the same enforcement path so the control model does not fragment by actor type.
• Separate retrieval permissions from model permissions Limit write access to augmentation data, apply read scopes narrowly, and log every change to connected data sources. A model should not inherit broad database access simply because it can query the store.
• Make policy decisions auditable at runtime Capture which identity requested the action, what policy allowed or denied it, and which resource was touched. Use those records to support investigations, compliance evidence, and drift detection across AI workflows.
• Inventory unmanaged AI usage as shadow identity exposure Map where employees are already using internal AI tools, identify who owns each integration, and classify any undocumented connection as an identity governance issue. That gives you a practical starting point for bringing hidden access into scope.

Key takeaways

• AI security breaks down when policy is advisory instead of enforced at runtime.
• The scale of the identity problem is already visible in NHI environments, where excessive privilege and weak visibility remain common.
• Teams should govern AI access, augmentation data, and audit trails as one identity problem rather than three separate ones.

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: Undiscovered or unmanaged AI use inside an organisation, including tools, integrations, and agent-like workflows that security teams have not formally approved. The governance issue is usually hidden access and missing ownership, which means the first control requirement is inventory, not optimisation.

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 responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Pomerium: Turning SANS Critical AI Security Guidelines Into Enforceable Agentic Controls. Read the original.