Quest: Enforce least authority across `xmd` workflows

[taras]

Quest outcome

Let a workflow author restrict which XMD operations a section of a workflow and
its nested content may perform.

If an outer section removes access to a capability, no nested component can
restore that access through another XMD provider or middleware layer. A nested
section may remove additional access.

Here, XMD-mediated authority means the ability to perform an effect through
XMD's Files, Fetch, Process, Git, Git-host, Issue, Workspace, Agent, model, or
other trusted operation boundary.

Example

A supervised implementation workflow has three stages:

Stage	Needs	Does not need
Implement	Worktree read/write, test processes, coding Agent	Deployment credentials
Review	Repository read, review Agent	Worktree write, test processes, GitHub mutation
Publish	Approved GitHub mutation and its credential	Coding Agent, arbitrary worktree access

The workflow restricts each stage to the XMD operations it needs.

If the Review stage installs another Files provider, loads another copy of an
XMD package, or calls nested components, it still cannot recover write access
removed by the outer restriction.

If the selected Agent or process launcher cannot enforce a requested
restriction, the stage refuses before starting that Agent or process. It never
runs with broader access silently.

The public Markdown form for expressing these restrictions remains a design
decision. This Quest owns the security contract and the child stories that
deliver it; it does not choose a permission-language syntax in this body.

Why this matters

Executable workflows already try to keep known behavior in the document and use
Agents only where judgment is required. Least authority applies the same idea to
effects: each part receives only the access it needs.

Lexical composition already gives XMD a useful shape for this boundary. A
restriction applies to nested content and ends with the scope that installed it.

Ordinary middleware alone is not a security boundary. A component can replace
middleware, trusted authored JavaScript can call runtime APIs directly, and a
launched process or Agent becomes a separately executing program.

The Quest must therefore state exactly which operations XMD controls and avoid
claiming broader sandboxing.

Initial security profile

The initial profile supports trusted authored workflows.

Markdown components, eval blocks, function components, imports, JavaScript,
processes, and Agents remain usable. Authored JavaScript is trusted.

XMD guarantees monotonic restriction only for effects that pass through its
trusted operation boundaries:

host's maximum XMD access
 ↓
access available to the workflow root
 ↓
outer section restriction
 ↓
nested section restriction
 ↓
final authorization
 ↓
effect

Each downward step may preserve or remove access. It may never add access above
its parent.

Direct JavaScript calls to Deno, Node, global fetch, native libraries, or
arbitrary SDKs remain outside this initial guarantee. Do not describe this
profile as an arbitrary-code sandbox.

Future constrained profile

A separate constrained or untrusted profile may prohibit, inspect, or isolate
authored JavaScript, imports, native APIs, processes, and Agents.

Only that stronger profile could claim that everything beneath a restriction is
confined to it, regardless of how the code attempts an effect.

Useful least-authority support for trusted workflows does not wait for that
future profile.

Authorization boundary

The trusted host establishes the maximum XMD-mediated access before authored
work begins. That maximum is owned by the execution, not stored in replaceable
middleware or Context.

Before an effect occurs:

1. the trusted provider normalizes the final request;
2. every active lexical restriction evaluates that same request;
3. an execution-private authorization gate records acceptance; and
4. the provider performs the effect.

Ordinary middleware may route, observe, transform, instrument, synthesize,
refuse, or delegate. Its return value does not authorize an effect.

A fabricated request, another loaded package copy, a captured public wrapper,
or a replacement provider cannot invoke the private authorization gate or widen
the active access.

The final check occurs immediately before the effect rather than trusting a
capability object handed down earlier.

Initial XMD domains

Candidate domains include:

• document Files;
• Fetch;
• environment reads through XMD;
• Process and Service launch;
• Git and Git-host effects;
• Issue-provider effects;
• Workspace effects;
• Agent and model invocation; and
• other recorded external effects.

The first implementation need not cover every domain. Every delivered domain
must document what can be restricted, how the provider enforces it, and what
happens when enforcement is unavailable.

Credentials and live provider objects never appear in the structural policy a
document can inspect or copy.

Processes

Processes remain available. The policy may restrict launch-time facts XMD can
control, including:

• whether launch is allowed;
• executable or launcher profile;
• arguments;
• working directory;
• complete environment;
• credential injection;
• inherited descriptors; and
• process lifetime and cancellation.

After launch, filesystem access, network access, child processes, OS-visible
credentials, and interpreter behavior require enforcement from an operating
system, container, sandbox, or qualified launcher.

Allowing an executable is not complete confinement. An interpreter or extensible
tool may expose broader behavior.

If a workflow requests a launch restriction that the selected profile cannot
enforce, XMD refuses before spawning. A restriction is never silently converted
to ambient behavior.

Agents

Agents also remain available.

An Agent provider may be asked to enforce restrictions on:

• provider and model;
• working directory and Workspace;
• environment;
• filesystem reads and writes;
• commands and tools;
• network;
• MCP servers and tools;
• mutation channels;
• permission requests; and
• credentials.

For every requested dimension, the provider reports either:

• enforced;
• unsupported; or
• not requested, using its documented ambient behavior.

A requested unsupported restriction refuses before session creation, resumption,
or Prompt execution.

Prompt instructions do not count as enforcement. A permission callback is one
decision point inside an already fixed ceiling, not the ceiling itself.

Replay and portability

A resumed workflow receives the same effective access as the original execution
or a narrower intersection with the current host. Resumption never restores
access that the current branch or environment no longer permits.

A workflow describes the access its components require independently from the
mechanism a local, CI, or cloud environment uses to enforce it.

component requirements
 ⊆
section's allowed access
 ⊆
environment's enforceable access

A restricted host's own recursive xmd invocation preserves the same or a
narrower runtime profile. Authored arguments cannot restore broad runtime flags
such as --allow-all.

Delivered foundations

• 🌐 Fetch retained HTTP observations from Markdown #456 — trusted-host Fetch ceiling beneath replaceable middleware.
• Run workflow Agents through XMD-mediated observations #302 and Evaluate Agent-generated XMD through a constrained allowlist #369 — XMD-mediated workflow Agent observations and constrained
  generated-XMD execution.
• Launch a deterministically prepared Agent session in its native UI #517 — provider-native Agent session launch with host-owned authority.
• Reject secrets before journal persistence by default #199 — secret rejection before journal persistence.
• 🏛️ Codify capability-backed policy middleware as an architecture pattern #451 — its middleware doctrine was consolidated into Establish and enforce ownership rules for Effection scope and middleware #491 rather than
  delivered separately.

These foundations demonstrate parts of the model. They do not yet provide a
general lexical least-authority component.

Blocking work

• Establish and enforce ownership rules for Effection scope and middleware #491 — establish and statically enforce the repository's ownership rules
  for Effection scope and middleware.
• Establish execution-owned root XMD authority, lexical restriction frames,
  and the private final authorization gate.
• Apply the gate to initial Files, Fetch, environment, and recorded external
  effect domains.
• Define one trusted Process launch contract and its enforcement reporting;
  Run shell blocks in xmd workflows #363 is a constrained-shell consumer.
• Define Agent-provider enforcement reporting; Require ACP adapters to enforce tool-free workflow Agent sessions #496 owns portable tool-free
  workflow Agent sessions.
• Define restricted CI and deployment profiles.
• Settle how components declare or imply their required access without
  maintaining a second permission manifest.
• Define the later constrained or untrusted execution profile separately.

Create focused child stories for every unassigned blocking item before
implementation. Add their issue numbers and dependency order to this Quest.

#227 remains the ordinary xmd run filesystem-containment story. It supports
the Files boundary but does not deliver the complete Quest.

Completion

The Quest is complete when:

• architecture and specifications explain the trusted and constrained profiles
  in the same terms;
• the trusted host establishes one execution-owned root authority;
• nested restrictions can only remove XMD-mediated access;
• every delivered XMD domain checks the final request through an
  execution-private authorization boundary;
• middleware replacement, another loaded copy, or a fabricated request cannot
  widen an effect;
• Process and Agent providers report whether requested restrictions are
  enforceable and refuse unsupported requests;
• resumption cannot widen the original or currently permitted access;
• focused negative tests prove every delivered domain's restriction and
  fail-closed behavior;
• public documentation states the exact boundary of every security claim; and
• every blocking child story is complete.

Out of scope

• Choosing the public policy syntax in this Quest body.
• Claiming arbitrary-code sandboxing for trusted authored workflows.
• Requiring built-in-only workflows.
• Prohibiting processes or Agents by default.
• Treating Prompt instructions as security enforcement.
• Solving general portable container, network, or operating-system sandboxing.
• Describing XMD itself as an operating-system sandbox.

Related work

• Establish and enforce ownership rules for Effection scope and middleware #491 owns Effection scope and middleware ownership rules.
• Prevent xmd run filesystem operations from escaping the working directory #227 owns ordinary host-filesystem containment.
• Run shell blocks in xmd workflows #363 owns transactional constrained Worker Shell execution.
• Require ACP adapters to enforce tool-free workflow Agent sessions #496 owns portable tool-free workflow Agent enforcement.
• Quest: Resume workflows with their Workspace, repositories, and Agent state #218 owns workflow Workspace and resumption.