System view

What is an action-control graph?

An action-control graph shows how an AI-assisted workflow moves from human owner to agent, tool, credential, action, target, approval, policy, and evidence.

Last updated: May 16, 2026

AI-assisted software delivery risk is not contained in one tool. It moves through an action path: human intent, agent or workflow, repo, CI/CD, credential, action, target, approval, and evidence. The action-control graph connects those pieces so engineering and platform teams can see which paths can write, deploy, use credentials, publish, or touch production.

The graph Clyra maps first

human owner -> task -> agent/workflow -> tool -> credential -> repo/PR -> CI/CD -> action -> target -> risk tier -> approval/policy -> evidence
Scattered signal Connected graph answer
A workflow file changed in a PR. Which agent or automation introduced it, and who owns the path?
A CI job has access to a package token. Which action can use the token, and which target can it change?
An MCP tool can call an internal API. Which credential, approval rule, and outcome evidence attach to the call?

This is not a model inventory. It is not a log stream. It is the operating map for what can act, through which path, with whose authority, against which system, and with what evidence afterward.

How it relates to an Agent Action BOM

The Agent Action BOM is the first artifact a team can review. The action-control graph is the system structure behind that artifact.

Agent Action BOM

A shareable snapshot of actor, owner, task, repo, workflow, credential, reachable action, target, approval rule, and evidence coverage.

Action-control graph

The connected system view that shows how those paths relate, where authority enters, what changed, and which gap to close first.

What the graph should contain

  • Human owner or accountable team.
  • Agent, agent team, workflow, CI bot, MCP-connected tool, review bot, or internal automation.
  • Task, repo, branch, PR, workflow file, config, package script, or release path.
  • Credential source, identity, token, OAuth grant, cloud role, or service account.
  • Reachable action class: read, write, execute, deploy, publish, delete, access secret, or modify workflow.
  • Risk tier based on reversibility, authority, target system, and production or customer impact.
  • Target system: repo, CI/CD job, package registry, cloud account, database, internal API, tool, or release workflow.
  • Approval rule, policy decision, validation result, timestamp, outcome, and evidence location.

What decisions it supports

Know

Which AI-assisted paths can change software delivery systems, and which owners are accountable for them.

Control

Which actions should be allowed, approval-required, blocked, or moved toward temporary scoped authority.

Prove

Which evidence packet exists for action, approval, credential use, validation, target system, and outcome.

Prioritize

Which action path should the team review first because it carries the clearest blast radius.

What it is not

The action-control graph is not the category name. It is the system view. The near-term category is AI Software Delivery Control: visibility, control, and evidence for AI-assisted engineering actions across software delivery.

It also does not replace IAM, PAM, NHI management, SAST, secret scanning, CI/CD policy, or runtime gateways. Those controls still matter. The graph connects their signals into the action path.

Start with the software delivery graph.

Clyra maps selected repos or workflows and returns the graph, Agent Action BOM, and evidence packet your engineering, platform, and security reviewers can use.

Map one workflow