RSAC 2026: AI Stack Blind Spots & NHI Security

Singulr AI highlighted a concerning pattern in CSO Online’s RSA Conference 2026 recap. Across enterprise assessments, organizations actively use between 350 and 430 AI services and features. Most of them operate without formal approval.

This is not a prediction — it is already happening.

For years, security teams focused on future AI risks: prompt injection, model abuse, governance frameworks, and regulatory readiness. RSA 2026 made the shift obvious. Those risks now exist in production. Meanwhile, most organizations still rely on data security models designed before this infrastructure appeared.

The Actual Attack Surface Isn’t Where You’re Looking

Ask a security team to map the AI threat surface, and they will usually focus on the model layer — API endpoints, inference services, and chat interfaces. That approach makes sense. Prompt injection is visible, easy to demonstrate, and simple to present in a slide deck. Executives prefer threats they can see. That preference rarely ends well.

However, the real exposure sits deeper in the stack.

RAG pipelines — Retrieval-Augmented Generation workflows — connect language models directly to external data sources. Instead of retraining models, teams feed them live enterprise data. As a result, internal databases, document stores, knowledge bases, and data warehouses become part of the model’s runtime context.

This shift creates a clear risk. Customer records, contracts, financial data, and internal communications become accessible unless teams strictly control access.

The Retrieval Blind Spot

Retrieval systems do not audit themselves. Without proper instrumentation, teams cannot track what the system fetched, which service account executed the request, or which query triggered it. They also cannot verify whether the access matched user permissions.

Vector databases introduce a related problem. Embeddings are not plaintext, but they are far from harmless. OWASP’s 2025 LLM guidance identifies vector and embedding weaknesses as a separate risk category, including data leakage, unauthorized access, and manipulated retrieval.

Teams often treat embeddings as safe metadata. That assumption fails quickly. Research presented at EMNLP 2023 showed that text embeddings can be inverted under certain conditions. In other words, derived data can expose original content.

Retrieval Poisoning in Practice

Retrieval poisoning adds another layer of risk. Attackers do not need dramatic breaches. Instead, they inject malicious content into knowledge bases and wait.

Over time, the model retrieves that content and generates attacker-shaped responses with full confidence.

PoisonedRAG research presented at USENIX Security 2025 demonstrated how effective this approach can be. Injecting just five malicious entries per target query into a large knowledge base produced a 90% attack success rate.

This is not a Hollywood scenario. It is controlled manipulation of context that consistently shifts model output.

None of this remains theoretical. The real gap today is visibility into the data layer these mechanisms target.

Shadow AI Is Past the Gate

Shadow AI is not mainly a policy problem. It is a visibility problem.

An unfamiliar service account pulling PII outside business hours. A document retrieval service that did not exist six months ago running queries against a customer database. Usage patterns that do not map to any approved application. A browser-based AI tool receiving pasted customer records because the official workflow is too slow and everyone is pretending that is not how work actually gets done.

Microsoft’s RSAC 2026 Edge for Business announcement framed the same issue at the browser layer: employees bring consumer GenAI tools into the workplace, creating risks when sensitive information is typed or uploaded into unsanctioned AI tools where it may be retained or used for training.

This is where data-layer activity monitoring catches what perimeter tools miss — not by magically labeling every workflow as “AI,” but by detecting access that does not fit established behavioral baselines.

The 350 to 430 unsanctioned services are not hidden because they are clever. They are hidden because the monitoring infrastructure was built for a world that did not have them.

A Note on Where This Advice Breaks Down

The phrase “secure the AI stack” assumes a clearly defined stack. In reality, most organizations operate something messier. They deal with vendors, integrations, browser features, internal experiments, and half-approved projects spread across business units that never aligned on procurement in the first place.

This gap matters. Data-layer controls only work when teams know what to instrument. Monitoring a database that you do not even realize connects to an AI service does nothing. Therefore, everything starts with inventory — not just AI systems, but data infrastructure, sensitive data locations, and the identities that access them.

Sensitive data discovery forms that foundation. It is not an “AI security” feature; it is basic hygiene. Teams must understand what data exists, classify what matters, track system connections, and remove access paths that should not exist. Without that baseline, meaningful control does not happen.

What Faster Response Actually Requires

AI-powered defense is often sold as a speed story — faster triage, faster containment, faster response. Fine. Speed matters.

However, automated response depends on clean evidence. When logs contain gaps, automation does not become decisive. Instead, it produces confident but incomplete decisions — which is just underinformed action with better branding.

Response pipelines rely on signals from logs, policies, access records, and activity history. When those signals miss key inputs — for example, vector database queries, RAG retrieval events, or mapped AI service accounts — the system either misses incidents entirely or reacts on partial context.

In practice, faster response only works when monitoring and audit systems already exist. Building that visibility during an incident, while teams argue over service account ownership, is not a strategy.

The Practical Layer

Three things security and data teams can do this quarter that are not theoretical:

• Extend activity monitoring to AI-adjacent infrastructure. Vector databases, embedding services, document stores, and data systems connected to LLM workflows should not sit outside the monitoring perimeter. If your monitoring does not cover them, you do not have visibility into a major part of the attack surface described at RSA.
• Apply masking in training, testing, and non-production environments. Raw production data used for training, fine-tuning, validation, or analytics is one of the ugliest patterns in the AI deployment lifecycle. If a workflow does not need raw PII, PHI, payment data, or other regulated fields, do not hand it over like a party favor.
• Map machine identities against your data access controls. CyberArk reported that machine identities outnumber human identities by more than 80 to 1. Most access control frameworks were designed around human users. AI agents and service accounts connecting to databases often inherit broad permissions established during development and never tightened.

None of this requires pretending that AI security is a completely separate universe. Most of it starts with data security infrastructure organizations already have, already need, or should have bought before the incident report taught them economics the hard way.

DataSunrise provides real-time activity monitoring, sensitive data discovery, data audit, and dynamic masking across databases, cloud data stores, and distributed data environments — including infrastructure that AI systems increasingly depend on.