The Access Problem Nobody Talks About
Most conversations about AI and ransomware go straight to deepfake phishing or AI-written malware. That's a real trend, but it misses the quieter problem sitting inside your own network: the AI tools you deployed.
Generative AI is now woven into everyday work. Employees use assistants to summarize documents, search internal knowledge, draft content, and kick off automated workflows. Organizations are rolling out agents that go further—calling APIs, touching SaaS platforms, writing back to databases—with minimal human sign-off in the loop. That autonomy is the whole point. It's also the exposure.
AI doesn't conjure a new ransomware playbook. What it does is hand a fast-moving attacker a dramatically better map of your environment—and sometimes the keys to act on it. The underlying risk isn't the model; it's the permissions that come with it.
Two Threat Models, One Converging Problem
There are really two AI stories running in parallel right now, and security teams need to hold both in mind at once.
Attackers using AI on their end. Criminal groups are integrating AI into their operations: generating phishing emails, writing and debugging malicious scripts, automating reconnaissance, analyzing stolen credential dumps, and personalizing extortion messages. The Acronis Cyberthreats Report H2 2025 documents the GTG-2002 threat group doing exactly this—using AI to scale out what a small team can accomplish without fundamentally redesigning the attack. The GLOBAL GROUP ransomware operation went further, deploying an AI chatbot to automate ransom negotiations so human operators could manage more victims in parallel. This is AI as an efficiency layer, not a paradigm shift—but efficiency at scale is dangerous enough.
Organizations deploying enterprise AI. This is the less-discussed side. AI assistants and agents connect to document repositories, collaboration platforms, internal wikis, and SaaS stacks. They operate under delegated identities and permissions. When an attacker compromises those identities—through credential phishing, OAuth token abuse, or session hijacking—they may inherit everything the AI can reach.
Both trends are intensifying simultaneously. As attackers get faster, an enterprise AI deployment with sloppy access controls hands them a shortcut.
Identity Is Still the Battlefield
Ransomware campaigns haven't changed their skeleton in years: gain initial access, perform discovery, escalate privileges, locate valuable data, exfiltrate, then decide whether to encrypt, extort, or both. What changes with enterprise AI is how fast an attacker can run the discovery and exfiltration steps once they're inside.
Microsoft reports analyzing approximately 38 million identity risk detections every single day. The Cloud Security Alliance has documented large-scale OAuth device-code phishing campaigns targeting Microsoft 365 users specifically. Identity is the battlefield—and AI applications sit inside that battlefield, operating under the same identity infrastructure that attackers already know how to crack.
When an attacker compromises the credentials or token associated with an enterprise AI assistant, they don't just get the assistant. They get everything the assistant's identity can reach: document repos, connected APIs, any SaaS integrations configured to trust that credential. That's not a theoretical risk. It's the natural consequence of wiring AI into your identity stack without tightening access first.
For a deeper look at how shared credentials amplify this exposure across fleets of AI agents, see One Key to Rule Them All: The Danger of Shared Credentials in Enterprise AI Fleets.
How AI Inherits Access It Was Never Explicitly Granted
Here's the part most security teams underestimate: AI agents rarely receive permissions directly. They inherit access through existing infrastructure—and that inheritance chain is often invisible.
A typical access path looks like this:
User → Application → API → Service Account → Data Repository
The AI agent operates somewhere inside that chain. It inherits whatever the application already has, whatever the service account already covers, whatever the API already permits. An over-permissioned service account that was set up three years ago to support automation can silently extend that access to every AI workflow that now runs through it.
There are five common inheritance paths worth understanding:
-
Application-level inheritance. An AI copilot embedded in Microsoft 365, Salesforce, or ServiceNow inherits portions of whatever that platform can already access. Security teams evaluate the application; they often skip evaluating the AI identity operating inside it.
-
API inheritance. AI agents interact with enterprise systems through APIs that already have broad permissions—retrieving records, triggering workflows, updating data. The agent effectively gains the API's capabilities.
-
Service account inheritance. Automation-supporting service accounts are frequently over-permissioned by design, to avoid friction as services are added. AI agents that depend on those accounts inherit the excess.
-
User role inheritance. Copilots operating on behalf of a user inherit that user's full access scope—including sensitive data the AI has no business reason to touch.
-
Machine identity inheritance. Certificates, tokens, secrets, and workload identities authenticate AI to cloud services. Compromising those machine identities gives an attacker the same reach as the AI itself.
The result: most organizations cannot clearly explain why a given AI system has access to a specific application, system, or dataset. That visibility gap is where ransomware operators are starting to look. This problem grows more acute as AI deployments scale—When AI Agents Multiply Machine Identities, Security Teams Lose Track of What's Trustworthy examines how proliferating machine identities compound the governance challenge.
The AI Assistant as Discovery Engine
Think about what a connected enterprise AI assistant can do in five minutes: search across every indexed document, summarize SharePoint libraries, identify files matching a search term, and return structured results. For a legitimate employee, that's productivity. For an attacker who's stolen the right credentials, it's a reconnaissance shortcut that would have taken hours of manual folder-browsing.
Rather than crawling hundreds of directories, an attacker with a compromised identity can simply ask the AI to locate backup documentation, administrative procedures, customer records, or financial data. The assistant doesn't know it's talking to the wrong person. It just answers the query.
Agents with active permissions compound the problem. If an AI agent is authorized to send emails, export files, or invoke connected business tools, a compromised identity can abuse those capabilities to move data out faster than any manual exfiltration method. The underlying risk isn't AI behaving badly—it's AI behaving exactly as designed, just for the wrong principal.
Prompt injection is another angle: malicious instructions embedded in a document or email can influence AI behavior when the agent retrieves that content. But OWASP is clear that prompt filtering alone isn't the answer. Layered controls, least privilege, and human approval for high-risk actions are what actually contain the blast radius. Relying on prompt filtering while ignoring permissions is like installing a deadbolt and leaving the window open.
Anthropic researchers have documented a Chinese state-sponsored group using agentic AI to execute large portions of a cyberespionage campaign—reconnaissance, vulnerability research, credential harvesting, data collection. The efficiency gains available to nation-state actors apply equally to ransomware operators running leaner crews.
Six Controls That Actually Reduce the Risk
You don't need to scrap your existing security strategy. You need to extend it. Enterprise AI sits inside your identity, data, and access management environment—so the right response is governance that closes the gap, not an entirely separate security program.
1. Build an AI inventory
You can't govern what you can't see. Maintain an inventory of approved AI applications, models, and integrations, including shadow AI that employees have connected without formal approval. Every AI workflow should have a defined owner, a stated business purpose, and a risk classification. If you can't name the owner, the permissions are unaccountable.
2. Enforce least privilege across the whole chain
Grant AI applications, service accounts, and APIs only the access required for their specific task—nothing more. Review delegated permissions on a regular schedule; revoke credentials that aren't actively used. This includes the machine identities and tokens that AI systems use to authenticate. An AI assistant that only needs to read from a single document repository should not have write access to the corporate email system.
3. Control AI-related traffic and data movement
Use secure web gateways, CASB tooling, and DLP capabilities to discover what AI services employees are actually using, block access to unauthorized tools, and prevent sensitive data from being uploaded or exported through AI channels. Shadow AI usage is wide—if you're not looking for it, you're not finding it.
4. Monitor and audit AI activity continuously
Correlate AI application usage, identity events, data access patterns, export actions, and agent interactions with your existing endpoint, SaaS, and cloud telemetry in SIEM or XDR systems. Maintain audit trails that answer three questions: which user or service account initiated the action, what resources were accessed, and whether human approval was obtained. If you can't reconstruct an AI session after the fact, you can't investigate it.
5. Prepare for fast containment
Security teams need practiced playbooks for revoking compromised tokens, disabling affected integrations, and suspending AI workflows when malicious activity surfaces. Speed matters—an AI-accelerated attacker can exfiltrate in the time it takes to find the right admin screen. Immutable backups and tested recovery procedures remain essential. They can restore encrypted systems; they can't reverse a data theft that already happened, which is why containment speed is its own control.
6. Require human authorization for high-risk actions
Bulk data exports, administrative changes, external communications, and code execution should require human or policy-based approval before the agent acts. OWASP explicitly recommends this for privileged operations—not as a productivity speedbump but as a structural limit on how much damage a compromised AI identity can do before someone notices. The more autonomous the agent, the more important the human gate.
Extend Resilience, Don't Reinvent It
Enterprise AI adoption isn't slowing down. The productivity case is too strong for that. The challenge is making sure the access model underneath it isn't quietly expanding the attack surface that ransomware operators are already probing.
The most practical posture isn't a separate AI security program bolted onto everything else. It's incorporating AI governance into the identity, data protection, and incident response work your team already does—asking the same access questions you'd ask about any privileged integration, and demanding the same visibility you'd expect from any system that touches sensitive data.
As attackers continue integrating AI as an operational force multiplier, the organizations positioned to contain ransomware risk are those that treat their AI deployments with the same skepticism they apply to everything else connected to their network. Less autonomy than you think is justified. More monitoring than feels necessary. Human approval exactly where it's inconvenient.
That's the actual playbook. For a broader look at building enterprise defenses before AI-powered attacks arrive, see The Security Posture Enterprises Need for the AI Era.