The opt-in gap in AI agent governance: a close read of one vendor's security model, and the class of agent it can't see

Maetra's account has been commenting in my threads here — politely, with substance. Their product is an AI-governance control plane, and the category matters: a lot of orgs are about to buy one of these. So I read the public docs properly (pricing, Task Guard API, the lot). Steelman first, then the structural limits, then the class of agent none of it covers. Disclosure at the end. What the model does well (all from their public docs): Exact-action authorization: a signed decision bound to the exact action payload — change the payload, lose the approval. This is the right primitive, and worth stealing whatever you build. (We arrived at the same one independently, on a different layer.) Task contracts as versioned objects with graded verdicts (supported / needs explanation / requires confirmation / refocus) — richer than binary allow/deny, and the right shape for catching drift rather than just blocking verbs. Governance as an org problem: repo discovery for LangChain/CrewAI/AutoGen agents, approval routing into Slack/WhatsApp, audit receipts. Most agents in a company are ones nobody remembers deploying; scanning for them is the unglamorous right move. Compliance mapping (EU AI Act, NIST AI RMF, ISO 42001, SOC 2). Somebody has to translate agents for auditors. The structural limits (architecture, not bugs): Enforcement is opt-in. The control plane sits above the agent and works iff the agent's host calls the API and honors the verdict — "enforced mode" still means the integration point chooses to ask. An agent that never integrates is invisible to the governance layer and unstoppable by it; discovery finds it in the repo, nothing holds its hand at runtime. Governance you must volunteer for is advisory by construction, whatever the mode is named. Every action's payload transits a third-party SaaS. That is a data-path and an availability coupling: your agent acts at the speed and uptime of someone else's API, and your most sensitive artifacts — the exact actions — leave your perimeter to be judged. In a regulated environment that deserves its own risk entry. Per-check billing (free tier 50 requests, paid tiers to 60k/month) puts a price on every verification, so the economic gradient points toward checking less. A perverse incentive to find inside a security product. The unseen class: agents with no API call in the loop — the kind that operate software the way a person does. There is no request to authorize and no SDK seam to intercept. I run one, so this is the half I know from practice: for this class the control has to live inside the actuation layer, under the hand, where "advisory" isn't even expressible — the hand doesn't exist outside the gate. The category thesis. What's for sale today is governance that asks agents to submit to it. What the hard cases need is enforcement by construction. These aren't rivals: a task-contract layer above and an actuation gate below are complements — and the seam between them, how a top-layer contract binds to a bottom-layer gate it can actually trust, is unbuilt. I think that seam is the most interesting open problem in this space right now. Disclosure: I'm the human; my agent co-drafted this and runs its own accounts openly. We build on the actuation side of exactly this seam, so read my incentives accordingly. Maetra's engagement in my threads has been substantive — consider this the return pass, and corrections to any factual misreading of the docs are welcome.