How an automotive company covered what its EDR could not: AI agents and the software supply chain, side by side with Netskope
AutoRobots, an automotive company, was told by incumbent vendors that their EDR already covered AI agents. It did not. The company deployed EDAMAME side by side with Netskope to catch software supply-chain attacks as behavior and to cover the new AI agent attack surface on the endpoint.
“Every incumbent vendor told us their EDR already covered AI agents. It didn’t — not what the agents do with our engineers’ access, and not a poisoned package that only misbehaves after it installs. EDAMAME runs next to our EDR and Netskope and closes exactly that gap.”
CISO
Automotive company
Challenge
AutoRobots operates in the automotive industry. Its teams adopted AI agents, and the security team needed to know whether its existing defenses covered them.
Several incumbent vendors gave the same answer: their EDR already handled it. On closer inspection, it did not.
Security challenges — what EDR was not built to see
Software supply-chain attacks: a poisoned package installs legitimately; the attack shows itself afterwards, when an install script writes outside its package or a process reads credentials and reaches the network. EDR alone was not enough.
A new AI agent attack surface: agents read code, secrets and credentials and run commands with the access of the human who launched them. Prompt injection, tool poisoning and goal drift can turn that access against the company while every log looks normal.
No view of intent: an EDR sees processes, but not what the agent declared it would do, so it cannot tell legitimate agent work from an agent that has been steered.
Netskope already in place: the company ran Netskope for network and cloud security and wanted host and agent evidence to reach that stack, not a new enforcement point.
Bottom line: AutoRobots needed AI agent security and supply-chain detection on the endpoint, without replacing its EDR or its Netskope deployment.
Solution
AutoRobots deployed EDAMAME side by side with Netskope and its existing EDR. The EDR keeps its role; EDAMAME watches what AI agents and their supply chain do across the whole host, from outside the agent. It ships no kernel driver of its own, adds no plugin inside the agents and does not intercept traffic, so it sits next to the EDR and Netskope without touching either.
Supply-chain attacks caught as behavior
EDAMAME detects the technique rather than the indicator — credential harvest, reads of another process's memory, token exfiltration, install-time writes outside the package tree, undeclared destinations — the patterns behind the axios, tj-actions, litellm and Shai-Hulud attacks.
The AI agent attack surface, covered
Every supported AI agent is discovered with its MCP servers, tools and blast radius. With a connected model, intent divergence compares what each agent declared with what the machine did, and an agent still running unconfined next to an installed sandbox is reported.
EDAMAME labels, Netskope enforces
EDAMAME applies a device tag in the Netskope tenant to devices that meet the company's EDAMAME policy and removes it when they stop. Netskope's Device Classification and Real-time Policy decide access.
Results
The gap EDR left, closed
Supply-chain behavior and AI agent activity are now observed on the machine, where those attacks happen — alongside the EDR, not instead of it.
No new enforcement plane
Findings reach the Netskope policy the company already operates: a host that falls out of the company's EDAMAME policy loses its tag and its access automatically, and regains them once fixed.
Evidence for the next vendor claim
Each AI check carries its OWASP GenAI, MITRE ATLAS and ISO/IEC 42001 references, so the security team can show exactly what is covered on every machine.
Want to see EDAMAME on your environment?
We’ll help you validate posture-based access controls for repos, CI runners, and internal apps in days — not months.