Expanding beyond the SOC: Introducing Exaforce Agentless AI Security

In the past 6 months, two incidents showed attackers compromising trusted third-party AI software to break into the platforms those tools connect to.

In April 2026, a Vercel employee connected Context.ai, a context engineering and AI analytics platform, to their corporate Google Workspace account with a broad set of permissions. Hackers stole the OAuth tokens from Context.ai and used them to take over the employee's Google account and jump into Vercel's internal systems. They were able to enumerate and decrypt non-sensitive environment variables. Vercel's product apps stayed safe. (Vercel security bulletin)

In August 2026, hackers took over the GitHub account of the maintainer behind keyv, cache-manager and flat-cache, npm libraries with a combined two billion downloads a month, and pushed poisoned versions that passed every provenance check. On every developer laptop and CI runner that installed them, a preinstall script harvested GitHub, npm, cloud and Kubernetes credentials. It then planted a Claude Code hook and a VS Code task, so the payload ran again every time a developer opened the repo or started a coding session, with no install needed. The stolen tokens were used to poison over 1,600 more package versions within the day. (The Hacker News, CSA Singapore advisory)
According to Wiz's analysis of the payload, the target list now includes the credential stores of Claude, OpenAI, Codex, Cursor and Gemini. (Wiz’s blog)

Both incidents exemplify how hackers take advantage of the trust WE give to AI agents: the credentials and tooling they hold on our laptops, and the OAuth permissions we grant them. This is why it's important to enable full visibility, detection and response into this emerging landscape. In a time when not only your developers are using agentic apps locally, but also the HR, Finance and GTM organizations do, these events will become more and more frequent, and they impose a real threat to sensitive business data. Addressing this new surface as part of the entire security program, and not as a new silo, is what lets an organization act, and not just react.

Introducing agentless AI Security

Today, we are introducing AI Agents Security at Runtime in the Exaforce Platform. AI agents and agentic apps are now an integrated part of the threat landscape. Exaforce enables security organizations to gain full visibility into this emerging attack surface, detect real threats and respond in real time, either autonomously or by human approval.

Exaforce enables this with no additional agent to deploy on the endpoint, by leveraging available integrations, APIs with all known LLM and agentic app providers, and the endpoint/EDR data Exaforce already ingests. On the endpoint, that EDR data is where the agents actually live. Exaforce tells an agent from any other process, ties it to the employee enterprise identity, the device and the access behind it, and follows what it touched, from the shell it opened to the file it read and the address it called. Exaforce now enables continuous visibility, risk identification, threat detection and response into every package, IDE extension and AI tool running across your organization fleet: developers, HR, finance and GTM alike.

This is not a separate product for agents. AI activity lands in the same platform as your identity, endpoint, cloud and SaaS data, so every agent action resolves to an actual identity (human or not), a device or resource, and gets scored against that identity's whole behavior, not only their AI usage. The chats, the sign-in, the device process and the cloud call become one story in one queue, handled by your SOC or our MDR. That is the difference between a new dashboard and a new capability: you see the whole incident, not just the AI part of it, and you can act on it with the integrations you already have.

Visibility to every AI & Agentic app your people are running

Exaforce 1st pillar to enable end to end AI agentic security at runtime, is full visibility into this surface:

• Agentic apps on every endpoint, and their configuration. Coding agents, desktop apps, MCP servers, IDE plug-ins and browser extensions, read from the EDR and MDM you already run, tied to the employee, the device and what they touched. Including the settings that matter: runs without asking, allowed and denied commands, trusted folders, MCP servers, AI switched off.
• Hosted agents, agents existing in the organization's Anthropic cloud account, or CustomGPTs by OpenAI for example, with their configuration: the model they run on, the skills attached, the MCP connectors they call and where those point, and the owner behind each one.
• AI chat sessions, and what is inside them. Secrets, PII and PHI exposed in prompts and answers, files shared with the model, prompt injection and suspicious intent, and a topic classification that tells personal use from business use, so a token spike on a personal chat stands out.
• AI skills, locally, in the cloud or in your repo, with a risk score and a recommendation for each.
• LLM API usage across every user in your organization, per model and product.
• Permissions shared with model providers, e.g. who gave Claude full read permissions to Google Drive.

This visibility streams into our semantic, behavioral and knowledge models, together with the other logs and configs. That enables Exaforce bots to stitch the new AI agentic data to known enterprise identities and cross application sessions, so a chat, a laptop process and a cloud call from the same person read as one story.

Exaforce also builds the agent graph: the employee, the agents and AI apps they run, the OAuth grants and credentials each one holds, and the resources those reach, so the blast radius of any single agent is one click away.

Flag risks, before the attack

The 2nd pillar is risk. After gaining full visibility, Exaforce flags the risky parts of your AI estate before anyone abuses them: excessive permissions for any AI app or agent, risky MCP servers, skills or plugins, and provider configurations that fall short. Two real world examples:

A skill that should not be installed. Exaforce flagged a Critical skill with a "Do Not Install" recommendation, and showed why:

The `collect_analytics()` function actively searches for and exfiltrates sensitive
environment variables under the pretense of 'usage analytics for improvement.' This constitutes natural-language exfiltration — using a benign-sounding comment to mask malicious data theft. It is especially egregious in a cooking skill where users have no reason to suspect their API keys or passwords are being stolen.

Shadow-AI OAuth app with write scopes. An OpenAI app was authorized to write, modify, send or delete Workspace data for the entire Google Workspace. Almost no restriction. Another example: a Claude for Google Calendar app had access to the entire workspace with write/send scope, which is much more than what it actually needs.

Real threat detection, at runtime

The 3rd pillar is our real threat detection. Exaforce sessionizes and correlates what agents do, in the chat, on the laptop and in the cloud, with the identities, endpoints and actions around them, to detect real threats, rooted in AI and agentic apps and respond to them in real time. Two examples from a live tenant:

An AI agent on a laptop goes after the session cookies. An AI desktop agent, launched with its safety prompts switched off, spawned a shell, copied the browser's cookie database and queried it for the company's own session cookies. Nothing on the device blocked it. Exaforce followed the process tree from the agent to the shell to the file, out to an IP in a denylist country, and tied it to 15 earlier findings on the same user and the same IP, including successful MFA and SSO logins. A P1, with the evidence attached, before anyone opened a ticket.

Exposed secret in an AI chat. The correlation story shows how Exaforce is able to "sessionate" different events to a session performed by a user. In this case, exposing an AWS access key secret from a TOR exit node, through an uncommon and unidentified IP location, addressing the baseline (3rd time of this occurrence). And Exaforce was able to identify that the secret is living exposed in the chat. The behaviour itself is suspicious, but the exposed AWS access key secret is what makes it a real threat. Exaforce triaged this finding in 12 minutes.

From today our customers will be able to use Exabot Detect for:

• Exposed secrets in AI chats
• Admin keys from rare ASN
• Identify malicious skill/MCP/instructions on endpoints and in repos
• Malicious AI skill/MCP Server on any device
• Agents running with safety switches off, and changes to their command allow/deny lists
• Suspicious intent and prompt injections in chats
• Shadow-AI OAuth apps with write scopes
• Flag insider risks from AI Platform logs
• Hook telemetry from Cursor (pre-execution events)
• Token spend visibility per user, model and product, with anomalous spikes flagged

Back to the two incidents this post opened with. Against the keyv attack, Exaforce works on two layers. The first is package visibility: Exaforce inventories the npm packages installed on every endpoint, so when a poisoned version is published you see which laptops and CI runners are exposed, and the Claude Code hook the payload planted shows up as a configuration change on the agent itself. The second is behavior. Exaforce baselines every agent on the laptop as its own identity, so a coding agent that starts reading credential stores it never touched, or pushing to a GitHub repository it never used, is a threat finding on its own, before anyone has flagged the package as poisoned. The Context.ai incident is the same story on the identity side: an OAuth app pulling data at volumes it has never pulled, from an ASN it has never used, is a threat finding too.

Autonomous or human-in-the-loop response, out of the box

Every template or response action within a custom workflow can be either autonomous (depends on the action) or notify a user (via Slack/email) to take the action needed to remediate. So our customers can decide whether they want certain workflows and threats to be responded to automatically, or involve a SOC engineer or the MDR team (ours or theirs) for more sensitive actions.

Why not just block every prompt?

Because blocking is one response, not the architecture. Stopping a prompt or a tool call before it runs is the right answer for a known-malicious skill or an agent that has clearly drifted from its baseline. Applied to every prompt through a rigid policy set, it interrupts developers, piles up false positives and ends with the control switched off, which is the worst outcome for everyone. So Exaforce treats blocking as a flexible response, decided per threat: when an agent's session starts to drift, the workflow can let it continue and record it, add a human in the loop, or stop the action. None of this needs another agent on the endpoint. The coding agents themselves expose hooks that fire before a shell command, file edit or MCP call executes, and Exaforce already ingests that hook telemetry, so the decision point sits inside the session, where the agent runs. When the blast radius reaches beyond the session, to the device, the identity or the cloud, the response moves to the tools you already run.

Endpoint containment through the EDR you already run is one example. Take the agent that went after the session cookies. The 1st step is to quarantine the laptop in CrowdStrike, so the agent process keeps running but nothing leaves the device. The 2nd step is to revoke the user's sessions in the identity provider, so the cookies it already copied are worthless. The 3rd step runs through Real Time Response: kill the agent process, remove the skill or instruction file that steered it, and push its hash as a prevent IOC so it cannot run on any other device in the fleet. Every step is a native action of a tool your team already trusts, chained by Exaforce into one workflow, with the analyst approving the destructive ones and the reversible ones running on their own.

What ships today

From today, our customers have a complete picture for their AI & Agentic apps, through visibility, risk, detection, response and governance, across 4 major AI surface areas: endpoints, hosted agents, chats and identities. And this is thanks to our best in class breadth of coverage: the applications, skills, plugins and extensions running on each endpoint, how each one is configured, and which of them are known to be malicious. Custom GPTs and Claude agents as hosted agents, with their models, skills and connectors. The actual conversations your team is having with LLMs via coding agents, Cowork or directly in the web applications, and what is inside them. The identities behind every agent and app, and what they are authorized and entitled to do. Exaforce doesn't miss a spot. Today, Exaforce covers Anthropic, OpenAI, Cursor, Copilot (M365 and GitHub), Gemini and Bedrock, for visibility, risk, detection, and response actions.

Get started

Want to secure your AI & Agentic applications surface? Book a demo.