EDAMAME now integrates with Netskope. When a device passes your EDAMAME policy, EDAMAME applies a device tag in your Netskope tenant; when the device falls out of compliance, the tag comes off. Your own Netskope Real-time Policy, keyed on that tag, decides what the tag grants. EDAMAME labels, Netskope enforces — the enforcement decision stays entirely yours. The setup guide is public: Setting Up Netskope for Access Control Integration.

The mechanism is simple. What makes it worth writing about is what EDAMAME counts as compliant, because the definition now reaches past the state of the machine and into the behaviour of the AI agents running on it. And Netskope's own threat research explains why that matters.

What Netskope's Europe 2026 report says is actually leaking

The Netskope Threat Labs Report: Europe 2026 covers the year from March 2025 to March 2026, and its headline is saturation: 99% of European organisations now use AI applications, with the share of individual users actively using them climbing from 35% to 65% in twelve months. Governance improved over the same window — personal AI accounts fell from 79% to 43% of users while organisation-managed AI rose from 28% to 72%.

The interesting part is the composition of what leaks. Across AI and personal cloud apps, data-policy violations break down as regulated data 59%, source code 15%, intellectual property 13%, and passwords and API keys 12%. Put source code and credentials together and more than a quarter of all violations are engineering material; add intellectual property and it is 40%. Regulated data is still the biggest bucket and rightly gets the attention. But a meaningful minority of these incidents are not a marketing spreadsheet in the wrong Drive — they are a repository, a private key, a token.

Two more findings from the report matter here. First, AI is no longer something a user visits: 64% of users touch AI apps directly, but 95% use applications with embedded AI features, and the report names coding copilots explicitly alongside meeting transcription and writing assistants. Anthropic Claude is now the second most adopted AI application in Europe at 79% of organisations, ahead of Google Gemini at 69% — and Claude is the engine behind Claude Code, which runs shell commands on a developer's laptop. Second, attackers deliver malware through platforms your engineers are required to trust: GitHub and Microsoft OneDrive lead the list, each affecting 10% of European organisations.

Put those three findings next to each other and a specific picture forms. The most-adopted AI in Europe is increasingly one that executes code locally. The material most at risk, after regulated data, is code and credentials. And the delivery channel of choice is the developer's own supply chain.

The part that never crosses the proxy

Netskope's controls sit inline: a next-generation secure web gateway inspecting downloads, DLP on traffic to personal and AI app instances, an AI gateway between users and models. That plane is real, it is where a large fraction of AI-era data exposure happens, and the report's recommendations follow from it correctly.

But an AI agent running on a laptop does a great deal that produces no cloud transaction at all. It reads ~/.aws/credentials. It spawns a shell. It runs a package's post-install script. It writes to a file outside the workspace it was pointed at. It opens a socket to a raw IP address. None of that is a download from a sanctioned app, and none of it is a prompt sent to a model. It is local process behaviour on a trusted, managed device — and it is exactly where the blast radius of a compromised agent lives.

Even for the traffic that does cross the network, there is a resolution gap. The network sees a destination, a volume, a category. It does not see which agent opened that socket, under which declared task, from which parent process, having just read which file. That attribution only exists on the host, at the operating-system boundary.

So there are two planes, and they are complementary rather than competing. Netskope owns the network, cloud and AI-traffic plane. EDAMAME owns the host and agent plane: EDAMAME Security on laptops, EDAMAME Posture on CI/CD runners and self-hosted agent hosts. The integration is what lets a finding on the second plane change an access decision on the first.

How the integration works

Netskope joins EDAMAME Hub's conditional-access providers — GitHub, GitLab, Entra ID, Google, FortiGate, NetBird and Tailscale — as a tag-based trigger, closest in shape to NetBird, Tailscale and FortiGate. The chain is four links long:

EDAMAME applies a device tag to a device that satisfies your policy — and removes it when the device stops satisfying it.
A Netskope Device Classification rule matches on that tag.
A Netskope Real-time Policy references that classification.
Netskope allows or blocks.

Three design choices are worth calling out, because they determine how the thing behaves on a bad day.

Allow-on-tag, so every failure mode is the safe one. Because EDAMAME tags devices that pass, the policy should grant access when the tag is present. A device with no EDAMAME agent, a device whose Netskope Client was never enrolled, an EDAMAME outage — all of them leave the device untagged, and therefore denied. The inverse polarity, treating the tag as a block signal, both inverts the meaning of the tag and fails open. The guide is blunt about this because it is the single mistake that turns the integration into a liability. (An expired API token behaves differently and is worth noting: EDAMAME can no longer update tags, so every device keeps whatever tag state it had at that moment. Expiry freezes enforcement rather than opening it — but rotate the token in Hub before it lapses.)

Read-modify-write, so other tools' tags survive. Netskope's tag write is replace-semantics: the array you send becomes the device's entire tag set. So every EDAMAME update reads the device's current tags first, adds or removes only its own, and writes the result back. Tags applied by Netskope Cloud Exchange or any other integration are preserved. This is deliberately unlike EDAMAME's allow-list and group integrations, which replace the whole list on each update.

Per-device, never a fleet-wide sweep. Only the device whose compliance actually changed is touched. There is no reconciliation pass across the tenant, so the integration can never affect a device EDAMAME has not heard from — and a single misreported device cannot cascade into the rest of the fleet.

EDAMAME Hub Policies view: four policies - Production Access, Corporate VPN, Finance (PCI-DSS), Company Baseline - each with a conditional-access provider badge and live compliant / non-compliant device counts

EDAMAME Hub → Security → Policies: each policy carries its own compliance definition and its own conditional-access provider, with live compliant and non-compliant counts. Netskope joins the same list as a trigger provider. Hub policies documentation.

What “compliant” means once the agent is in scope

This is the part that extends what a Netskope-managed device compliance signal can express. Historically, device compliance meant the state of the machine: disk encryption on, screen lock set, OS patched, antivirus running. EDAMAME still checks all of that — the checks live in the open-source threatmodels repository, tagged with their CIS, ISO 27001 and SOC 2 references, so you can read exactly what is being asserted.

What is new is a second family of checks, tagged AI Agent Posture, that assert things about the agents on the device rather than the device itself:

An agent running unobserved. Cursor, Claude Code, Claude Desktop, Codex, OpenClaw and Hermes each have a check that fires when the agent is present but the host-side observer is paused — the agent is running and nobody is watching.
An agent with a high host blast radius. The agent can reach far more of the machine than the task requires — unsandboxed, passwordless privilege escalation, broad filesystem reach.
An agent running without a governance harness, where no sandbox or policy runtime fences it at all.
An agent that has escaped its harness boundary — a harness is present, and the agent's observed behaviour is outside it. This is the highest-severity check in the family, because a bypassed control is worse than a missing one: it looks contained.
Behavioural divergence and unreviewed attack-pattern findings — the two runtime outputs, described below.

Those checks flow into the ordinary Hub score and policy pipeline. Which means a policy can now say: a device keeps its Netskope tag only while every AI agent on it is observed, fenced, inside its fence, and behaving as declared. When an agent on a managed laptop starts behaving like an attack, the tag comes off, the Device Classification stops matching, and the Real-time Policy denies. Re-tagging is automatic once the device returns to compliance — nobody has to touch the Netskope console.

Supply chain: the report's GitHub finding, seen from the host

The report's observation that GitHub is a leading malware-delivery platform is the network-plane view of something we see from the other side. When an AI agent runs npm install or pip install on its own initiative, a compromised package executes on a developer's workstation with that developer's credentials. The registry request looks entirely legitimate, because it is.

What gives it away is the behaviour afterwards: a process with open handles to several credential stores at once, a token read followed by an outbound session, a post-install script writing outside the workspace. EDAMAME's attack-pattern detector works on that signal, and it is the half of the product that already earns its keep — the axios npm RAT, the litellm PyPI takeover, the tj-actions/changed-files compromise, and the TanStack / Shai-Hulud payloads all present as runtime behaviour, not as a signature.

With the integration in place, a credential-harvest finding on a laptop is no longer only an alert in a console. It is a compliance state change, and therefore an access change in Netskope, within the same loop.

Intent divergence: the one record the agent cannot edit

The second output is the one the report cannot measure from the network at all, because it requires knowing what the agent said it was going to do.

Intent divergence is the distance between the agent's declared plan and what the machine actually did — processes spawned, files opened, sockets created, credentials touched. You cannot get that answer from inside the agent: a misdirected or hijacked agent narrates a perfectly reasonable account of itself, and the log it writes is the log it chooses to write. Observed from outside, at the operating-system boundary, it is the one record the agent cannot fake, narrate away, or erase. That is the ground truth of what the agent actually did.

This rests on published research, not just a product claim. Our joint paper with the LISTIC laboratory (CNRS) is open-access on HAL, and we are explicit in it about the limits: the approach is reactive, detecting divergence as it unfolds rather than preventing the first action, and the hardest case — an agent living off the land, doing only permitted things for a forbidden purpose — is tagged in the paper as a designed miss. The full write-up is here.

Where the evidence lands: OWASP GenAI, MITRE ATLAS, trust controls, Vanta

A finding is only useful if it lands in a taxonomy your team and your auditor already read. Every agent finding EDAMAME produces carries framework references, and they surface as live scorecards in the app.

OWASP GenAI. Findings are tagged against the OWASP Top 10 for Agentic Applications 2026 (ASI01–ASI10) and the OWASP Top 10 for LLM Applications 2025 (LLM01–LLM10). A credential-harvest detection carries LLM02 Sensitive Information Disclosure and ASI03 Identity and Privilege Abuse; a poisoned-skill detection carries LLM03 Supply Chain and ASI04 Agentic Supply Chain Vulnerabilities. The scorecard grades coverage honestly, row by row, and separates detection from enforcement — several rows read “monitoring only”, because that is the truth. This is our own engineering crosswalk, not an OWASP certification or endorsement.

EDAMAME Security AI tab, Compliance subtab: the OWASP GenAI Scorecard listing ASI01 Agent Goal Hijack through ASI07 Insecure Inter-Agent Communication, each row with live alertable finding counts, a coverage grade and an enforcement status

AI → Compliance → OWASP Gen AI: live coverage of the Agentic and LLM Top 10s, mapped to findings observed on this host. Coverage and enforcement are graded separately, and categories that depend on a configured divergence model say so rather than guessing. AI feature documentation.

MITRE ATLAS. The attack-pattern detections carry MITRE ATLAS technique references alongside the OWASP ids in the same reference string — the credential-harvest detection cites AML.T0055, AML.T0083 and AML.T0090, for example. To be precise about what that is: technique-level tagging on the attack-pattern findings, so they can be pivoted in ATLAS-aware tooling. It is not a full ATLAS crosswalk, and we would rather describe what exists than imply more.

Agentic trust controls. The same findings are attributed to the trustcontrols.ai Agentic Trust Controls catalog — 61 controls across 12 domains, cross-mapped by its publisher to ISO/IEC 42001:2023 and ISO 27001:2022. So a finding tagged LLM02 lights up the OWASP row and every trust control that cites LLM02, with the ISO clause attached: least-privilege tool scoping, tool and MCP definition integrity, behavioural telemetry generation, loop and recursion bounds. That is what turns a host alert into something a governance conversation can use.

EDAMAME Security AI tab, Compliance subtab: the Trust Controls Scorecard showing the Agent Identity and Authority domain with controls AID-01 through AID-08, each with live alertable counts, coverage grade and enforcement status

AI → Compliance → Trust Controls: the trustcontrols.ai Agentic Trust Controls catalog, evidenced by findings observed on this host, with the publisher's ISO/IEC 42001 and ISO 27001 mapping on every row.

Vanta. Separately and at the device layer, EDAMAME streams continuous endpoint posture into Vanta instead of screenshots and point-in-time checks. Worth keeping the two straight: the Vanta integration carries device posture evidence; the OWASP and trust-control scorecards are the agent-layer view inside EDAMAME. Both are evidence, and neither makes anyone certified — what they do is prepare you for a direction of travel that is now unmistakable. The EU AI Act's logging and traceability obligations, ISO/IEC 42001, and auditors asking about agent accountability under SOC 2 all converge on the same question, and it is a runtime question: can you prove what the AI agent actually did?

Why Netskope

Because the argument for this split is not only ours. In June 2026, Netskope Field CTO Steve Riley argued that agents deserve a place in every Zero Trust strategy, and described EDAMAME as a platform that “observes coding agents independently, from outside the agents themselves… enforces posture-gated access when intent diverges from activity or attack patterns appear, such as when code starts touching credentials or sending unauthorized data.”

That is a description of exactly the two outputs above, written by someone at a company whose Threat Labs data opens this post. Riley's piece named the model; this integration is the wiring that makes it operational in a Netskope tenant. Netskope decides what a tagged device may reach; EDAMAME decides, continuously and from the host, whether the device and its agents still deserve the tag.

Set it up

The full walkthrough is in the Netskope setup guide. In outline:

Create a Netskope REST API v2 token with read and write access to the device-tag endpoints. EDAMAME calls exactly two of them.
Create the device tag — a device tag, not a device classification; the two are separate systems with separate id spaces and identical-looking names, and confusing them is the most common setup mistake. Name it for what it means, such as EDAMAME-Compliant, since it marks devices that pass.
Wire the tag into a Device Classification rule and a Real-time Policy, allow-on-tag. Validate with one device before rolling out.
Create the conditional access in EDAMAME Hub under Policies → Conditional access, with your tenant hostname, the token and the tag name. Creation validates all three together, so it either works or fails cleanly — there is no half-configured state.
Attach it to a policy: set the conditions a device must satisfy — a minimum score, and the AI Agent Posture checks you care about — and link the Netskope conditional access to that policy. From that point on, devices that satisfy the policy receive the tag and devices that fall out of it lose it.

Steps 1 to 3 live entirely inside your Netskope tenant; steps 4 and 5 are in Hub. One device-side prerequisite is easy to miss: the integration matches devices by their Netskope identity, which EDAMAME reads from the Netskope Client's own provisioning store. That store is root-owned, so the EDAMAME helper must be installed on macOS and Windows, and edamame_posture must run as root on Linux and in CI. A device that cannot report a Netskope identity is skipped silently — and under allow-on-tag, skipped means denied rather than accidentally allowed.

Get started

Download EDAMAME Security — free for macOS, Windows, Linux, iOS and Android; four users per tenant on the free plan.
EDAMAME Posture — free CLI for CI/CD runners, self-hosted agent hosts and headless servers.
See the agent side on the EDAMAME agents page, with a short demo on a Cursor session that applies identically to Claude Code, Codex, OpenClaw and Hermes: youtu.be/zAN4u7ImWrU
The other conditional-access providers, same model: Zero Trust access with live posture evidence.
Running Netskope and want to walk this through on your own tenant? Book a slot on our calendar.

Sources

All AI-adoption, data-policy-violation and malware-delivery figures: Netskope Threat Labs Report: Europe 2026, based on aggregated Netskope One platform usage across a subset of European customers, 1 March 2025 to 31 March 2026.
Integration setup and mechanics: Setting Up Netskope for Access Control Integration (EDAMAME integrations wiki).
Agents in Zero Trust, and the description of EDAMAME quoted above: Steve Riley (Field CTO, Netskope), “Agents Deserve a Place in Every Zero Trust Strategy”.
Taxonomies: OWASP Top 10 for Agentic Applications 2026, OWASP Top 10 for LLM Applications 2025, MITRE ATLAS, trustcontrols.ai Agentic Trust Controls.
Device and agent checks, with their CIS / ISO 27001 / SOC 2 references, are open source: github.com/edamametechnologies/threatmodels.
Intent-divergence research: Lyonnet, Clerget, Salamatian, “Runtime Security for Agentic Systems” (HAL, 2026), joint work with the LISTIC laboratory (CNRS).