New Agent Every Month. New MCP, New Tools Every Week. Still in Control.

A new agent every month. Cursor, Claude Code, Codex, Hermes and OpenClaw are the ones on most developer machines today, and next month there will be another. New MCP servers and new tools every week: the agents already installed declare a server nobody had listed, pick up a skill, reach a service they did not reach last week, for a use case nobody wrote down in advance. Most of the useful work with agents in 2026 happens in that unforeseen space, and it moves faster than any policy can be rewritten. 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, still in control, which is what EDAMAME and the new AI Governance page in EDAMAME Hub are built for. It has three parts. Discover every agent from outside the agent, with nothing installed inside it, and with it every MCP server and tool the agent can reach. Audit what you found in the vocabulary your auditors already use, framework by framework. Govern the exceptions approved for a specific condition rather than by switching off a check: when a new agent or a new MCP server trips a check, you approve that one condition on that one agent, and everything else the check covers stays enforced. Together, the three let a team take this month's agent and next week's MCP servers and tools without giving up control of what any of them is allowed to reach. The post closes with how this compares with the other ways the market is approaching the same problem, because most security leaders are now being asked to evaluate several of them at once.

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/CD runner or on any server running AI agents, cloud or self-hosted, 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 CI/CD runners and on any server running AI agents, cloud or self-hosted, so the inventory is one inventory across the laptop, the pipeline, the cloud VM 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? Every AI posture check now 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 lists those AI frameworks as filter chips next to CIS, SOC 2 and ISO 27001, groups a threat's tags per framework with a count, and shows pass or fail per check. Pick ISO/IEC 42001, and you 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.

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 Agents section (Frameworks) 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.

Approve specific exceptions, never switch off the check

Here is the part that makes it possible to say yes to the next agent. 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 conditions 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 AI Governance overview in EDAMAME Hub: one score for the fleet, the posture trend, and the runtime findings the devices reported, agent and device named on each line.

The rule underneath is the one to take away: exceptions are approved for a specific condition, never by switching off the check. A check such as "unconfined agent with a dangerous blast radius" can fail for many different reasons on many different devices, and switching the check off to unblock one team would hide all of them. So when a team adopts a new agent this month, together with an MCP server nobody had listed, that specific condition surfaces in Recurring evidence and in Not permitted, where the Hub lists each such condition as a cause. The administrator reviews it and either approves that condition on that agent, from the device's AI posture card, or allows the agent or server in an allowlist. Every other condition 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.

Framework exposure, recurring evidence and the not-permitted list: the same condition on many devices is cleared by one exception, approved for that condition and never by switching off the check.

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: three allowlists instead of a pre-approval queue

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 EDAMAME Posture network allowlist on CI/CD runners and the servers, cloud or self-hosted, that run agents: 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 detects the harness and reports agents still running unconfined next to it.

That last point is the one that makes the whole model safe to open up. The harness divergence check reports that an installed control plane is not actually confining the agent, and two 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 that agent runs unconfined next to its harness or weakens its own guardrail. 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: eleven deterministic checks, among them token exfiltration, skill supply chain, sandbox exploitation, credential harvest, file-system tampering, sensitive-material egress, agent control tampering, denylist bypass and process memory scrape. They are held to a fail-closed release gate of 23 attack scenarios on four platforms (September 2026), after a clean ten-minute idle baseline. 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.

How this compares with the rest of the market

The premise is no longer contested. The largest endpoint and platform vendors now say it in their own words: the agent rather than the prompt is the threat, and the endpoint is where its actions happen. CrowdStrike's category paper, Palo Alto Networks' agentic endpoint security module and Microsoft's Agent 365 have each moved onto that ground this year, and a crowded field of gateways, guardrails, identity platforms and observability tools is working the same problem from other positions. What separates the approaches is where they sit and what they treat as evidence. Here is the map, and where EDAMAME stands on it.

• Endpoint platforms extending into AI. The EDR and XDR vendors bring their existing sensors to the agent, shipped by MDM to the managed fleet, with verdicts from fleet-learned taxonomies of known techniques; Microsoft's Agent 365 discovers local coding agents on Windows devices and blocks them by Intune policy. EDAMAME is user-up and reporting-only: the developer installs it, no MDM enrolment is needed, and it therefore covers the BYOD, contractor, macOS and Linux machines, CI/CD runners and self-hosted agent hosts a managed fleet never enrolled, which is exactly the population where new agents appear first. Its verdict does not come from a taxonomy. It comes from whether what the machine did matches what the agent said and what the human asked, so a novel attack that appears in no signature set still produces divergence if it has a host-observable effect.

• AI gateways, proxies and prompt firewalls. Network and SSE vendors, and the standalone AI firewalls, inspect prompts and AI traffic inline at a gateway. Much of what an agent does never reaches a gateway: a shell command, a file read, a local stdio MCP call, an npm post-install script executing on the laptop. EDAMAME sits on the host where those actions are visible, and it does not inspect prompts; prompt injection is caught by its effect, sensitive data reaching an untrusted sink, whatever text caused it. This is also why we complement Netskope rather than compete with it: the proxy owns the inline decision, and EDAMAME supplies the host and agent evidence that decision consumes.

• In-agent guardrails, sandboxes and governance runtimes. The agent's own permission model, sandboxes such as nono and Anthropic's srt, and control planes such as AgentField and Rippletide decide what an agent may do from inside the agent, before execution. EDAMAME does not replace them. It detects the harness you run, reports agents still running unconfined next to it, treats a present harness as a reason for more confidence in a finding rather than an excuse for it, and reports the moment an agent weakens its own guardrail. The in-agent control and the outside observer are two different things, and a fleet needs both.

• Agent identity and access platforms. Microsoft Entra Agent ID, Okta for AI Agents and the non-human-identity vendors give the agent an identity, an owner and a scoped credential. They answer who the agent is and what it may access. EDAMAME answers whether the machine that holds those credentials is still trustworthy and what the agent actually did with them, and feeds that answer back to the identity layer as a conditional-access signal. A natural pairing, not an overlap.

• Cloud-managed agent runtimes. OpenAI Codex's sandbox and approval policies, AWS Bedrock AgentCore, Google's Gemini Enterprise controls and Microsoft Foundry secure the agent path the platform hosts. Most of the risk that reaches code, secrets and production still runs through machines the platform does not host: developer workstations, self-hosted runners, local agents. Those machines already hold the tokens, the repo cache and the SSH keys. That is EDAMAME's lane.

• Agent observability and compliance platforms. LangSmith, Langfuse and their peers trace prompts and tool calls from inside the application; compliance platforms collect and organise the evidence. A trace is the agent's own account of itself. EDAMAME consumes the same traces as one plane, corroborates them against host evidence, and exports the result into the compliance trail, with Vanta as the shipped integration.

Put the map together and the differentiators are concrete:

• Discovery from outside the agent, with nothing installed inside it, on every machine an agent runs on, including the ones IT never provisioned.

• Evidence rather than narrative. The transcript is a claim, host telemetry is the evidence, and the human's own instruction is the policy: the ground truth of what the agent actually did, which the agent cannot fake or silence.

• An observer the agent cannot switch off, enforced by shipped checks: read-only observer state, operator-only dismissals, a floor of findings no adjudicator can clear, and an agent that weakens its own controls is itself a finding.

• Harness coverage, not only harness presence. EDAMAME detects the harness you already run and reports agents still running unconfined next to it.

• Runtime and posture together, audited in six frameworks. OWASP GenAI Agentic and LLM, MITRE ATLAS, Agentic Trust Controls, ISO/IEC 42001 and ISO 27001 on every AI check, with coverage stated as coverage.

• Specific exceptions, never a switched-off check, with allowlists that are scoped, expire, start audit-only and become restrictive when you decide.

• Response where it cannot be forged. Nothing is blocked on the workstation, by design; the finding pulls the host's access at the Zero Trust layer, Netskope first, and halts the CI pipeline.

• Local-first data. Transcripts and inventories stay on the device, the Hub receives check states, and adjudication can run on a local model.

• Published numbers. Eleven deterministic checks held to a fail-closed gate of 23 attack scenarios on four platforms (September 2026), after a zero-finding idle baseline. We would welcome the same from every vendor now entering the category.

The scope is equally plain. EDAMAME covers the endpoint, meaning macOS, Linux and Windows workstations, CI/CD runners and any server running AI agents, cloud or self-hosted, and hands its evidence to the SSE, identity and compliance layers you already run. It does not inspect prompts inline, it does not cover agents hosted inside SaaS applications, and it blocks nothing on the workstation. Each of those is a design decision with its reason given above. On the AI-agent use case itself — knowing every agent on every machine, judging what each one did against what it said and what it was asked, auditing that in the frameworks' own vocabulary, and approving specific exceptions without rewriting history — we believe the evidence-first design is ahead, and we publish the numbers that let anyone check.

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, audit and specific exceptions fit together on the AI governance 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 are comparing approaches for your own agent fleet, I am happy to walk through the map above on your machines rather than on slides. My calendar is open.