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.

The product idea

SecurityRecipes should not stop at a prompt library. 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.

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 Hugo 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, acquirers, and platform teams can operate.

Industry alignment

The manifest model is aligned to current primary guidance:

NIST AI RMF for governed, measured, managed AI risk.
NIST SP 800-218 SSDF for secure software development and vulnerability-response evidence.
CISA Secure by Design for measurable customer security outcomes and transparency.
OWASP GenAI Security Project for agentic AI risks such as excessive agency, insecure plugin design, prompt injection, and overreliance.
MCP Security Best Practices for scoped authorization, tool-call safety, and confused-deputy risk.

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:

Match the finding to a workflow.
Load the workflow manifest.
Confirm the finding satisfies eligible_findings.
Restrict tool access to mcp_context.
Restrict file edits to scope.
Run every gate declared in gates.
Attach the required evidence records to the PR or triage note.
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.