Workflow Control Plane

Why this page exists. Recipes are useful, but enterprises buy control planes. The workflow manifest turns every agentic remediation workflow into a governed deployment unit: what it may touch, which MCP context it can read, which gates must fire, what evidence must be retained, and when the workflow must be paused.

Rechecked source anchors against the public MCP specification 2026-07-28 on August 21, 2026.

The product idea

SecurityRecipes should not stop at recipes alone. The durable value is the control layer between agents and enterprise security work:

  • Recipes tell an agent how to remediate.
  • Manifests tell the platform whether the agent is allowed to run.
  • Gates decide whether the agent may continue.
  • Evidence proves what happened after the fact.
  • KPIs decide whether the workflow expands, pauses, or retires.

That shape makes the site easier to adopt in a serious environment: security teams can start with the open recipe, then wire the same workflow into an MCP gateway, CI gate, or internal orchestrator without inventing the governance model from scratch.

Workflow at a glance

Workflow Control Plane workflow

Validate a workflow manifest and bind its identity, scope, tools, gates, tests, and promotion rules before execution.

program-operations

  1. Signal

    Receive workflow request

    Identify the workflow, finding class, repository, owner, requested agent, and target environment.

  2. Scope

    Validate the manifest

    Check schema, version, declared inputs, file scope, tool permissions, tests, stop conditions, and outputs.

  3. Decision

    Bind runtime controls

    Resolve identity, entitlement, MCP policy, context package, approval, telemetry, and receipt requirements.

  4. Action

    Execute through gates

    Apply admission, mid-run, output, review, merge, and rollout decisions in the declared order.

  5. Proof

    Record promotion state

    Write validation results, decision receipts, evidence locations, and the next allowed maturity stage.

Decision gate

Is the manifest valid, owned, least-privileged, testable, and fully bound to runtime controls?

Proceed

Admit the workflow under its declared gates and evidence contract.

Hold or stop

Reject or hold unknown, incomplete, overbroad, or unowned workflows.

Evidence to retain

  • validated workflow manifest
  • bound policy and identity versions
  • gate and promotion decisions

Expected outputs

  • control-plane decision
  • workflow validation report
  • gap list

What was added

The control plane currently lives in source-controlled JSON:

  • data/control-plane/workflow-manifests.json - workflow declarations for the active remediation workflows.
  • data/control-plane/workflow-manifest.schema.json - the public shape a downstream platform can validate against.
  • scripts/validate_workflow_control_plane.py - a dependency-free validator that fails CI on missing gates, missing evidence, bad MCP scope, broken content links, or malformed workflow IDs.
  • data/evidence/workflow-control-plane-report.json - generated by the validator as an audit-friendly summary of the current workflow pack.
  • data/policy/mcp-gateway-policy.json - generated enforcement policy derived from this manifest for MCP gateways and agent runtimes.

Run it locally from the repo root:

python3 scripts/validate_workflow_control_plane.py

GitHub Actions runs the same validator before the site build, so a workflow page cannot drift away from its enterprise controls unnoticed.

Manifest anatomy

Each workflow declares the minimum set of fields an enterprise reviewer, agent host, or MCP gateway needs:

Field Purpose
eligible_findings What findings may dispatch this workflow.
automation_first Deterministic tools that should run before an agent.
mcp_context Typed MCP namespaces and access mode. No wildcard tool access.
scope Allowed paths, forbidden paths, changed-file caps, and diff caps.
gates Required admission, tool-call, output, pre-merge, post-merge, and runtime checks.
evidence Audit records, source systems, retention windows, and owners.
kpis Promotion and kill metrics for the workflow.
kill_signals Conditions that pause the workflow immediately.

This is intentionally boring. Boring is what auditors, reviewers, and platform teams can operate.

Industry alignment

The manifest model is aligned to current primary guidance:

The important product move is that those references are not just linked from prose. They are embedded in the manifest, validated in CI, and available to agents as part of the workflow policy.

How agents use it

An agent should ask the platform for the workflow policy before it acts:

  1. Match the finding to a workflow.
  2. Load the workflow manifest.
  3. Confirm the finding satisfies eligible_findings.
  4. Restrict tool access to mcp_context.
  5. Restrict file edits to scope.
  6. Run every gate declared in gates.
  7. Attach the required evidence records to the PR or triage note.
  8. Stop immediately on any kill_signals hit.

The local MCP server exposes the same pack through recipes_workflow_control_plane, so agents can retrieve this policy as structured context rather than scraping pages.

For runtime enforcement, use the MCP Gateway Policy Pack. It compiles this manifest into default-deny tool scopes, branch-write limits, approval holds, runtime kill signals, and evidence records.

Promotion model

Use the manifest as the promotion gate from “recipe” to “operated workflow”:

Stage Meaning Required manifest posture
crawl Pilot only; high human review; narrow scope. All six gate phases declared, low changed-file caps, runtime kill signals.
walk Active workflow with repeatable evidence and stable KPIs. CI validator green, evidence owners assigned, KPI targets measured monthly.
run Broad rollout with platform ownership and audit exports. Gateway policy generated from manifest, evidence report exported, promotion reviewed quarterly.

Do not move a workflow forward because it feels useful. Move it forward because the manifest, evidence, and metrics prove it is safe enough to scale.

See also