Skip to content

Agent Capability Risk Register

Why this page exists. Enterprise AI approval cannot stop at “the workflow is ready.” It also needs to know how powerful the agent capability is, how far a mistake can spread, and which controls reduce the residual risk before MCP access scales.

The product bet

SecurityRecipes is positioned as the secure context layer for agentic AI, but credible enterprise adoption also needs a capability risk view. A buyer approving an MCP-backed agent has to answer four questions before the first rollout cohort:

  • How critical is the system or workflow domain?
  • How autonomous is the agent before the next human review point?
  • What is the most powerful MCP permission the workflow can request?
  • How far can a bad decision spread across repos, tenants, supply chain assets, or irreversible financial systems?

The Agent Capability Risk Register turns those questions into a generated artifact. It gives security architecture, AI platform, GRC, procurement, and diligence reviewers a simple residual risk tier: low, medium, or high.

What was added

The capability-risk layer has three artifacts and one MCP surface:

  • data/assurance/agent-capability-risk-model.json - the source-controlled factor model, risk tiers, control credits, and standards mapping.
  • scripts/generate_agent_capability_risk_register.py - a dependency-free generator with --check mode for CI drift detection.
  • data/evidence/agent-capability-risk-register.json - the generated workflow-by-workflow risk register.
  • recipes_agent_capability_risk_register - the MCP tool that exposes risk tiers, residual scores, and next actions to agents, AI platform portals, and internal control dashboards.

Run it locally from the repo root:

python3 scripts/generate_agent_capability_risk_register.py
python3 scripts/generate_agent_capability_risk_register.py --check

What is inside the register

SectionPurpose
capability_risk_summaryWorkflow counts, average raw capability score, average residual score, tier counts, decision counts, and top-risk workflows.
workflow_capability_risksPer-workflow dimensions, raw score, control credits, residual score, risk tier, guardrails, and next actions.
factor_modelThe four capability dimensions: system criticality, AI autonomy, access permissions, and impact radius.
control_credit_modelCredits for readiness, default-deny gateway policy, connector coverage, red-team coverage, and runtime kill signals.
risk_tiersLow, medium, and high residual-risk thresholds with operating decisions.
source_artifactsHashes for every artifact used to generate the decision.

The register separates inherent capability risk from residual risk. That distinction matters: a workflow can be inherently powerful, but acceptable to pilot when default-deny MCP policy, production connector coverage, red-team drills, human review, and runtime kill signals are current.

Industry alignment

This feature follows current primary guidance:

How to use it

For an AI platform review, start with high residual risk:

recipes_agent_capability_risk_register(risk_tier="high")

For a workflow owner, inspect the workflow directly:

recipes_agent_capability_risk_register(workflow_id="defi-blockchain-security")

For architecture review, ask for workflows above a residual threshold:

recipes_agent_capability_risk_register(minimum_residual_score=35)

The output names the factors driving the score and the compensating controls currently reducing it. That keeps the review focused on concrete decisions instead of broad fear about agents.

CI contract

The generator fails if:

  • The factor model is missing any of the four capability dimensions.
  • Risk tiers do not include low, medium, and high.
  • Gateway policy, connector trust, red-team, or readiness evidence drifts from the workflow manifest.
  • The gateway policy no longer defaults to deny.
  • A checked-in register is stale in --check mode.

That is the enterprise bar for agentic capability risk: reviewers can see the raw capability, the compensating controls, the residual tier, the hashes behind the decision, and the next action before expanding MCP access.

See also