What Is an AgBOM? Inventorying the Autonomous Coding Agents in Your Pipeline

A new framework called the Agent Bill of Materials (AgBOM) is emerging to inventory autonomous coding agents in software pipelines, formalized through OWASP's Agent Observability Standard (AOS) project in 2025. AgBOM extends existing formats like CycloneDX, SPDX, and SWID to track agent tools, models, and permissions, addressing risks that dependency scanners miss. GitHub Copilot alone now serves 140,000 organizations, highlighting the need for such tracking.

What Is an AgBOM? Inventorying the Autonomous Coding Agents in Your Pipeline Your team probably knows who merged the last pull request. But do you know which AI agent wrote it, what tools it invoked, what credentials it used, and whether those permissions had changed since yesterday? For most organizations, the answer is no. Most software supply chain tools don't track the newest actor in your pipeline: the AI agent. Many teams already generate SBOMs for software dependencies and are beginning to adopt AI Bills of Materials AIBOMs for models and datasets. The agents themselves, however, usually aren’t inventoried at all. That’s where the Agent Bill of Materials AgBOM comes in. Many engineering teams would struggle to answer which agent modified a given file, what permissions it held at the time, and whether those permissions had changed. Does your team belong to this group? In this article, we explore AgBOM and the steps to take if you’re missing out on it. TL;DR - Why engineering teams should adopt AgBOM AI coding agents can gain access to new tools, credentials, or autonomy without a single line of code changing – a risk your dependency scanners aren't built to catch. An AgBOM tracks that authority directly, so teams can spot dangerous permission changes before they merge, not after an incident forces the question. What is an AgBOM? An Agent Bill of Materials, or AgBOM, is a structured inventory that documents the autonomous coding agents operating in your software pipeline, including the tools, models, and permissions each one holds. The concept began to be formalized through OWASP’s Agent Observability Standard https://owasp.org/www-project-agent-observability-standard-2/ AOS project in 2025, yet the underlying problem will be familiar to many teams using coding agents such as Claude Code, Cursor, or GitHub Copilot alongside modern CI/CD workflows. With it, developers and auditors can answer a specific question: what is this agent actually authorized to do? OWASP describes the purpose plainly, noting that the Agent Bill of Materials addresses this need by providing a dynamic inventory of all components comprising an agent system. The important detail here is that AgBOM was not invented as a brand-new format competing for adoption . The working group behind OWASP's AOS built it to extend formats engineering teams already use — CycloneDX, SPDX, and SWID — rather than introducing a separate one. In other words, your team can extend the SBOM tooling it already runs instead of adopting an entirely new schema. The framing worth internalizing is that an agent is now an actor in your pipeline /ai-agents-are-turning-developers-into-engineering-orchestrators-and-moving-the-risk-to-review , with its own identity and behavior pattern, rather than a passive artifact like a library version pinned in a lockfile. An agent decides, within the bounds of its configuration, what to do next: which files to touch, which tools to invoke, whether to open a pull request or push directly. The AgBOM is the record of what that actor is permitted to do at any given point. Why is AgBOM emerging now? AgBOM is emerging because coding agents have moved from experimental extensions to standing participants in delivery pipelines. GitHub Copilot alone now serves 140,000 organizations https://github.blog/ai-and-ml/github-copilot/github-recognized-as-a-leader-in-the-gartner-magic-quadrant-for-enterprise-ai-coding-agents-for-the-third-year-in-a-row/ , each with credentials and tool access that traditional dependency scanning never had to account for. A CycloneDX proposal filed in early 2026 captures the shift directly https://github.com/CycloneDX/specification/issues/895 , arguing that tracking agent components extends the discipline from "what software components are in this system" to "what components make up this autonomous agent and what is it authorized to do" . That distinction did not matter much when agents were confined to autocomplete suggestions inside an editor. It matters enormously once an agent can open a pull request, call an external API, or write to a production database on a schedule nobody explicitly reviewed that week. How is an AgBOM different from an SBOM or AIBOM? An AgBOM differs from an SBOM or AIBOM because it documents the agent's authority to act rather than the components it is built from. The three inventories answer related but distinct questions, and none of them substitutes for the others: | | | | | | Which software dependencies and versions make up this application? | Agent behavior, model provenance, runtime permissions | | | Which models, datasets, and frameworks make up this AI system? | What an autonomous agent is authorized to do with that system | | | What can this agent access, invoke, or change, and under what approval gates? | Underlying code dependencies covered by SBOM instead | By breaking down each one of these artifacts, we can better understand how they complement each other: - A software bill of materials /software-bill-of-materials-sbom enumerates packages and their versions, which is exactly the right lens for a static library, but the wrong lens for something that makes decisions at runtime. - An AI bill of materials goes further, functioning as a comprehensive inventory of the models, training datasets, software dependencies, frameworks, and infrastructure that make up an AI system, but it still treats the system as a fixed composition to be cataloged rather than an actor to be governed. - An agent bill of materials adds a dimension neither of the other two artifacts was designed to hold: the attributes that describe autonomous action itself, such as tool permissions and credential scope. This last artifact functions as a complementary security layer for runtime authority, making agentic risk visible before deployment and trackable across changes, rather than replacing the dependency or model inventories your team already maintains. What does an AgBOM actually track? An AgBOM tracks the fields that describe what an agent can do, not just what it is made of. It spans identity, tool access, and the approval gates https://blog.codacy.com/why-coding-agents-need-independent-quality-gates that constrain its behavior. This is the point where the abstraction becomes concrete enough to act on. An agent BOM adds fields for: - Autonomy - Tool permissions - Memory - Credential scope - Approval gates - Audit signals - Inter-agent communication - External action capability Each of these fields exists because it describes a way the agent could cause harm, even when its underlying code hasn't changed. The most consequential category is what practitioners call runtime authority https://arxiv.org/html/2605.28914v1 : the specific permissions an agent holds and the conditions under which it can exercise them. A useful way to frame the overall boundary is as the union of everything that defines what an agent can do and what happens when it does it. Miss any one piece, and the inventory can't answer whether the agent's current behavior matches its intended scope. For a team starting from zero, the practical checklist looks like this: Agent identity and version: which agent, which build, running where, so a specific instance can be traced during an incident. Tool descriptors and risk tier: what each connected tool can do, ranked by how destructive a misuse would be. Credential scope: which secrets, API keys, or service accounts the agent can invoke, since this is usually the difference between an annoying bug and a serious breach. Network egress policy: where the agent is allowed to send data out to, since a tightly scoped tool with unrestricted egress can still exfiltrate whatever it touches. Approval gates: which actions require a human sign-off before execution, and where that gate is enforced. Audit signals: what gets logged when the agent acts, and whether that log is tamper-evident. Why does AgBOM matter for compliance and audit? AgBOM matters for compliance because regulators and auditors are increasingly asking for evidence of runtime enforcement, not just a written policy describing intended behavior. Provisions tied to the EU AI Act, ISO 42001 https://blog.codacy.com/iso-42001-what-engineering-leaders-need-to-know-about-the-ai-management-system-standard , SOC 2, DORA, and the increasingly reach into how agent behavior is documented and constrained, and auditors are starting to request agent activity logs, permission reviews, and kill-switch procedures as standard evidence rather than optional extras. https://www.nist.gov/itl/ai-risk-management-framework NIST AI Risk Management Framework Cycode's research https://cycode.com/press/ai-is-rewriting-how-software-is-built-and-secured/ into product security practices found that only 19% of organizations “have ” across development, which becomes an audit liability the moment a regulator asks for a specific answer under time pressure. https://blog.codacy.com/the-visibility-problem-behind-ai-tool-adoption-in-engineering-teams full visibility into where and how AI is used The teams that treat agent code governance as a framework to build now will have that evidence ready before anyone asks. On the other hand, teams that treat it as optional will assemble it retroactively – a slower, more error-prone process than exporting an existing report. What auditors actually check https://blog.codacy.com/what-auditors-will-ask-about-ai-generated-code-in-2026 is enforcement, not intent: not what an agent could theoretically do, but proof that a control held in practice . An inventory alone doesn't establish that. Without a runtime policy reference tying capability to actual behavior, the AgBOM tells only half the story. Where does AgBOM fit in your delivery workflow? AgBOM fits into the same surfaces your team already controls for code quality and security: the IDE, the pull request, and the CI/CD pipeline https://blog.codacy.com/ci/cd-pipeline-security-best-practices , with the pull request stage carrying the most weight for catching risky changes before they merge, going from documentation to control. The mechanism that matters most here is changes in an agent’s runtime authority: what an agent is able or permitted to do. These changes can happen without any obvious code-level signal, for example through: - A new write-capable tool being added to the agent’s toolkit - A broader credential scope or access to additional secrets - Persistent memory gaining access to sensitive information - Changes to orchestration or approval policies that expand the agent's autonomy The unsettling part is that all of this can occur even when the code and dependencies in the diff look completely unchanged. A pull request that adds no new library and touches no obviously sensitive file can still hand an agent write access it did not previously have, simply by editing a configuration block that a standard SCA or SAST https://blog.codacy.com/code-review-is-dead-why-ai-generated-code-needs-verification-not-human-approval scan was never built to interpret. Catching these subtle changes requires a review layer capable of flagging authority changes at the point they enter the codebase, whether the review happens in a pull request or directly from the terminal via tools like Claude Code, Cursor, GitHub Copilot, etc. During an actual incident, the same record pays off differently. Audit signals captured in the AgBOM determine whether there is sufficient evidence to reconstruct what an agent actually did, rather than only what it was configured to do. Enforcing this consistently across every repository https://blog.codacy.com/scaling-code-security-single-enforcement-layer , rather than as a one-off check on a single high-visibility project, is what separates a governance program from a slide deck. Build toward an AgBOM for AI coding governance To start building toward an AgBOM, your team needs to identify the agents already running in your pipelines and layer permission tracking onto that inventory, well before any formal standard lands. The sequence matters more than the tooling at this stage. Discover the agents you already run: Continuous discovery ofacross every connected repository is the foundation, because a team cannot govern what it has not inventoried. coding assistants, agents, and MCP servers Capture permissions and credential scope per agent: Treat any expansion of scope, from a new API key to a broader database role, as a reviewable event rather than a silent configuration change. Define approval gates for high-risk actions: Decide explicitly which agent actions require a human sign-off before execution, and document exactly where that gate lives in the workflow. Log agent activity in a durable, tamper-evident record: This is the first thing an auditor or incident responder checks, so the retention period and field list need to be decided in advance, not improvised during a crisis. Track changes as diffs, not snapshots: New tools, increased autonomy, or disabled logging should surface as flagged signals in the pipeline, not facts discovered after the fact. Map each captured field to a compliance control: This is what allows the same inventory to double as audit evidence instead of existing as a separate documentation exercise. With AI-assisted coding becoming standard for engineering teams, AgBOM must be part of the automated pipeline tooling rather than a manual documentation process to be scalable. The 2025 Stack Overflow Developer Survey https://survey.stackoverflow.co/2025/ai/ confirms that developers primarily adapt existing monitoring tools for agent observability, and the practical decision for most teams is to extend whichever format their SBOM pipeline already produces rather than adopting a second, incompatible schema. Expect the fields around tool-risk tiers and credential scope to keep evolving as more agent frameworks publish their own capability descriptors, and expect regulators to move faster on requiring evidence of enforcement than on blessing any single technical specification. Auditors are starting to ask what your agents are authorized to do Codacy's AI Inventory gives you a continuously updated, audit-ready record of AI models, API keys, and coding tools across every repository – so the answer is a dashboard export, not a scramble.