EAA Series · Control Analysis

Why Containers and MCP Are Not Delegated Authority

A six-dimension control matrix, and the shell-access thread that shows why none of the popular substitutes clear it.

Read

Every few weeks a claim resurfaces that a sandbox, a container, or a protocol has solved agent permissions. Below is a six-dimension framework for checking that claim, applied to two popular substitutes — the Model Context Protocol and git-native agent memory. Neither was designed to pass it, and the framework is offered as a working assessment tool, not a settled definition of what delegated authority requires.

Six dimensions to check

This is a proposed assessment framework, not a claim that these are the only six controls that could constitute enterprise delegation. It also leaves out questions a fuller treatment would need: who the delegating principal is, what the permitted purpose was at grant time, whether the agent may redelegate to another agent, and how revocation actually propagates. Within that scope, a system's claim to delegate authority is checkable against six questions, each answerable only by a party other than the agent itself:

Dimension The question it answers
Context provenance Where did the agent's belief about the world come from, and is that source attributable and tamper-evident?
Credential issuance Are the agent's credentials minted for this task, scoped to it, and short-lived and invalidated when the task ends — or is it holding a standing secret?
Tool authorization Is there a policy engine, independent of the model's own judgment, deciding which tool calls are allowed before they execute?
Egress enforcement Is outbound data movement actually gated at the boundary, or only the filesystem and process boundary?
Approval fail-closed semantics When a human-in-the-loop check errors, times out, or the reviewer is unreachable, does the action default to denied?
Signed/verifiable action evidence Is there a record of what the agent did that the agent's own self-report cannot alter or omit from?

Not every dimension applies to every system: an agent with no human-approval step in its design has nothing to score under approval fail-closed semantics. But where a dimension does apply, it has to hold independently of the others. A perfectly scoped credential used inside a tool-call policy with no egress control is a scoped credential with an open door; an approval workflow that only sometimes blocks when the reviewer is unreachable is not a fail-closed control, whatever it's labeled.

The adversarial case: gating shell access

A recent Ask HN thread on gating an autonomous coding agent's shell access is a useful way to see why isolation and authorization are separate questions, even for an agent with no protocol or memory layer involved at all — just a shell.

  • Command allowlists are a tool-authorization control. A filter that inspects a command string before execution is checking syntax, not the runtime effect of that command — a narrower guarantee than it's often sold as.
  • Containers and per-user Linux accounts are primarily isolation controls. That is a real and useful property, and container network policy can be configured to disable egress entirely, which does constrain the egress dimension when it's actually set. The failure mode is a container run with its default, unrestricted network still attached: isolation was configured, but the egress question was never separately asked or checked. The gap is in the assumption that isolation implies egress control, not in what containment is capable of.
  • A gate that only sometimes blocks when its human reviewer is unreachable is not fail-closed. Whether approval loops in practice degrade to fail-open under operational pressure is a risk worth designing against, not a claim this piece is treating as established.

The pattern holds without needing a survey to quantify it: a container alone does not establish delegated authority, because containment and authorization answer different questions, and a system can score well on one while being blank on the other.

Scoring MCP and git-native agent memory

This is a document-and-source review, not a deployment test of either system. Each cell below distinguishes three things: a specified requirement (the governing spec or schema mandates it), a documented capability (the project supports or enables it, without mandating it), and a control the reviewed evidence does not establish at all. A specified requirement is not the same claim as observed enforcement in a live deployment, and this review makes no claim about the latter.

Dimension MCP (protocol) Git-native agent memory
Context provenance No mandatory authenticated provenance mechanism. Tool and resource schemas carry no required source or trust metadata at the protocol level. Supports provenance, generation/verification, and lifecycle metadata; independent verification not established. The OKF v0.2 schema defines a sources field, a trust tier (generated vs. verified), and lifecycle metadata (stale_after), and the project's validator conditionally checks these fields when present. Supporting and conditionally validating a field is a narrower claim than every entry being required to carry authentic, independently verified provenance.
Credential issuance Mandatory once adopted, optional to adopt. Authorization itself is optional — the specification says so explicitly, and STDIO-transport implementations are told not to follow it at all and to retrieve credentials from the environment instead. But where an HTTP-based implementation does adopt it, the spec is not soft: servers MUST validate token audience, MUST reject tokens not issued for them, and invalid or expired tokens MUST receive an HTTP 401. The optional part is whether a given deployment turns this on, not what happens once it does. Not addressed. It is a knowledge store, not an identity system; it inherits whatever git and filesystem permissions the host already has.
Tool authorization The specification defines scope-based authorization and runtime scope-challenge behavior: operation-specific scopes, a 403/insufficient-scope response with the scopes required for the current operation, and a step-up authorization flow for a client to request them. It does not mandate a shared policy model binding tool use to delegated purpose, task state, and cross-tool history — scope grants and re-authorization are per-resource-server, not task-bound across the tools an agent composes in a single task. Not applicable — it stores what the agent knows, not what the agent may do.
Egress enforcement The specification states consent and data-protection principles — including consent before sharing user data and before a tool invocation that transmits data elsewhere — but does not itself provide runtime egress enforcement; it acknowledges these principles cannot be enforced by the protocol alone. Whether a given deployment enforces them is a client/host implementation matter the specification does not settle. Not applicable — no network surface of its own.
Approval fail-closed semantics Unspecified. Left entirely to the host application. Not applicable — no approval workflow exists in the format.
Signed/verifiable action evidence Not addressed. No protocol-level action log or signing; auditing is whatever the host chooses to build. Version-history support for memory changes; action completeness and protected retention not established. A commit records a change to what the agent knows, but a file can be modified without a commit, and git history can be rewritten, so mandatory commit signing would still not prove every mutation was captured or block deletion of the record. This also only covers memory-store writes: it says nothing about whether the agent's tool calls or other actions were logged at all.

Read down the columns rather than across, and read “credit” narrowly: MCP's specification, where a deployment adopts its authorization path, requires token validation — but that is a specified requirement about the token, not a claim about whether the resulting access is scoped to one task or safe to compose across tools, which is the actual delegated-authority question. On egress, the specification states consent and data-protection principles but does not itself provide runtime enforcement of them. Git-native memory supports provenance metadata and a diffable change history, without independently verifying either. Neither implementation was built to fail this framework — each was built to solve a real, narrower problem, and does so credibly on its own terms. The claim under scrutiny is the broader one: that adopting either gives you delegated authority as a side effect. Neither, on this evidence, does — not because either is poorly built, but because task-bound, cross-tool delegated authority was never the problem either one set out to solve.

The thesis

This review compares six dimensions using specified requirements and documented capabilities. Establishing that a deployment enforces the applicable controls requires separate testing. A container enforces isolation. MCP's specification, where a deployment adopts its authorization path, requires token validation. Neither, by itself, establishes task-bound, cross-tool delegated authority.

The pattern above is a category error, not a defect in either technology: treating a control that answers one question as though it answered all six that apply. The fix is not a better container or a stricter allowlist inside the same architecture — it is naming the applicable questions separately, so a system can be checked against each one instead of credited for the one it happens to answer well.

Sources

About This Series

Michael K. Saleme — Enterprise Agent Architect

A control-plane analysis reading two popular agent-infrastructure choices — a protocol and a memory format — against a six-dimension delegated-authority framework, in the same evidence-discipline style (cataloged vs. verified, applicability noted explicitly) used elsewhere in this series for incident analysis.

This page is the canonical version of this analysis.

Cite the Position Paper

This analysis develops the Enterprise Agent Architecture position paper, which is published and citable on Zenodo under CC BY 4.0. Cite the concept DOI — it always resolves to the latest version.

DOI: 10.5281/zenodo.21105314

Saleme, M. K. (2026). Enterprise Agent Architecture: The Case for a Fifth Architecture Domain for the Agentic Enterprise. Zenodo. https://doi.org/10.5281/zenodo.21105314

BibTeX 
@misc{saleme2026eaa,
  author    = {Saleme, Michael K.},
  title     = {Enterprise Agent Architecture: The Case for a Fifth Architecture Domain for the Agentic Enterprise},
  year      = {2026},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.21105314},
  url       = {https://doi.org/10.5281/zenodo.21105314}
}

Michael K. Saleme

Enterprise Agent Architect · Cognitive Thought Engine