The Vilkas Wire
NIST AI RMF Meets Identity: Building AI Governance on Your Access Controls
Jun 23, 2026 · By Ben Rollin
Many discussions about AI governance start off on the wrong foot. They focus on use cases, productivity, model performance, and how fast teams can launch copilots, agents, and automation. But the real question that defines AI risk often gets overlooked: what can your AI systems access as soon as they are activated?
This matters beyond the technical side, and the business stakes are becoming clearer. Regulatory enforcement for mishandled AI data is no longer theoretical. The EU AI Act will begin enforcement on August 2, 2026, with GDPR and US state laws following. When AI accelerates a breach, recovery costs rise quickly because the speed that makes AI useful for data discovery also helps an attacker who has taken over a privileged account. The operational impact is significant when an internal audit or regulator finds issues after a broad rollout. This can lead to paused AI programs, remediation sprints, and months of lost productivity while governance is retrofitted. Getting governance right before deployment is less expensive in every way than fixing it after.
AI governance is now a regulatory, legal, and operational requirement, and in 2026, deferring the conversation on the framework is no longer viable. Emerging state-level AI laws, shifting GDPR expectations, and sharply increasing scrutiny of how data is used and how models behave are pushing organizations to demonstrate actual control over their AI environments, not just a policy document outlining what they're trying to do.
Security and leadership teams must know what data their AI systems access, where that data is stored, how it moves between systems, and who or what can reach it. Many organizations still lack this visibility, which creates both security and compliance risks.
The AI Governance Gap
The gap between adopting AI and putting governance in place is widening. Companies are adding AI tools to their workflows very quickly, but few have set up proper governance or risk management to support this growth.
The exposure is concrete since AI systems process sensitive data, connect to external services, and produce outputs that create privacy and compliance concerns. If AI governance is an afterthought, it will likely lead to data leakage, unintended sharing with third parties, AI decisions nobody can explain to an auditor, and limited ability to respond when regulators ask.
A useful exercise for any CISO: Do you have an inventory of AI systems? Can you show a reviewer exactly which identities and datasets each Copilot or AI agent deployment can reach? If the answer to either is no, you have a governance gap, not a roadmap. In many environments we assess, the only "AI governance" in place is an acceptable use policy and a few blocked domains, which users often bypass. That's not defensible when AI can query regulated data sources and act on behalf of privileged identities.
As Dark Reading's coverage of AI governance in cyber operations points out, AI is moving from a supporting tool to an active participant in cyber operations, interacting directly with systems and making decisions that traditional security models were never built to handle. Once AI is an operator in your environment, the old model of separating users from service accounts in your IAM approach is no longer sufficient. AI identities need to be in scope, too.
AI Governance Is Really an Identity Problem
At its foundation, AI governance is fundamentally an identity and access problem. Traditional security models were built around human users and service accounts, but AI agents and copilots don't fit cleanly into either category. They span multiple systems, act on a user's behalf, and make decisions based on dynamic inputs, behaving like powerful, semi-autonomous identities rather than passive applications.
Effective governance requires treating AI systems as first-class identities in your environment, meaning defined credentials, least privilege access, and logging and monitoring of everything they do. Without that identity-centric approach, organizations lose visibility into what AI is doing and what data it can actually reach.
We see this regularly in practice. A Copilot instance provisioned against a single over-privileged M365 account with access to every SharePoint site becomes a blast radius problem that AI makes far easier to exploit than a person browsing SharePoint manually could, going beyond a mere misconfiguration. Teams focused on Active Directory and Entra ID should extend those identity governance practices to AI agents, building on work they may already be doing.
AI Risk and Blast Radius
AI usually speeds up existing risks instead of creating new ones. AI systems inherit whatever permissions already exist across Microsoft 365, SaaS applications, and internal systems, including over-permissioned users, nested group memberships, stale access, and data repositories that were never properly scoped.
Before AI, much of that exposure remained hidden because finding sensitive data took time and required knowing where to look. AI makes this faster and easier. If access exists, AI can surface it quickly through a natural-language query or automated workflow, without the manual effort that previously kept most exposure hidden.
Here's a concrete example we've seen: a service account with write access to an internal data warehouse, originally provisioned for a legacy integration, was inherited by an AI agent during a new workflow deployment. Nobody reviewed the account's permissions before connecting it. The agent began querying and aggregating data across systems no person had been actively checking. This is one of many examples of the blast radius problem in practice, which may not appear until something goes wrong.
Blast radius, in the identity sense, refers to everything an identity can reach, directly or indirectly, based on effective permissions. Nested groups, inherited access, and stale ACLs all contribute to a blast radius that is often much larger than the org chart or documentation suggests. When AI is added, that blast radius becomes immediately more dangerous because discovery, aggregation, and correlation happen in seconds rather than hours.
The table below shows how familiar identity issues change when AI enters the picture:
| Existing Issue | What Changes When AI Is Added |
|---|---|
| Over-privileged service accounts | AI can query and combine all accessible data at once |
| Nested group sprawl | AI inherits deep, difficult-to-discover access paths instantly |
| Excessive SharePoint and Teams sharing | AI can search and summarize all exposed content |
| Shadow SaaS and OAuth grants | AI agents call external APIs with permissions nobody mapped |
Understanding AI risk means understanding identity exposure first. It is no longer enough to just know who has access to data. Companies deploying AI today need to know how far that access really stretches when AI is layered on top. This matters most for privileged accounts, service accounts, and other high-value identities.
Where the NIST AI Risk Management Framework Fits
The NIST AI Risk Management Framework (AI RMF) provides organizations a shared vocabulary and structure for approaching AI governance and risk. First published in January 2023, it is a voluntary, sector-agnostic framework designed to help organizations manage AI risk and build more trustworthy AI systems across their lifecycle without prescribing specific technologies. It offers outcomes and actions adaptable to different environments, making it practical rather than just academic.
The framework is built around four core functions: Govern, Map, Measure, and Manage. In an identity and AI context, here is what each one means in practice:
Govern focuses on accountability: who owns AI identity risk and who reports on it to executive leadership or the board. Without defined ownership, governance gaps persist across teams indefinitely.
Map is where you document where AI is plugged into your M365 environment, identity providers, and data sources. This means producing an inventory of AI systems, along with the identities and datasets each can actually access.
Measure is how you quantify blast radius and model data exposure across AI deployments. This is where AD and Entra ID assessment methods extend directly into the AI governance program.
Manage covers how you change access, re-scope models, revoke permissions, and update incident playbooks when risks are found. Governance without a response process is documentation, not risk management.
These four functions map well to existing risk processes and are easy to extend for organizations already running identity governance programs. NIST also identifies key trustworthiness characteristics for AI systems, including validity and reliability, security and resilience, explainability, privacy, fairness, and accountability. Each relies on knowing who or what accesses data, how decisions are made, and whether those decisions can be traced and explained after the fact.
NIST's Guidance for Generative AI
As generative AI adoption accelerated, NIST released a companion profile specifically for it. The NIST AI RMF Generative AI Profile adapts the core framework to risks specific to generative models, including hallucinations, content safety, and data leakage. Its suggested actions map back to the four core functions and include red teaming generative AI systems, folding generative AI into incident response processes, and monitoring for harms that emerge after deployment rather than at launch.
This is where AI-aware penetration testing and red team exercises fit in. Red teaming a generative AI deployment requires understanding which data an attacker or insider can surface through the model and which identities and permissions enable it. Organizations that have run traditional Active Directory assessments already understand the methodology, so applying it to AI-connected systems is a natural continuation.
NIST continues to develop the framework for higher-impact environments as well. In 2026, it released a concept note for a profile on trustworthy AI in critical infrastructure, a clear signal that governance expectations will continue to sharpen in sectors where AI intersects with regulated data and safety-sensitive operations.
The Regulatory and Compliance Picture
AI governance is being shaped by binding regulation alongside voluntary frameworks. The EU AI Act applies a risk-tiered approach, with transparency, accountability, and control requirements scaled to the level of risk a given AI system poses. GDPR continues to apply directly to AI, particularly around data minimization, purpose limitation, and privacy by design.
In the United States, Colorado SB24-205 sets requirements for developers and deployers of high-risk AI systems and imposes specific compliance on organizations using AI in consequential decision-making. NIST's ongoing work on trustworthy AI in critical infrastructure reinforces the trend extending to sectors with regulated data and operational risk.
When regulators or auditors come looking, they ask for specific evidence such as an AI system inventory, data flow diagrams, documented risk assessments, access records for AI identities, and evidence of human oversight for high-risk use cases. "We have an acceptable use policy" no longer suffices.
In regulated sectors like healthcare and financial services, AI controls are increasingly being incorporated into or extended beyond existing cybersecurity program requirements. In some cases, they layer directly onto frameworks like New York's hospital cybersecurity rule, and organizations in those industries face compounding expectations that require governance covering both the security dimension and AI-specific compliance.
These regulatory expectations point back to the same underlying fundamentals: knowing what data you hold, where it lives, who can access it, and how AI systems interact with it, exactly what identity security and access governance programs are already designed to produce.
Building an AI Governance Framework
You don't need to build AI governance from scratch. A better approach is to apply your existing identity security, data governance, and risk management practices directly to AI systems and workflows. A practical first 90-day plan looks like this:
Start with inventory. Find out where AI is being used across the business, including officially approved tools and the shadow AI tools that individual teams have adopted without formal review or oversight.
Second, map identities and data. For each AI system, document which identities it operates under, what datasets it can reach, and how that access was granted, including whether any permissions flow through nested groups or legacy ACLs that predate the AI deployment.
Third, analyze blast radius. For privileged accounts, service accounts, and other high-value identities connected to AI workflows, understand the full scope of what each one can actually access, not just the intended scope on paper.
Fourth, align with NIST's Govern, Map, Measure, and Manage functions and identify where gaps exist between your current posture and the framework's outcomes.
Fifth, put monitoring, logging, human oversight, and vendor risk checks in place for AI-driven workflows and document them in a form you can show to an auditor or regulator.
In most environments we work with, organizations start by running an identity-focused assessment of their AD and Entra ID environment, then layer AI-specific controls on top of what that review uncovers. This sequence makes sense because AI governance is harder and exposure is larger from day one if the identity foundation is weak.
If you don't have a solid identity and data governance foundation, it is usually better to slow a broad AI rollout and establish those basics first. AI should be rolled out in a well-managed environment, not on top of years of unreviewed permissions and oversharing.
For vendor risk, the contract levers that matter most are documented training data usage policies, retention periods, subprocessor locations, data localization commitments, and a contractual right to audit. Vendor assurances in sales conversations are not a substitute for contractual commitments you can verify and enforce.
Common AI Governance Failures
The organizations that struggle with AI governance usually run into the same issues we see in identity security assessments: limited visibility into who can access what, identity sprawl, permission drift, and governance controls applied inconsistently across systems.
Shadow AI is consistently underestimated as employees adopt tools without formal approval, leaving the organization with AI integrations it did not plan for and cannot audit. One effective mitigation is establishing a clear AI intake process so teams can get tools approved quickly rather than bypassing the process. A fast path to "yes" reduces shadow adoption more reliably than blocking.
We've seen cases where a single AI integration with a SaaS CRM inherited broad OAuth scopes that had not been reviewed since the original setup. The AI agent exposed more reportable data than any previous human error, simply because it moved faster and hit more endpoints automatically. The fix is both technical and contractual: restrict OAuth scope grants at provisioning and require API-level logging for any AI agent connecting to external systems.
Relying on vendor assurances without independent validation is a recurring problem. If you haven't verified how an AI provider handles data flows, retention, and model training, you may expose sensitive data in ways that conflict with your policies or regulations. That exposure grows more serious as AI moves deeper into core business processes and regulators ask sharper, more specific questions about AI risk management.
What Effective AI Governance Looks Like
Good AI governance starts with visibility. Organizations ahead on this can produce a clear picture of what data they hold, where it is stored, and who or what can access it across human and AI identities. They understand effective permissions, can measure blast radius for key systems and users, and have that analysis documented in a form suitable for a board or auditor.
A CISO should be able to show an AI system inventory, blast radius maps for high-value identities, an exception register for approved deviations from least privilege, and incident playbooks updated to cover AI-driven scenarios. That is the baseline for a defensible AI governance posture you can stand behind, though not perfect.
AI systems should be integrated into existing identity and access management processes rather than managed as a separate program. Frameworks like the NIST AI RMF provide a solid structure but need to be shaped to your specific environment and risk tolerance. The goal is to make AI adoption safe and auditable.
At Vilkas, most organizations start with an identity-first assessment of their AD and Entra ID environment, followed by a targeted review of how AI layers on top of that identity and permissions landscape. This produces blast radius visibility, a prioritized remediation roadmap, and documented evidence of control that make an AI governance program defensible to regulators, auditors, and leadership.
Closing Thoughts
AI governance is a core part of modern cybersecurity and risk management and is not going away. AI exposes and accelerates risks already present across your identities, data, and systems.
Organizations that treat AI governance as an extension of identity and access control and use the NIST AI RMF as a guide rather than a checkbox will be better positioned to manage AI risk, meet regulatory requirements, and scale AI adoption safely. Those who defer governance will find AI exposes their existing weaknesses faster than they can address them.
If you don't know what your AI can access right now, that's the right place to start.
Vilkas Cybersecurity helps organizations assess AI risk, understand identity exposure, and reduce blast radius across on-premises, hybrid, and cloud environments. If you're unsure where you stand on AI identity exposure, privilege sprawl, or nested group risk, fill out the form, and we'll get back to you shortly.