Why your existing security stack cannot handle AI runtime risks

When people ask whether traditional security tools can prevent AI-era risks, I don't say yes or no. I walk them through a scenario. By the end, they stop asking.

Here's the scenario. An authorized user - an employee with legitimate access - is using your enterprise AI assistant. They start asking it questions. Cumulatively, across a few dozen queries over a few days, they extract enough customer PII to build a complete data set. No single query tripped an alarm. No file was downloaded. Nothing was emailed out. But the data is gone.

Can your existing stack catch that? Let's find out.

Step 1: Write a DLP rule

Your first instinct is DLP. You open Microsoft Purview (or your equivalent), create a policy, and define the sensitive data types: names, email addresses, phone numbers, account numbers. You set a threshold - say, more than five instances of PII in a single response - and block it.

The policy looks something like this:

# Microsoft Purview DLP Policy (simplified)
PolicyName: "AI PII Exfiltration Block"
Conditions:
  ContentContainsSensitiveInformation:
    - SensitiveType: "All Full Names"
      MinCount: 5
    - SensitiveType: "Email Address"
      MinCount: 5
  AND ContentSource: "AI Assistant Responses"
Actions:
  - BlockAccess
  - GenerateAlert
  - NotifyUser

This works until someone figures out that sending five queries of four records each returns twenty records with zero alerts. Chunking defeats per-response thresholds trivially. You just taught your users how to do it.

Step 2: Add intra-session CASB controls

So you layer in your CASB - Netskope, Microsoft Defender for Cloud Apps, or similar. You configure inline session policies that track how much sensitive data has been returned across queries within a session. Hit the cumulative threshold, end the session. Better.

# Netskope Session Policy (simplified)
PolicyName: "AI Session PII Limit"
Trigger: "RealTimeProtection"
Conditions:
  App: "Enterprise AI Assistant"
  SessionCumulativePII:
    Types: ["FullName", "Email", "Phone"]
    MaxCount: 20
Actions:
  - TerminateSession
  - Alert: SOC
  - LogEvent: SIEM

This works until someone logs out and logs back in. New session, clean counter. Your policy has an obvious, built-in bypass that requires zero technical skill to exploit.

Step 3: Add inter-session UEBA

Now you need behavioral analytics that spans sessions. You go to your SIEM - Splunk, Microsoft Sentinel - and write a detection rule that aggregates AI response data across sessions, per user, per day.

-- Splunk Detection Rule (simplified SPL)
index=ai_gateway sourcetype=session_logs
| eval is_pii_response=if(pii_count > 0, 1, 0)
| stats
    sum(pii_count) as total_pii_returned,
    dc(session_id) as session_count,
    values(query_text) as queries
  by user_id, date_trunc("day", _time)
| where total_pii_returned > 50 AND session_count > 3
| eval risk_score=total_pii_returned * session_count
| where risk_score > 200
| outputlookup ai_pii_risk_alerts.csv

This requires your AI gateway to be logging structured session data (including PII counts per response) into your SIEM in real time. If it isn't - and most enterprise AI deployments aren't - you need to build that pipeline first. That's a separate project, owned by Data Engineering, with its own timeline, backlog, and cost.

Count the systems. Count the teams.

Here is what you now own to enforce one rule: "don't let a single user extract more than X records of customer PII via AI queries in a day."

Four systems. Three teams. One rule.

And this is the simple case - a single rule about PII volume, applied to a single AI application, for a user category you already trust. You haven't touched prompt injection. You haven't touched agent tool-call authorization. You haven't touched cross-tenant data leakage in multi-model pipelines. You haven't touched agentic workflows that span multiple systems.

The hidden costs compound quickly

Each of those four systems requires someone to own it, configure it, maintain it, and respond when it fires. The DLP policy needs tuning as your AI usage patterns evolve. The CASB policy needs updates when new AI applications are onboarded. The middleware pipeline breaks when your AI gateway vendor updates their API. The SIEM rule generates false positives that your SOC analysts have to triage.

Would you hire two or three people at $50,000 to $250,000 annually to maintain this scaffolding for every AI governance policy you need to enforce? Because that is the honest cost. And most organizations need not one policy but dozens - covering data classification, user authorization, output filtering, audit logging, regulatory compliance, and incident response.

The tools aren't broken. They're doing exactly what they were designed to do. The problem is that they were designed for a different threat model: files moving between systems, users accessing known data stores, network traffic with inspectable payloads. AI runtime is none of those things. It is a conversational, stateful, context-sensitive interface to your most sensitive data - and it requires a purpose-built enforcement layer, not a patchwork of tools that were never designed to work together.

What a unified enforcement layer looks like

Trampolyne's Enterprise AI Security and Runtime Control platform sits between your users and your AI systems - whether those are commercial AI assistants, internally deployed models, or agentic workflows. It enforces policies at the point where they matter: the runtime.

The same rule - "no user extracts more than X PII records per day via AI queries" - becomes a single policy configuration. No middleware pipeline. No cross-team coordination. No SIEM query to maintain. The enforcement, the session state, the behavioral context, and the audit log all live in one place, owned by one team.

If your AI governance strategy today is "we'll use the tools we already have," the scenario above is a useful test. Walk through it with your security architect. Count the systems. Count the teams. Count the maintenance cost. Then ask whether that is a governance program or a liability.