The Envelope Can Stand; the Authorization Cannot

Before the detail — Decision: let some actions stand pre-authorized inside a fixed envelope, and require a fresh decision for the rest, rather than treating “the agent is approved” as one standing yes. Outcome: MU-AI-011 reads and drafts without asking a person every time, and still cannot promote itself to the next rung on its own. Artifact: the four-rung table policy/envelope.json pins per action class, accepted when every tool the agent can call maps to exactly one rung. Status of what follows: a house construct — Meridian’s own labels — built on guidance that names the idea but publishes no rungs of its own. Demonstrated with NON-PRODUCTION classroom artifacts.

Prompt first: which of your approvals are standing, and which are fresh

For each tool my agent can call, tell me: does calling it again
require a new decision from a person, or does today's approval
cover every future call automatically? If you don't know, say so -
don't assume "it asked once" means "it will keep asking."

Most teams can answer this for one or two tools and not the rest, because “standing” and “fresh” usually live in someone’s memory of how the integration was set up rather than in a file. The prompt is shaped to surface that gap rather than paper over it with a guess.

Four rungs, one file

MU-AI-011’s action classes do not share one autonomy level. Each class maps to a pinned rung in policy/envelope.json, and the gateway evaluates every attempted action against that mapping:

These labels are Meridian’s house construct, not a standard. The nonbinding 2026-04-30 joint guidance, Careful adoption of agentic AI services, names “graduated autonomy” and rolling autonomy back but publishes no rungs; it reaches Meridian only if it is in the contract. Reading a ranking file needs nobody’s sign-off every time; sending a notice that reaches a crew’s handset needs a fresh one every time, no matter how many times the same notice has been approved before. Raising an action’s rung — letting pre_position_crew run unattended, say — is a change to this record, decided by the owner named in Lesson 1.1, not a setting an agent or an engineer flips in a config file.

The distinction is not about how much a rung trusts the model behind the agent. It is about how much of the world one unattended decision can move. A read cannot change anything, so a standing yes on it costs nothing to grant. A notice reaches a crew’s handset the moment it sends, so even a long, uneventful history of approved sends does not earn the next one a standing yes — the rung stays fixed at L0-never-autonomous regardless of how many times the action has gone well before.

Even the least sensitive rung earns its own line in the file rather than a default: a tool with no entry is denied, the same rule Lesson 1.3 applies to whole actions. Writing “read-only actions may run unattended” as a blanket sentence would let a future tool inherit a rung by category instead of by a decision someone made about that specific verb — the distinction Module 2 tightens into a number instead of a word.

A standing rung for read-only work and a fresh decision for the rest is the difference between an agent that is useful today and one that needs a person for every step.

What arrives already decided

AI Assurance 4.3 (a separate training in this series) answered “not yet”; the other three facts are inherited inputs to this NON-PRODUCTION lab:

Module 19 lesson 4’s allowlist covers CLI commands, not operational actions.

Before this module runs a new agent, the owner named in Lesson 1.1 checks that all four rows already have an answer — not because this training re-derives any of them, but because a missing one is a missing prerequisite, the same shape of gap the guard’s own step 0 refuses to run past.

The protocol carries the call; it does not authorize it

MU-AI-011’s actions travel through the Model Context Protocol (MCP) — the protocol agents use to call tools through a gateway — among other transports. The current MCP revision makes its own authorization layer optional, and says explicitly that a transport carried over standard input and output should not attempt to follow it at all: an agent running as a local command-line process gets its credentials from its environment, not from anything the protocol negotiates. That single fact kills a tempting shortcut — “the agent talks MCP, so MCP authorizes what it does” — because for exactly the transport a local CLI agent uses, the protocol says the opposite.

What authorizes the call is the gateway this training builds in the next module: the thing that reads the envelope, checks the rung, and decides before the request reaches a target. The protocol is how the request arrives; the gateway is what decides whether it proceeds. Confusing the two leaves an operator believing a protocol-level property is doing a policy-level job. The same holds for MU-AI-011’s other two transports: a loopback HTTP call and a local process call carry no authorization step of their own either, which is exactly why every transport in this training passes through the same gateway file rather than each choosing its own.

Stop and escalate when a new tool is proposed for MU-AI-011 and nobody can point to which rung in the table above it belongs on — a tool with no rung is a tool this training treats as denied, not as pending.

Key takeaway

Four rungs, four facts already settled elsewhere, and one protocol that carries requests without deciding them — this lesson maps where MU-AI-011’s authority can stand and names everything this training does not re-derive. The next lesson, The Action-Class Decision, turns the rungs above into an owner-accountable register: which action gets which class, and how many people sign for the ones that need it.

LEADERSHIP DECISION   autonomy is set per action class in a pinned
                      table, never inferred from what an agent asked
                      for last time
PRACTITIONER ACTION   check every tool an agent can call against the
                      rung table before it ships; anything unmapped
                      is denied, not pending
SUCCESS MEASURE       every tool in the envelope maps to exactly one
                      rung, verified at each policy change - audit
                      finding avoided