Blog · arXiv Analysis · Last reviewed June 25, 2026

The AgentRiskBOM Becomes the Authority Map

The June 2026 arXiv paper AgentRiskBOM: A Risk-Scoping Security Bill of Materials for Agentic AI Systems, by Srimonti Dutta and Akshata Kishore Moharir, argues that tool-using agents need a bill of materials for runtime authority, not only software dependencies or model provenance.

The useful object is an authority map: a versioned, machine-readable declaration of what an agent can read, remember, call, change, delegate, approve, and prove afterward. It is not a safety certificate. It is the record a release gate, buyer, auditor, or incident responder needs before trusting delegated action.

The Authority Gap

The paper, arXiv:2606.21877 [cs.AI], was submitted on June 20, 2026. Its premise is direct: once an AI system can retrieve private context, invoke tools, write files, call services, coordinate with other agents, or act without human approval, ordinary component inventories stop short of the risk. A software bill of materials can name packages. A model or AI bill of materials can name training or model provenance. Neither record necessarily says what the deployed agent is allowed to do.

Dutta and Moharir call this an agentic transparency gap: capability opacity around what an agent can access, remember, change, delegate, and prove afterward. That makes the paper a useful companion to this site's existing page on the AI bill of materials, but it is not a duplicate of it. The earlier page maps the AI supply chain. AgentRiskBOM maps runtime authority.

The distinction matters because the dangerous part of an agent is often not the dependency tree. It is the credential scope, the tool side effect, the memory store, the approval bypass, the external endpoint, the inter-agent trust relationship, or the missing log that prevents reconstruction after harm.

Current Context

As of June 25, 2026, the paper lands inside a fast-forming standards and security stack. The G7 Cybersecurity Working Group's Software Bill of Materials for AI - Minimum Elements guidance, surfaced by CISA and national cybersecurity agencies, treats AI SBOMs as a way to improve transparency and cybersecurity across AI supply chains. SPDX 3.0.1 includes an AI profile for documenting AI systems, model artifacts, software packages, and datasets. CycloneDX's ML-BOM capability represents models, datasets, configurations, provenance, training methods, and framework configuration. Those efforts make AI component memory more machine-readable, but they still do not fully answer what a live agent may do.

Agent security guidance is converging on the same gap from another direction. NIST's AI Agent Standards Initiative names autonomous action, interoperable protocols, agent authentication, identity infrastructure, and security evaluation as standards work. NIST NCCoE's software and AI agent identity project focuses on identifying, managing, and authorizing actions taken by software agents, including AI agents. CISA's joint Careful Adoption of Agentic AI Services guidance frames agentic AI as a cybersecurity risk-management problem. OWASP's Top 10 for Agentic Applications highlights goal hijacking, tool misuse, identity and privilege abuse, agentic supply-chain vulnerabilities, memory and context poisoning, insecure inter-agent communication, cascading failures, and rogue agents.

AgentRiskBOM sits between those two stacks. It says the AI supply-chain map and the agent-security map have to meet at the authority envelope: the live bundle of identity, tools, credentials, memory, approvals, communication paths, external effects, and logs that determines what the agent can actually do.

What the Map Records

AgentRiskBOM is presented as an additive layer over SBOM, AIBOM, and MLBOM artifacts. It references those records where they are authoritative, then adds agent-specific fields: agent identity, model and prompt metadata, tool descriptors, tool-risk tiers, memory and data sources, credential scope, approval gates, audit signals, autonomy level, inter-agent communication, control mappings, and external action capability.

The paper's core field groups are practical rather than ornamental. The tool layer records source, protocol, descriptor, permissions, side effects, and risk tier. The memory-data layer records data classification, retention, vector store, retrieval logging, and memory behavior. The autonomy-authority layer records maximum tool tier, approval gates, emergency stop, and autonomy level. The audit layer records prompt, tool-call, retrieval, approval, and memory-write logs.

That turns a vague deployment question into reviewable structure. What can the agent do without a human? Which systems can it affect? What sensitive data can it see or remember? Could a risky change be caught before deployment? Could an incident be reconstructed? Those are security questions, procurement questions, and governance questions at the same time.

Minimum Authority Record

A useful AgentRiskBOM-style record should be short enough to check at release time and detailed enough to reconstruct an incident.

At minimum, it should identify the agent name, owner, sponsor, purpose, deployment environment, model or runtime version, prompt or policy version, scaffold or orchestration layer, connected tools, tool descriptors, side effects, data classifications reachable by each tool, memory stores, retention policy, retrieval sources, service accounts, token scopes, external destinations, inter-agent communication paths, human approval points, emergency stop, rollback owner, logging status, and field-level evidence status.

The last field matters. A map can be generated from code, declared by a vendor, inferred from configuration, verified against the live system, or reviewed by an auditor. Those are not the same claim. An authority map should preserve who asserted each important field, what evidence supported it, when it was checked, and what remains unknown or redacted.

What the Evaluation Shows

The implementation uses a JSON Schema, YAML corpus files, a risk-scenario library, a rule-based scorer, a diff detector, a control mapper, and rendered reports. The evaluation covers 13 documented open-source agents across coding, RAG, and multi-agent archetypes, with corpus artifacts used to test whether the schema can represent real deployment shapes.

It also uses 52 risk scenarios across 14 categories, including prompt injection, tool poisoning, excessive agency, sensitive-data disclosure, RAG poisoning, memory leakage, credential misuse, unsafe external action, inter-agent trust propagation, missing approval, missing audit logging, overprivileged cloud access, destructive tool misuse, and supply-chain compromise.

The arXiv abstract and PDF report that all 13 corpus artifacts validate against the schema. The paper's coverage analysis gives AgentRiskBOM a native-equivalent score of 14 across 16 capability dimensions, compared with 1.0 for SBOM, 1.5 for AIBOM, and 2.0 for MLBOM. Across modeled risk categories, AgentRiskBOM exposes 100.0% visibility, compared with 10.5% for SBOM-like views and 20.9% for AIBOM-like views.

Drift and Incident Readiness

The strongest governance concept in the paper is agentic authority drift. An agent can become riskier without changing its brand name: a new destructive tool appears, approval gates are removed, logging is disabled, credentials broaden, memory persistence increases, autonomy rises, or an external communication channel opens. If those changes are only scattered across prompts, tool registries, orchestration code, and deployment settings, no one has a single object to diff.

Dutta and Moharir inject 33 structured deployment mutations and report that the diff detector identifies the correct change type for all mutations. That does not prove an agent is safe. It proves something narrower and useful: once authority is declared in a structured artifact, risky declared changes can become visible to release gates before they become incidents.

The same artifact also supports incident readiness. A post-incident reviewer needs to know which prompt policy, tool descriptor, credential, memory store, approval log, retrieval path, and external endpoint were active when the action happened. An audit trail without an authority map can show what happened while leaving the more important question unanswered: why was this agent able to do it?

The practical control is a diffable authority envelope tied to deployment. If a release adds a write-capable tool, broadens a token, turns on persistent memory, changes a retrieval corpus, disables approval, or opens inter-agent delegation, the change should trigger the same kind of review that a new privileged service account would trigger. The map should not merely describe risk after deployment; it should make authority changes blockable before deployment.

Limits That Matter

AgentRiskBOM is not a safety certificate, and the paper says so. It is a risk-scoping and review artifact. It depends on accurate declarations about tools, credentials, memory, approval gates, and logging. If an organization lies, omits fields, or treats the schema as paperwork after the real system has shipped, the artifact will not save it.

The evaluation is also artifact-centered. It tests schema expressiveness, risk visibility, drift detection, and scoring consistency, not live exploitation of every agent in production. The reported Spearman rank correlation of 0.73 between the primary and secondary scorers supports directional ranking, but the paper cautions that thresholds still need human calibration.

There is also a disclosure problem. Publishing every tool, credential pattern, endpoint, and memory path can expose attack surfaces. Hiding every important field makes the record useless. A serious deployment therefore needs tiered access: public summary where appropriate, buyer/operator detail, auditor/regulator depth under confidentiality, and internal security detail protected like other sensitive infrastructure records.

The hardest limit is live reconciliation. An authority map should be checked against the running system: tool registry, identity provider, MCP or plugin configuration, secrets broker, vector store, log pipeline, approval queue, and deployment manifest. Otherwise the record can be syntactically valid and operationally false.

Governance Standard

The practical rule is simple: do not deploy a consequential agent unless its authority envelope is machine-readable, versioned, and diffable. The record should name the model and scaffold, but it should not stop there. It should name tools, side effects, permissions, credential scope, memory behavior, data reachability, approval gates, emergency stops, external action paths, inter-agent trust, and audit evidence.

For procurement, the AgentRiskBOM reading is a checklist against delegation theater. A vendor that can name its model but not its runtime authority has not described the purchased capability. For engineering, it is a release gate: if a change increases autonomy, raises tool tier, disables logging, broadens credentials, or weakens approval, the deployment should require review. For incident response, it is the authority map that lets the organization reconstruct why the agent was able to act.

For public-sector or regulated use, the map should also connect to the AI system inventory, procurement file, risk assessment, safety case, audit trail, vulnerability process, incident report, and public register where disclosure is lawful. A model card may explain intended behavior. A system card may explain evaluations and limits. An AgentRiskBOM-style authority map should explain the delegated powers that make the system consequential.

The release gate should fail closed on high-risk unknowns. Unknown software dependencies may already be unacceptable in some environments; unknown write tools, unknown credentials, unknown memory persistence, or unknown approval bypasses are worse because they hide the path from recommendation to action.

This belongs beside agent operational envelopes, agent logs, tool-scope gates, and runtime policy. The common argument is that agent governance has to leave the prompt and become infrastructure.

Source Discipline

Use the AgentRiskBOM paper for the proposed schema, implementation, corpus, risk categories, coverage figures, mutation test, scoring correlation, and limitations. It is a paper about a risk-scoping artifact, not a proof that the listed agents are secure or that a schema alone can enforce policy.

Use G7, CISA, SPDX, and CycloneDX sources for BOM context: they show that machine-readable AI supply-chain documentation is becoming more formal, but they do not by themselves document runtime authority. Use NIST, NCCoE, CISA agentic-AI guidance, and OWASP for agent-security context: they support the need for identity, authorization, oversight, risk management, and threat modeling, but they do not certify AgentRiskBOM as a standard.

The clean claim is narrower and stronger: when an AI system can act through tools, credentials, memory, and other agents, its bill of materials needs an authority layer. Without that layer, procurement, release review, and incident response can know what the system is made from while missing what the system was allowed to do.

Sources

Return to Blog