The scenario is specific.
A developer opens their AI coding assistant and pastes in a function. The model suggests a completion. The session ends. Nothing unusual — a hundred of these happen across the fleet every day.
Except the response payload embedded an indirect prompt injection. A crafted string, planted in a poisoned package registry the model had indexed, designed to instruct the assistant's tool-use layer to read local credential files on the next invocation and transmit them in a subsequent API call.
Your firewall saw HTTPS to a known AI endpoint. It logged the connection. It moved on.
Your SIEM had no alert to triage. There was no anomalous destination, no unusual port, no signature match. The attack used your developer's own AI tool, over TLS, to a trusted provider, to exfiltrate credentials that would have given an attacker standing access to your production environment.
This is what enterprise AI adoption looks like from the attacker's side: a massive expansion of trusted, encrypted channels that security teams have no visibility into.
The New Encrypted Noise Floor
AI tool adoption in the enterprise isn't slowing. It's accelerating past the point where security teams have meaningful visibility.
The average developer now routes significant portions of their working day through AI API endpoints — code, documentation, internal architecture context, sometimes credentials. AI agents with broad tool access are being deployed to handle tasks that previously required human action: reading files, writing to databases, calling internal APIs, browsing the web on behalf of the user.
All of this traffic is TLS-encrypted. The destinations look legitimate — and usually are. The payloads are invisible to every layer of the conventional security stack.
Traditional security was built for a threat model where the danger was in the transport: malicious destinations, unusual ports, known bad IPs. That model is being routed around entirely. The threat is now in the content being exchanged with endpoints that look completely clean.
The signal is in the noise. The noise floor just got dramatically louder.
What Attackers Already Know
Prompt injection isn't theoretical. OWASP named it the top risk in their LLM application security framework. The techniques are active in the wild. The attack surface has three vectors that enterprises are almost uniformly unprepared for.
Indirect prompt injection. The attacker never interacts with your AI system directly. They plant instructions in content the AI will eventually read: a document in a shared repository, a support ticket, a web page the agent browses, a function docstring in a public package. When the AI processes that content, it receives and executes the injected instruction. The developer who triggered it never saw the attack. Neither did your security stack — because nothing about the connection looked suspicious.
Data exfiltration via AI APIs. The path of least resistance for sensitive data leaving your organisation is increasingly an AI API call. A developer troubleshooting a production incident pastes database credentials. An analyst asks the model to summarise a client report containing PII. Legal drafts a contract using a public AI tool. The data leaves in an encrypted POST request to a trusted domain. Nobody sees it leave.
Compromised AI infrastructure. AI API providers, model registries, and MCP servers — the tool-use layer that AI agents rely on to take action in the world — are supply chain targets. A compromised provider doesn't need to breach your perimeter. Your enrolled devices connect to it voluntarily, repeatedly, and trustingly. The responses coming back may carry payloads designed to manipulate, exfiltrate, or establish persistence — and they arrive through a channel your security team has marked as trusted.
What Threatmatic Already Sees
Before payload inspection, Threatmatic already has visibility that no conventional firewall or SIEM achieves.
We see the identity behind every connection. Not just the IP — the enrolled device, the organisation, the session context. When an AI API call leaves an enrolled endpoint, we know which endpoint it came from. Not a NAT address shared by a hundred devices behind a corporate router. The specific machine, the specific identity.
We see the traffic pattern across the entire fleet. If three devices across two organisations begin making high-volume connections to an AI endpoint outside business hours, that's a cross-fleet signal — one that no single organisation's security stack would catch, because each organisation sees only its own telemetry.
We already block known-malicious infrastructure at the identity layer, before connections are established. That includes C2 infrastructure repurposed to mimic legitimate AI API endpoints — a technique appearing in incident reports with increasing frequency as attackers learn to hide in AI traffic.
But we don't yet see the payload.
That changes soon.
What Payload Inspection Changes
Threatmatic is shipping payload inspection: the ability to intercept, decrypt where necessary, and examine the content of connections traversing enrolled devices — both encrypted and plaintext traffic.
Exfiltration detection. A POST to api.openai.com containing AWS credentials looks identical to any other AI API call at the transport layer. At the payload layer, it contains your AWS credentials. Threatmatic can detect the data pattern, alert on it, and block it — before the exfiltration completes. Policy can be content-aware: block requests containing secrets, flag sessions transmitting above a volume threshold, require approval before internal documents leave the device.
Prompt injection detection. A response payload containing injection patterns — ignore previous instructions, encoded variants, or novel techniques that match behavioural signatures — is now detectable. We can flag the payload, prevent the AI client from acting on it, and correlate it across the fleet: if the same injection technique appears in responses on multiple devices across multiple organisations, that's a supply chain indicator, not a coincidence.
Shadow AI visibility. Enrolled devices already generate a map of every AI endpoint they communicate with. Payload inspection adds the ability to enforce on what they're communicating. Block requests containing specific data classifications. Enforce that AI sessions don't transmit internal system prompts or architectural context to public models. Log every AI interaction for audit — without requiring the AI vendor's cooperation.
Fleet-wide content correlation. When one device receives a suspicious payload — a novel injection technique, an unusual data request, a response that contains recognisable exfiltration staging — the intelligence fabric cross-references it against every device in the fleet. A new attack technique encountered by one organisation becomes a fleet-wide detection signature automatically, before it reaches anyone else.
The Fleet Advantage at the Payload Layer
An isolated device running payload inspection is useful. The Threatmatic fleet running payload inspection is a different category of capability.
AI attacks aren't random. Attackers probe, iterate, and reuse successful techniques. An indirect prompt injection that works against one AI client is likely to be tested against others. A compromised MCP server doesn't target a single organisation — it targets every organisation whose devices connect to it.
Each time a novel payload technique touches one device in the Threatmatic fleet, it becomes intelligence for every other device. The second organisation to receive the same injection pattern doesn't experience it as an unknown threat. They experience it as a pre-blocked technique — because another device in the fleet already saw it, flagged it, and the intelligence propagated.
The same compounding logic that protects the fleet against SSH brute-force campaigns applies to AI-layer threats. The intelligence fabric becomes progressively harder to fool as the fleet grows — because every attacker interaction with any enrolled device makes every other device smarter.
The Window Is Closing
Enterprise AI adoption is moving faster than enterprise security. Most organisations today have no meaningful visibility into the content of their AI API traffic. They've deployed AI tools, granted them broad access, and extended implicit trust to the channels those tools use — without any ability to verify what's actually being said.
Attackers already know this. The techniques are being developed, tested, and weaponised now. The question isn't whether the AI layer of your stack will be targeted. It's whether you'll have any visibility when it is.
Payload inspection is shipping. Fleet-wide. Content-aware. And built on the same intelligence fabric that already turns one device's experience into every device's protection.
The signal was always in the noise. Now we're reading the signal.