Frontier AI threats: getting visibility through Netgraph

Ask a CISO how many AI tools are running inside the estate today and you will get one of two answers: a number that comes from the procurement register, or an honest "we don't know". The procurement number is wrong — sometimes by an order of magnitude. Across our engagements the pattern is consistent: for every sanctioned AI assistant there are several unsanctioned ones — browser extensions that read every page, desktop clients with clipboard access, IDE copilots configured against personal accounts, and increasingly, local agent frameworks that developers spin up to automate their own work. Each of those is a process, on a corporate endpoint, moving corporate data to an inference endpoint someone else controls, with no log line anywhere in your SIEM.

That is only the first quadrant of the problem. The AI threat surface that has assembled itself inside enterprises since roughly 2024 has four distinct fronts, and they demand different telemetry. Before we get to what Netgraph does about each, it is worth being precise about what the fronts actually are — because "AI security" has become a phrase that means everything and therefore nothing.

The threat surface AI built inside your walls

1. Shadow AI: the inventory you don't have

Shadow IT was a governance nuisance; shadow AI is a data-exfiltration channel with a friendly interface. The failure mode is not malice — it is a finance analyst pasting a customer spreadsheet into a free-tier chatbot to "clean it up", or a developer wiring an internal database into a personal agent to save an afternoon. The data leaves, the tool's retention policy applies (or doesn't), and no control in the estate ever saw it as anything other than HTTPS to a popular domain. DLP tuned for file transfers does not see a paste into a chat box. CASB sees the domain, not the payload or the intent. The result is an unmanaged data flow that your DPDP or sector-regulator obligations absolutely do apply to, running through tools you cannot name.

2. Prompt injection: the injection class your WAF has never heard of

Every enterprise that deployed an internal LLM application — a support summarizer, a document Q&A bot, an agent that can open tickets — deployed a new kind of parser with a new kind of injection. Prompt injection differs from SQL injection in one crucial way: the payload is natural language, arrives through legitimate content (an email the agent summarizes, a document it retrieves, a web page it reads), and there is no grammar to sanitize against. Indirect injection — poisoning the content an agent will later ingest — is the variant that worries us most, because the attacker never touches your application directly. If your agent has tools (and the useful ones do), a successful injection is remote code execution with extra steps: the attacker's instructions ride the model's tool-calling ability into your systems.

3. AI-accelerated social engineering

Across public reporting and our own engagements, the clearest change in initial access over the past two years is quality at volume. Phishing lures with flawless language and correct internal jargon; voice cloned well enough to pass a hurried help-desk verification; video convincing enough for a wire-transfer pretext. None of these techniques is new — what is new is that they no longer cost the attacker anything. The defensive implication is subtle: controls that implicitly relied on attacker effort as a rate limiter (a human reviewing "suspicious-looking" mail, a help desk trusting a familiar voice) have silently lost their assumption.

4. Agentic attackers: the speed problem

The fourth front is the one that breaks SOC operating models rather than individual controls. An attacker running an agentic toolchain does not pause between phases the way a human operator does. Recon, credential testing, lateral movement scoping and staging can execute as one continuous loop — which means the comfortable assumption baked into most alert pipelines (a human will look at this within a few hours, and that will usually be fast enough) is no longer safe. When the dwell-time between first foothold and data staging compresses from days to minutes, a triage queue with a human-paced SLA is not a defense; it is a post-incident notification system.

Why the traditional stack misses all four

It is worth being honest about why this surface is so poorly covered, because the reasons are structural, not lazy:

• No inventory primitive. Asset inventories track hosts, software and cloud resources. Nobody's CMDB has a column for "AI tools in use and what data they touch". You cannot govern what you cannot enumerate.
• No telemetry on prompts and tools. An LLM application's security-relevant events — what went into the prompt, what the model decided, which tools it invoked, what came back — are typically not logged at all, or logged as application debug output that never reaches the SOC. There is no syslog for a chain of thought.
• Alert pipelines tuned to human speed. Correlation windows, batch enrichment, tiered triage queues — the whole pipeline assumes attack phases arrive hours apart. Machine-speed attack sequences complete inside the correlation window.
• Siloed context. Even where fragments of AI telemetry exist (a proxy log here, an endpoint process event there), they land in different tools with no shared entity model, so nobody can answer the question that matters: which identities are moving which data through which AI tools?

What visibility actually looks like in Netgraph

Netgraph's answer is not a bolted-on "AI security module" — it is the same unified-telemetry posture applied to a new domain. Four capabilities carry the weight.

Shadow-AI inventory from the endpoint agent

The endpoint agent's skills library includes a shadow-AI inventory capability: it enumerates AI tools present and running on each host — desktop clients, browser extensions, CLI tools, local model runtimes and agent frameworks — and reports them as structured inventory, per host, per user. Because the agent already feeds the platform's asset model, the inventory is not a one-off audit spreadsheet; it is a live dimension of the estate. The question "which hosts in the finance department run unsanctioned AI clients" becomes a query, not a project. And because the same agent watches process and network behaviour, presence and usage are distinguished: a dormant extension and a client that moved data today are different findings.

Prompt-injection detection where the prompts are

Alongside inventory, the agent skill set includes prompt-injection detection — inspecting content flowing into AI tools for the structural patterns of injection payloads: instruction-override phrasing, role-reassignment attempts, exfiltration directives buried in retrieved content. This is honest, pattern-level detection, not a claim to solve prompt injection (nobody has); its job is to surface the attempt so a human sees it, tied to the host, user, and application where it occurred.

LLM observability for the platform's own agents

Netgraph's AI LLM Observability console records the full prompt and tool trace of the platform's own agentic SOC — every prompt the triage and investigation agents constructed, every tool call they made, every result they acted on. Operationally this serves three purposes: you can audit why an agent reached a verdict; you can detect when an agent is being manipulated by the content it processes (an injection attempt inside an alert artefact is visible in the trace); and you can demonstrate to an auditor that autonomous actions have a reconstructible decision record. Any AI decision-support you deploy — ours or anyone's — should be held to this bar.

UEBA models built for machine-speed shifts

Against agentic attackers, the useful detection primitive is not a signature — it is a behavioural discontinuity. Netgraph's UEBA layer runs a catalogue of models that are specifically good at machine-generated behaviour: DGA-style detectors that flag algorithmically generated names and patterns, sequence models that score the order of actions an identity performs (agentic tooling produces sequences human operators rarely do — too regular, too fast, no idle gaps), and streaming models that update baselines continuously rather than on a nightly batch, so a behaviour shift is scored in minutes. The point is not that any single model "detects AI attacks" — it is that machine-speed operation has a statistical texture, and models watching for texture changes catch it where rule-per-technique approaches lag.

One graph underneath all of it

The multiplier is the substrate. AI-application logs, endpoint AI inventory, prompt traces, identity events and data-classification context all normalize onto the same knowledge graph. That is what turns four disconnected visibility features into answers to real questions:

# "Which identities used unsanctioned AI tools from hosts
#  that can reach classified data stores?"  — one NQL query,
#  because inventory, identity and data live on one graph.

FROM endpoint.inventory
| WHERE inventory.category == "ai_tool" AND inventory.sanctioned == false
| JOIN identity.sessions ON host.name
| JOIN graph.reachable(asset -> datastore) ON identity.user
| WHERE datastore.classification IN ("pii.customer", "finance.restricted")
| STATS tools = values(inventory.name), hosts = count_distinct(host.name)
    BY identity.user, datastore.classification

No single-domain tool can express that question, because the question spans domains by construction. This is the same argument we make at length in the graph-native correlation whitepaper, applied to a threat surface young enough that no silo has grown around it yet. Keep it that way.

A defensive playbook, mapped to modules

Visibility is a means. Here is the sequence we walk with customers, each step mapped to the module that carries it:

Two notes from the field on making this stick. First, do step 2 with the business, not to it — the fastest way to grow your shadow-AI population is to ban the tools people find genuinely useful without offering a sanctioned path. Second, resist the urge to skip to step 4. Detection rules written before you have the inventory and telemetry are rules about an estate you are imagining, and they will be wrong in both directions.

"We ran the inventory expecting a handful of extensions. We found AI tooling on a third of developer endpoints, most of it individually reasonable, none of it known to us. The scary part wasn't any single tool — it was realising our data-flow map had been fiction for a year." — SOC lead, large Indian enterprise.

The honest closing note

Anyone selling you a finished answer to AI threats is selling you last quarter's answer. The landscape genuinely moves monthly: new agent frameworks, new injection techniques, new places the models sit in the workflow. That volatility is exactly why the durable investments are the boring ones — inventory you can trust, telemetry that captures the new event types, auditability for every autonomous decision made in your estate (attacker's or defender's), and a substrate that lets you ask next month's question without a new integration project. Detection content will be rewritten every quarter; the visibility layer underneath it should not have to be.

That, ultimately, is the Netgraph position: AI threats are not a reason to buy another silo. They are the newest and best argument for not having silos at all — a case we make more generally in Why unified telemetry works, and one that the agentic AI SOC solution page shows from the defender's side of the same coin.

For the substrate argument in full, read the graph-native correlation whitepaper. If your estate is regulated or air-gapped and the idea of AI telemetry leaving the premises is a non-starter, air-gapped and DPDP-first covers how the same visibility runs entirely inside a sovereign boundary.