Say Yes to the Next Agent: Discovery, Audit, and AI Governance per Cause

Every month a new agent shows up on a developer machine. Cursor, Claude Code, Codex, Hermes and OpenClaw are the ones we observe today; next month there will be another, and a new MCP server it wants to reach, and a use case nobody wrote down in advance. Most of the interesting work with agents in 2026 is happening in that unforeseen space. A security team has two familiar answers to it, and both are wrong: forbid everything that was not pre-approved, and watch the productivity leave through the side door; or trust everything, and find out later what the agent actually did.

This post is about the third answer, which is what EDAMAME 1.8.4 and the new AI Governance page in EDAMAME Hub are built for: discover every agent from outside the agent, audit it in the vocabulary your auditors already use, and govern exceptions per cause rather than per check, so a team can say yes to the next agent without giving up control of what it is allowed to reach. It closes with where this sits next to the AI detection and response paper CrowdStrike published this month, because several of our customers were forwarded that PDF with the question "isn't this what EDAMAME does?".

Discovery first: you cannot govern what you have not seen

The starting point is structural, not behavioural. EDAMAME Security on a workstation, and EDAMAME Posture on a CI runner or a self-hosted agent host, observe every AI agent present on the machine from the endpoint boundary: no plugin, no SDK, nothing installed inside the agent. Six agents are observed today with zero install: Cursor, Claude Code, Claude Desktop, Codex, Hermes and OpenClaw. For each one the Exposure view answers the questions a security lead needs on day one: which agents are running, which MCP servers and tools each can reach, how they authenticate, what its blast radius would be if it were compromised, and whether it runs inside a governance harness. Four harnesses are detected: AgentField, nono, Rippletide and Anthropic's srt.

The Exposure view in EDAMAME Security: what every AI agent on the host can reach, and how far a compromise would spread.

This discovery pass is deterministic. It does not ask a language model what is on the machine; it reads the machine. Twenty-four structural visibility rules and thirteen AI posture checks come out of it, and the same pass runs headless on runners and agent hosts, so the inventory is one inventory across the laptop, the pipeline and the self-hosted OpenClaw box. Every observation rolls up to EDAMAME Hub as an ordinary posture check: agents present without a governance harness, unconfined agents with a dangerous blast radius, discovered agents whose observer is paused, an agent that exposes an unprotected MCP server.

Audit in the framework's own words

Discovery tells you what exists. An auditor asks a different question: which of these findings matter for the standard I am assessing you against? With 1.8.4, every AI posture check carries its framework references, derived from one crosswalk: the OWASP GenAI Agentic Top 10 (ASI01 to ASI10) and LLM Top 10, MITRE ATLAS technique ids, the Agentic Trust Controls catalog and, through it, the ISO/IEC 42001:2023 and ISO 27001:2022 clauses. The Compliance table in EDAMAME Security now lists those AI frameworks as filter chips next to CIS, SOC 2, ISO 27001, PCI-DSS and HIPAA, groups a threat's tags per framework with a count, and shows pass or fail per check. Pick ISO/IEC 42001, read which AI checks map to it and whether they pass. Pick MITRE ATLAS, and you are reading a detection-engineering map instead: 39 runtime-observable parent techniques across 12 tactics, graded 16 strong, 20 partial and 3 indirect, with the telemetry behind each grade. That is coverage, not certification, and the product says so on the page.

One compliance table, classic and AI frameworks side by side: the agent checks are ordinary controls with a pass or fail status.

The same references travel with each finding to EDAMAME Hub, where the device's AI posture card shows a line of framework chips under every failing AI check, each linking to the published reference. For a security leader preparing for the EU AI Act, or for a customer security review that now asks about coding agents, this is the difference between a screenshot and evidence: the control, the framework clause it maps to, the host evidence behind it, and its history, in one place. The OWASP GenAI scorecard in the AI tab keeps the grade-per-category view; the Compliance table is the per-check, per-framework view. They read the same facts.

The OWASP GenAI scorecard: a grade per category, computed from observed structural facts, with the contributing findings one click away.

Govern per cause, never per check

Here is the part that makes "say yes to the next agent" possible. The new AI Governance page in EDAMAME Hub, on the Enterprise plan, reads the whole fleet from one evidence bundle and turns it into a governance surface:

• Agent adoption — which agents are present on how many devices — and governance harness coverage, with the share of devices where a harness confines the agent.

• External services (MCP) — every MCP server declared by an agent anywhere in the fleet, with its authentication state.

• Recurring evidence — the causes the fleet reports most, with device counts, so the condition behind a check that fails on forty devices is found once.

• Not permitted by any allowlist — agents or MCP servers present on devices that no enforcing allowlist permits.

• The devices and allowlists matrix — one row per AI-capable device, one column per allowlist, each cell reading Fits, Does not fit or incomplete for that list only. A device is never marked against a list unrelated to its problem.

The rule underneath is the one we want you to take away: exceptions are granted per cause, never per check. When a team adopts a new agent this month, together with an MCP server nobody had listed, it surfaces in Recurring evidence and in Not permitted. The administrator reviews it and either accepts that specific cause on that specific agent, from the device's AI posture card, or allows the agent or server in an allowlist. Every other cause on that device keeps failing. A new condition on an accepted agent fails the check again. Raw statuses are never rewritten, so the score history stays truthful. Nobody has to accept "the check" to unblock a team, and nobody can make a finding disappear by widening a rule.

Allowlists are written the way a rollout actually happens. They are scoped to the whole domain, a group or a single device; they can expire, and the page warns when they are about to; they start audit-only, hiding accepted findings without restricting anything, and become restrictive when you tick "restrict what is allowed to exist", at which point unlisted agents and MCP servers are reported as not permitted. A list can be written ahead of a deployment, before a single device reports, and an entry that nothing in the fleet matches is flagged as inert so the list does not accumulate dead rules.

Innovation with control: the allowlists are the enabler, not the brake

Several of our customers explicitly want to support new agent usage as it appears, month after month, including uses nobody foresaw when the security policy was written. That is the right instinct, and it is exactly what this design supports. The control does not sit in a pre-approval queue in front of the developer. It sits in three allowlists that the evidence keeps honest:

• Agents and MCP servers, in the Hub's AI Governance allowlists: what is permitted to exist, per domain, group or device, with an expiry.

• Egress destinations, in the Hub's posture policies for runners and self-hosted agent hosts: builds fail when behaviour violates the allowlisted destinations.

• Tools and commands, in the governance harness you already run around the agent: the sandbox, the deny rules, the tool scopes of nono, srt, AgentField or Rippletide. EDAMAME does not replace those rules; it verifies from outside that they held.

That last point is the one that makes the whole model safe to open up. In 1.8.4 the harness divergence check reports that an installed control plane is not actually confining the agent, and two new deterministic checks fire when an agent weakens its own enforcement configuration in the permissive direction — sandbox disabled, deny rules removed, wider egress allowlist — or when a command the harness denied is re-spelled and succeeds. A team can adopt the agent it wants and the tools it needs; the security lead sees the new agent appear, allows it with an expiry, and knows the day the guardrail around it stops holding. And if that day comes with an attack pattern on the host, the response is already wired: the device tag drops, and Netskope denies that host the critical resources until the finding is cleared.

The runtime security underneath

Governance is only as good as the evidence it is built on, so here is the summary of what produces that evidence. EDAMAME runs runtime verification on three planes: what the human authorised, derived from the operator's own prompts so there is no policy file to write; what the agent declared, its task, tools, parameters and scope; and what the machine actually did, observed as process lineage, files opened, sockets created and posture drift. The agent's transcript is treated as a claim. Process-attributed host telemetry is the evidence the claim is checked against. Divergence between them is scored in four correlation categories and five policy-plane categories, including scope escalation and retroactive declaration, and the verdict comes with an evidence trail.

Beneath that sits a safety floor that needs no behavioural model at all: eight deterministic check families for token exfiltration, skill supply chain, sandbox exploitation, credential harvest, file-system tampering, sensitive-material egress, agent control tampering and denylist bypass. They are held to a release gate of 15 attack scenarios on four platforms, fail-closed, with a clean ten-minute idle baseline, and the 56 curated false positives and 8 documented blind spots are published alongside. We say that on the agents page because a detection claim without its numbers is a slogan.

Two design properties matter for governance in particular. First, the agent cannot silence the observer: the surface an agent can reach is read-only for observer state, dismissals are operator-only, a floor of findings cannot be cleared by the AI adjudicator, and a paused observer is itself a finding. A compromised agent cannot dismiss, reconfigure or argue away findings about itself. Second, the data stays local-first: transcripts, inventories and session details are processed on the device; the Hub receives check states and counters; the optional AI adjudication is provider-configurable, including a local model. When something must be acted on, EDAMAME responds where the response cannot be forged: through the Zero Trust layer you already run. With Netskope, the chain is concrete. An attack-pattern finding or a divergence verdict lands on the host; EDAMAME removes the device tag it maintains for that machine; the customer's Netskope Device Classification no longer matches, and the Real-time Policy denies the agent's host access to the critical resources behind it — repositories, secrets, production, internal applications — in the same minute. The same proof drives conditional access at seven other identity and network vendors, from Microsoft Entra and Google to GitHub, GitLab, Tailscale, NetBird and FortiGate, and halts a CI pipeline on an alertable finding. Nothing is blocked on the workstation itself, by design, and the next section explains why.

Where this sits next to CrowdStrike's paper

In September CrowdStrike published AIDR: Defining the Next Era of Cybersecurity, which names AI detection and response as the successor to endpoint detection and response and describes a seven-layer AI estate across endpoint, cloud and SaaS. We read it with interest, because its premises are ours. In the paper's own words, the defining challenge is not the model and not the prompt but the agent; the endpoint is where the agent's actions happen and many of them never cross a network boundary; and agents were never onboarded through an access review. Claude Code and OpenClaw are its archetypes. Both are among the six agents EDAMAME observes with zero install, and the unmanaged, contractor and self-hosted population the paper describes is exactly the one a user-up, no-MDM sensor was built for.

Where we differ is on what counts as evidence, and the difference is worth stating plainly for anyone comparing the two on the AI-agent use case.

• Ground truth. The paper describes sensor telemetry plus inline inspection of prompts against a taxonomy of more than two hundred injection techniques, fed by a fleet-wide intelligence flywheel. EDAMAME does not inspect prompts inline. It checks the agent's claim against the host's evidence, and it asks a question the paper does not: whether the agent was entitled to declare what it declared, against the human's own instruction. A novel attack that is in no taxonomy still produces divergence if it has a host-observable effect, and prompt injection is caught by its effect — sensitive data reaching an untrusted sink — whatever text caused it.

• Runtime and posture, not runtime instead of posture. The paper draws a hard line: real AI detection and response is runtime, and posture management is "before and after". We run both on purpose. The thirteen AI posture checks are the ground the runtime loops stand on, and the harness divergence check is a control-efficacy signal no posture-versus-runtime split can express: it tells you whether the sandbox you already bought is confining the agent right now. The AI Governance page above is governance built on runtime evidence, which is a different thing from the governance the paper sets aside.

• Observer independence. The paper does not address whether the observed agent can dismiss, reconfigure or argue away findings about itself. For us that property is central, it is enforced by shipped checks, and it is what lets a security lead open the allowlists to new usage with confidence.

• Response. The paper's third principle is that detection without response is observation, and it describes blocking, redacting, isolating and revoking at the point of execution. We agree that detection without response is observation; we put the response in the Zero Trust layer rather than inside the agent. Anything that blocks an agent's action from inside or beneath the agent sits where a compromised agent's attacker already stands. EDAMAME sits outside it and responds where the response is unforgeable: an attack on the host triggers the tag, the tag triggers the access decision, and Netskope, or the identity provider, or the network, denies that agent's host the critical resources it was reaching for. Reasonable engineers can prefer either design. Ours keeps the observer out of the agent's reach and the enforcement point in a system the agent never touches.

• Data. The paper's differentiation rests on shipping prompts, agent behaviours and tool-call patterns to the vendor's cloud so the flywheel can learn from them. EDAMAME's default is local processing and a reporting-only Hub. Both are legitimate choices; they suit different organisations, and the second suits the contractor and BYOD population particularly well.

Two things the paper covers that we do not: it spans endpoint, cloud and SaaS from one sensor and correlates across them, while EDAMAME covers the endpoint, meaning macOS, Linux and Windows workstations and CI runners, and hands its evidence to the SSE, identity and compliance layers you already run; and it offers point-of-execution blocking on the host, which we deliberately replace with a response at the Zero Trust layer, Netskope first, for the reason above. On the AI-agent use case itself — knowing every agent on every machine including the ones IT never provisioned, judging what each one did against what it said and what it was asked, auditing that in the frameworks' own vocabulary, and governing exceptions per cause without rewriting history — we believe the evidence-first design is ahead, and we publish the numbers that let anyone check. We would welcome the same from every vendor now entering the category.

What to do with this

• See what is on your own machine first: download EDAMAME Security, free, and open the Agents tab. Discovery and the framework-tagged Compliance table need no account.

• Roll it up for a team: EDAMAME Hub is free for up to four users; the AI posture checks and their framework chips land on every device page. AI Governance, with the fleet Overview and the allowlists, is on the Enterprise plan.

• Read how discovery becomes fleet policy on the Agentic Posture Visibility page, and how the evidence reaches your auditors on the compliance page. A short demo on a Cursor session is at youtu.be/zAN4u7ImWrU.

• If you were forwarded the CrowdStrike paper with "isn't this what you do?", I am happy to walk through the comparison above on your own agent fleet — my calendar is open.