Two things shipped in the first two weeks of April 2026 that, taken together, describe an incident scenario the agent ecosystem has no vocabulary for.
The first is MMX-CLI — MiniMax's seven-modality command-line tool. An agent can invoke it to generate text, image, video, speech, music, code, and document output. It is not the first multimodal CLI. It is the first to treat all seven as peer capabilities with the same calling convention. Any agent framework that can spawn a subprocess can now produce synthetic voice and synthetic video with a single tool call.
The second is Claude Code Routines — Anthropic's April release that lets an agent run on a cron schedule on Anthropic's infrastructure. The developer's machine does not need to be on. The developer does not need to be awake. The routine fires, the agent executes, the results materialize somewhere on the internet.
Put them together. An agent, running on somebody else's computer, on a schedule, with tools that produce synthetic audio and video, with no human in the loop and no governance layer between the LLM and the output.
This is not a prediction. It is available today.
The ecosystem's blind spot
The conversation about agent safety has been, until now, about what the agent says. Prompt injection. Jailbreaks. Hallucination. These are input-side and output-side problems, and they are tractable with input-side and output-side tools — content filters, system prompts, eval harnesses.
What shipped in April is different. It is not about what the agent says. It is about what the agent does. And "does" now includes:
- Producing artifacts that are indistinguishable from human-made media.
- On a schedule, at a cadence, without supervision.
- From an execution environment the developer does not control.
There is no existing layer in the stack that governs this. Frameworks orchestrate. Models generate. Tools execute. Nothing between the agent's decision to call mmx video at 3 AM and the video appearing on disk asks: should this agent, with this authority level, on this task, be allowed to do this right now?
Consequence tiers: the missing axis
When a thing an agent does has different downstream impact depending on the action, the governing layer needs to differentiate. A read of /tmp/scratch is not the same as a write to /etc/hosts. A GET to a weather API is not the same as a POST to a payment processor. A mmx text call is not the same as a mmx video call trained on a specific person's face.
The vocabulary for this is consequence tiers:
- CRITICAL — synthetic media involving identifiable people, financial transactions, production database writes, outbound messages to real recipients.
- HIGH — arbitrary shell execution, writes to configuration paths, network egress to untrusted destinations, model calls that consume paid credits above a threshold.
- MEDIUM — reads of sensitive paths, writes to the working repo, inference above a token ceiling.
- LOW — scratch I/O, idempotent reads, exploratory inference on cheap models.
A governance layer that does not distinguish between these is not a governance layer. It is a logging layer. The distinction matters because the controls that apply at each tier are different. CRITICAL should demand a second factor — a human in the loop, a signed artifact, a deterministic replay. LOW can run on the cheapest path with minimal audit.
Earned authority: the only model that scales
The conventional approach — declared authority — is the model that frameworks ship with today. The developer writes a config: this agent can access these paths, these networks, these tools. The config is evaluated at deploy time. The agent runs.
Declared authority has two failure modes, both of which MMX-CLI plus Routines makes acute:
It is static. The agent's behavior does not affect its authority. An agent that has successfully completed a thousand routine tasks has the same access as an agent that has been wrong about every decision it made yesterday.
It is generous. When the developer sits down to write the config, the path of least resistance is to over-grant. Deny lists are painful; allow lists are painful; the easy thing is to give the agent "whatever it needs." In a routine that fires at 3 AM, "whatever it needs" is the same as "whatever it asks for."
The alternative is earned authority. An agent starts at minimum access. It is observed. Decisions are captured. Over time, as the agent demonstrates correct behavior, its access expands — measurably, against a batting average, with regression detection. A single egregious mistake drops it back to a lower tier.
This is not a new idea. It is how every human organization above a certain size handles new employees. Trust is demonstrated, not declared. The reason it does not exist in agent frameworks yet is that tracking conduct requires a governance layer with memory — a thing that exists in a different process, survives across routine invocations, and is not in the agent's control.
The architectural airgap
There is a third piece of vocabulary worth naming now, because without it the earned-authority argument collapses.
If the dangerous code path — the one that invokes mmx video, the one that writes to /etc, the one that POSTs to Stripe — exists inside the agent's own process, then a sufficiently adversarial prompt can reach it. The agent's process is a single trust domain. Anything inside that domain is reachable from anywhere else inside that domain.
The architectural airgap is the security property where the code paths for dangerous operations do not exist in the agent's process at all. They live in a different binary, in a different PID, communicated with over a socket. The agent can ask for them. The governing process decides whether to honor the ask. If the code is not in the agent's memory, no prompt — however clever — can execute it directly.
This is what "in-process middleware" cannot give you. A policy engine that lives inside the agent's Python or Node runtime shares memory with the thing that is trying to misbehave. It can be patched, imported around, or simply disabled by code that the agent itself is free to execute. The only way to enforce is to not be there.
What this looks like for MMX plus Routines
Concretely, the scenario at the top of this piece becomes governable with three moves:
Classify the tool. mmx video is CRITICAL when the prompt references an identifiable person, HIGH otherwise. mmx text is LOW. The governance layer inspects the argv before the subprocess runs, not after.
Gate by earned authority. A routine's agent starts UNKNOWN. It may not call CRITICAL tools at any tier until it has completed N successful LOW and MEDIUM tasks without regression. When it does call a CRITICAL tool, the call is held for a second factor — a human approval, a signed manifest, a cryptographic token.
Make the code path absent for untrusted agents. The binary that is installed on the routine-executing machine does not contain the ability to invoke mmx video with identifiable-person prompts unless the license tier for that agent permits it. Not configurable. Not feature-flagged. Structurally absent.
None of these three are provided by MMX-CLI. None of them are provided by Routines. None of them are provided by the agent framework sitting between them. The governance layer has to live below all three, and it has to be the same layer regardless of which framework or which tool is in play.
The vocabulary, collected
For the conversation about agent governance to move forward, the words have to mean specific things:
- Trust boundary — the interface between a component and the capabilities it can invoke. Every capability call crosses it.
- Architectural airgap — the property where code paths for sensitive operations do not exist in the agent's process.
- Consequence tier — CRITICAL, HIGH, MEDIUM, LOW classification of the downstream impact of an action.
- Earned authority — access level derived from demonstrated correct behavior, not declared configuration.
- Conduct engine — the component that tracks agent behavior over time and adjusts authority accordingly.
- Decision frame — the captured record of every governance decision: who asked for what, what was granted, why.
These are not Seawater's terms exclusively. They are the terms anyone who wants to discuss this precisely will need.
MMX-CLI and Routines did not create the governance gap. They made it impossible to ignore.
— James Ford, Equilateral AI