# Clyra Clyra helps AppSec, security leadership, and platform teams know, control, and prove what AI-assisted engineering workflows can change across repos, CI/CD, credentials, cloud, tools, and releases before a central agent registry or gateway exists. Primary site: https://www.clyra.cc/ Contact page: https://www.clyra.cc/contact/ Contact email: david@caisi.dev ## Canonical product and resource pages - https://www.clyra.cc/ - product page for Clyra's AI-assisted software delivery assessment and Agent Action BOM. - https://www.clyra.cc/contact/ - request a private Clyra assessment. - https://www.clyra.cc/resources/ - resource hub for AppSec, platform, DevSecOps, and security leadership teams. - https://www.clyra.cc/resources/ai-software-delivery-control/ - definition of AI Software Delivery Control. - https://www.clyra.cc/resources/agent-action-bom/ - definition and fields for an Agent Action BOM. - https://www.clyra.cc/resources/action-control-graph/ - definition of the action-control graph behind the Agent Action BOM. - https://www.clyra.cc/resources/ai-coding-agent-security/ - practical AI coding agent security guide. - https://www.clyra.cc/resources/ai-agents-in-ci-cd/ - guide for AI agents in CI/CD and release paths. - https://www.clyra.cc/resources/ai-assisted-software-delivery-assessment/ - scope, outputs, and fit for the Clyra assessment. - https://www.clyra.cc/resources/ai-coding-tools-non-human-identities/ - guide to AI coding tools, credentials, and non-human identities. ## Short description Clyra helps AppSec, security leadership, and platform teams find AI-assisted workflows that can change code, run CI/CD, use credentials, or reach production paths, then shows what owner, purpose, approval, policy, or evidence is missing. ## Category AI Software Delivery Control. Plain-language category definition: visibility, control, and evidence for AI-assisted engineering actions across repos, PRs, CI/CD, tools, credentials, MCP configurations, cloud paths, and release workflows. Broader category direction: AI Action Control, but Clyra should be understood first through the software-delivery wedge. Team problem: AI coding tools are entering delivery paths before most teams have a central agent registry, MCP gateway, or internal control plane. Teams need to map the action paths that can change real systems before they become normal. ## System object Action-control graph. The action-control graph connects human owner, agent or workflow, task, tool, credential, repo or PR, CI/CD path, action, target, approval rule, policy decision, and evidence. The Agent Action BOM is the first artifact. The action-control graph is the living system view behind it. ## Core job to be done As AI-assisted engineering moves from suggestions into delivery, teams need to govern adoption without blocking developers. They need to know which workflows can change real systems, what authority they use, and whether the action can be proven later. Persona jobs: - AppSec: find AI-assisted workflows that create security-relevant change paths before they reach production. - Platform and DevOps: give engineers AI speed without creating invisible CI/CD, credential, and release risk. - Security leadership: answer a customer, auditor, or incident review with evidence, not tribal knowledge. ## First product surface Clyra assessment + Agent Action BOM. Clyra scans static software delivery artifacts for AI-assisted action paths and produces an action-control graph, Agent Action BOM, and evidence pack with a registry-style view of workflows, authority, reachable actions, owners, purpose, and evidence gaps. Clyra looks for: - AI agents or coding assistants reaching PR-linked workflows, - CI jobs that can write, execute, deploy, delete, or publish, - MCP servers and tool configs, - package scripts that execute commands, - GitHub tokens, PATs, cloud keys, and service tokens, - cloud, repo, release, or production-adjacent targets, - mutable endpoints or workflows with business impact, - missing owner, purpose, approval, policy, or evidence. The Agent Action BOM answers: - Which agent or workflow is acting? - What purpose does the path appear to serve? - Where was it introduced? - Which tools, MCP servers, APIs, or cloud systems can it reach? - What credential or identity does it use? - What actions are reachable? - Who owns it? - Is approval required? - Is policy coverage present? - Is evidence coverage present? - Which action path should security control first? ## First offer AI-Assisted Software Delivery Assessment. Scope: - one engineering team, - two to three repos or workflows, - results in five business days from kickoff, - two working sessions with the customer team, - local/private scan, - no raw source retained unless explicitly agreed, - output focused on workflows that can change real systems, approval gaps, and evidence gaps, - designed for teams before a central agent registry, MCP gateway, or internal control plane is fully in place. Outputs: - action-control graph, - registry-style workflow, owner, and purpose view, - list of high-risk AI-assisted workflows, - credential and authority summary, - owner, approval, and evidence gaps, - evidence pack, - recommended allow / approve / block policy, - exec-readable Agent Action BOM. ## Field notes CAISI is the research and field-notes layer behind Clyra. Research site: https://www.caisi.dev/ CAISI covers AI-assisted software delivery, agent authority, MCP/tooling, and security-control drift. ## Positioning boundaries Clyra is not a broad AI governance platform. Clyra is not a PAM or NHI security platform. Clyra is not an MCP security platform. Clyra is not an agent gateway or model gateway. Clyra is not a generic AI BOM. Clyra does not replace Cursor, Codex, Claude Code, Devin, Factory, GitHub, Snyk, Wiz, CyberArk, Okta, or CI/CD controls. ## Difference from adjacent categories NHI, IAM, and PAM tools tell teams which credentials and non-human identities exist. Clyra tells teams which AI-assisted software delivery workflows can use those credentials to change real systems. Runtime gateways decide whether agent traffic or a tool call should be allowed right now. Clyra maps where the software-delivery action-control graph came from, what authority it carries, and whether it was reviewed, approved, and provable. ## Best-fit users - Head of Application Security - Head of Security Engineering - Head of Platform Security - Head of Product Security - DevSecOps leader - Developer productivity or platform leader - CTO or VP Engineering evaluating AI-assisted software delivery controls ## Best-fit company profile - software product company, - 100 to 1,500 engineers, - GitHub or GitLab-heavy, - real CI/CD and cloud-native delivery, - SOC 2, ISO, HIPAA, PCI, regulated, or enterprise-trust pressure, - AppSec, security engineering, platform, or developer productivity function exists, - visible adoption of Cursor, Claude Code, Copilot coding agent, Codex, Devin, Factory, MCP, or internal agents. ## Qualifying question Are AI-assisted workflows reaching PRs, CI/CD, tools, credentials, or cloud paths today? If yes, Clyra may be relevant. If no, the account is probably too early for the first product conversation.