When the AI Agent Diverges, the Netskope Tag Comes Off

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 behavior 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 organizations 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 organization-managed AI rose from 28% to 72%. But the share of users switching between personal and enterprise accounts rose from 7% to 15% over those same twelve months, which the report reads as shadow AI persisting rather than closing.

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 organizations, 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 organizations.

Put those three findings next to each other and a specific picture forms. The AI rising fastest in Europe is 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 behavior 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 absence of a valid tag denies. Because EDAMAME tags devices that pass, the customer policy should grant access when the tag is present. A device that has never received the tag is therefore denied. The inverse polarity, treating the tag as a block signal, inverts its meaning and fails open. This policy shape is fail-closed for untagged devices; it is not a guarantee across every operational failure. If the Netskope API token expires, EDAMAME can no longer update tags and each device keeps its existing state. A device without usable Netskope identity is skipped, and there is no fleet-wide reconciliation pass. Rotate the token before expiry and monitor skipped identities rather than describing the integration as universally fail-closed.

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. Netskope allows at most five tags on a device; when all five slots are occupied, EDAMAME fails visibly rather than evicting another tool's tag.

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 → 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 behavior 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.

• Behavioral 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 behavior 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 behavior, 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.

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. EDAMAME Security now ships a read-only MITRE ATLAS Detection Coverage Map for the 39 parent techniques across 12 tactics that a runtime host and network observer can witness. Each row carries its own AML.T... tags, live findings, a strong / partial / indirect grade, and the telemetry rationale behind that grade; the credential-harvest detection cites AML.T0055, AML.T0083 and AML.T0090, for example. ATLAS is independent detection evidence, while the OWASP labels are cross-references. This is the runtime-observable subset, not the complete 170+ published ATLAS matrix, a certification, or an endorsement.

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, behavioral telemetry generation, loop and recursion bounds. That is what turns a host alert into something a governance conversation can use.

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 — disclosing in the same sentence that Netskope's chief development officer and chief scientist advise us — 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. A new untagged device is denied under allow-on-tag; an already-tagged device can retain stale state until identity and reconciliation recover, so monitor skipped identities explicitly.

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).