OUT-1002 - The Task Manifest Protocol – Explicit Authority in CI

Living Document Notice
Published 2026-09-11. The evolving architecture, revisions, and connected notes for this dispatch live in the Stax Digital Garden.

The Task Manifest Protocol – Explicit Authority in CI

Summary

Automated continuous integration workflows frequently operate with excessive trust. When pipelines invoke external build scripts or autonomous linting routines, they often grant broad write permissions across the entire workspace. Without explicit boundary declarations, misconfigured tools can overwrite deployment manifests, leak repository secrets, or mutate version tags outside their operational purview.

The Task Manifest Protocol addresses this security gap by establishing an explicit, declarative specification for every automated job. Before invoking any executable script, the CI runner inspects a structured manifest that defines allowed inputs, designated output artifacts, and exact execution boundaries.

Declarative Authority Schema

Traditional CI configurations specify shell commands in sequential workflow steps. While simple to write, shell snippets hide side effects and allow unmonitored disk mutations. A task manifest replaces open-ended execution with structured parameters verified by pre-flight validation hooks.

{
  "$schema": "https://specs.bosunpkm.com/task-manifest-v1.json",
  "task_id": "dispatch-lint-042",
  "authority_level": "sandboxed-read-write",
  "allowed_inputs": [
    "02 Review/outrigger/*.md",
    "02 Review/harbormaster/*.md"
  ],
  "designated_outputs": [
    "02 Review/audit-log.json"
  ],
  "denied_paths": [
    ".git/*",
    ".github/workflows/*",
    "ops/*"
  ],
  "max_execution_seconds": 120
}

The protocol separates authority into distinct tiers. Read-only tasks cannot generate filesystem modifications. Sandboxed read-write tasks can modify only explicit output files. Administrative tasks that touch workflow configurations require separate cryptographic signature verification before execution.

Cryptographic Attestation and Pre-Flight Manifest Inspection

To prevent unauthorized manipulation of task manifests within distributed build environments, each manifest file carries an optional detached Ed25519 signature block. The runner reads the signature and validates it against known maintainer public keys stored in read-only environment variables.

Prior to starting an automated job, a dedicated supervisor binary loads the manifest, computes checksums for target files, and prepares the workspace. If the manifest declares paths outside the repository boundary, execution halts immediately.

import json
import fnmatch
from pathlib import Path
 
def verify_manifest_boundaries(manifest_path: Path, workspace_root: Path) -> dict:
    with open(manifest_path, "r", encoding="utf-8") as f:
        manifest = json.load(f)
        
    root = workspace_root.resolve()
    
    # Audit denied paths against allowed inputs
    for input_pattern in manifest.get("allowed_inputs", []):
        for denied in manifest.get("denied_paths", []):
            if fnmatch.fnmatch(input_pattern, denied):
                raise ValueError(f"Security conflict: {input_pattern} matches denied path {denied}")
                
    # Verify outputs remain strictly within workspace
    for output_rel in manifest.get("designated_outputs", []):
        out_target = (root / output_rel).resolve()
        try:
            out_target.relative_to(root)
        except ValueError:
            raise PermissionError(f"Designated output escapes workspace: {output_rel}")
            
    return manifest

This verification step runs in a minimal environment prior to invoking tool logic. By failing closed before launching heavy dependencies, pipelines prevent accidental modifications to protected infrastructure configurations.

Post-Run Mutation Audits

Following job completion, the supervisor performs a diff between the pre-run filesystem snapshot and the current working tree. Any created or modified file not listed in the designated_outputs array triggers an automatic failure.

Execution Phase	Supervisor Action	Validation Target	Failure Outcome
Pre-Flight	Manifest schema parse	Syntactic validity and path rules	Immediate pipeline exit
Snapshot	Baseline file hashing	Tree state and modification stamps	Abort on dirty worktree
Run Phase	Subprocess monitoring	CPU seconds and memory limits	Process SIGKILL on breach
Post-Flight	Working tree comparison	Modified paths versus designated outputs	Tree rollback and CI failure

Enforcing explicit authority through task manifests transforms CI pipelines into auditable execution boundaries. Teams gain clear visibility into automated changes while preventing unintended repository drift across long development lifecycles.

---

• Directus Target: outrigger
• Garden Source Reference: Continuous Integration Boundary Security, Declarative Action Manifests, MOC - Outrigger Protocol, MOC - Agentic Containment and Sandbox Boundaries, MOC - Adversarial Agent Containment, MOC - Bosun PKM Tools, [BSN-1007 - Sandboxing AST Extensions with Outrigger](BSN-1007 - Sandboxing AST Extensions with Outrigger), MOC - Bosun PKM Engine