TL;DR: Security teams are being pushed to inventory AI systems, but model lists and vendor registers reveal little about actual blast radius. Pillar Security argues that the risk sits in tools, system prompts, data access, and runtime behaviour, not in the BOM itself.
At a glance
What this is: This is an analysis of why AI bills of materials are an incomplete control for agentic AI, because real risk sits in tools, prompts, data access, frameworks, and runtime behaviour.
Why it matters: It matters because IAM, PAM, and NHI teams need to govern what AI systems can do, not just what models they use, especially when agents can reach data, code, and external systems.
Context
AI bills of materials are becoming common governance artefacts, but a list of models and vendors does not explain what an AI system can actually do at runtime. In agentic AI, the security question shifts from inventory to capability, because tools, prompts, data access, and orchestration determine the blast radius.
For identity and access teams, that means the relevant control problem is not simply cataloguing AI assets. It is understanding which non-human identities, delegated permissions, and external tool connections let an AI application cross from observation into action.
Deep repository scanning and runtime guardrails are therefore positioned as complementary controls: one exposes hidden configuration and access paths, the other constrains behaviour as the system executes.
Key questions
Q: What breaks when AI teams rely on an AI BOM for security?
A: An AI BOM breaks down when teams treat it as a security control instead of a record of what exists. It does not show tool permissions, data reach, or runtime actions, so it cannot explain blast radius or stop prompt injection from becoming privileged activity. Security teams need capability mapping and enforcement, not inventory alone.
Q: Why do agentic AI systems create more security risk than standard chatbots?
A: Agentic systems can turn model output into action, which means a bad instruction can affect code flow, tool use, and downstream state. Standard chatbots usually stop at text generation. Agentic AI adds execution authority, so compromise can lead to disclosure, unauthorized changes, or misuse of credentials.
Q: How do security teams know whether agent guardrails are working?
A: They know guardrails are working when denied tool calls are visible in logs, high-risk paths are blocked consistently, and the agent cannot override policy from inside its own session. Observe mode is useful first because it shows what the agent actually tries to do before the team decides where to deny access. The signal is repeatable enforcement, not model compliance.
Q: Should organisations review MCP and assistant configuration files as part of access governance?
A: Yes. Those files often define which tools an agent can reach and how persistent that access is across sessions. If they are changed after approval or reviewed only as code, organisations miss an identity and privilege layer that can expand the agent’s real authority without changing the BOM.
Technical breakdown
Why AI BOMs miss runtime blast radius
An AI BOM is a documentation layer, not an operational security control. It records model names, vendors, versions, and locations, but it does not reveal whether the system has database write access, can call external tools, or follows instructions that override user intent. In agentic AI, the same prompt injection can be a nuisance in a read-only chatbot and a serious breach path in an agent with execution privileges. Security depth comes from understanding the full capability stack, including orchestration, permissions, and the boundaries between model output and real-world action.
Practical implication: Treat AI inventory as a starting point, then map runtime permissions and tool reach before accepting the system as governable.
How tools and MCP configs expand agentic risk
Tools are the bridge from probabilistic output to deterministic action. When an agent can query databases, execute code, send email, or access external APIs, prompt injection becomes an action-oriented threat rather than a text-generation issue. MCP configurations and similar files define which servers and tools an agent can use, which means they also define persistence and abuse paths. If those files are altered after approval, the agent may keep inheriting unsafe access across future sessions. That makes configuration review part of access governance, not just application hardening.
Practical implication: Review tool definitions and MCP configurations as access artifacts, and monitor them for changes that expand execution scope.
Why runtime guardrails are the missing enforcement layer
Static scanning can expose tools, prompts, and hidden configuration risk, but it cannot stop a malicious instruction from being acted on at the moment of execution. Runtime guardrails sit in path and evaluate inputs, outputs, and actions against policy in real time. That matters when the system can reach sensitive data, issue commands, or persist changes. For agentic AI, governance only becomes effective when discovery and enforcement are paired: scanning tells you what is possible, and runtime controls decide what is allowed to happen.
Practical implication: Deploy in-path policy enforcement for high-risk agent actions and align those policies to the capabilities discovered in code review.
Threat narrative
Attacker objective: The attacker aims to turn the AI system’s delegated capabilities into data access, code execution, or persistent operational control.
- Entry occurs when an attacker places malicious instructions, poisoned model artefacts, or hidden configuration changes into the AI application’s repository or connected sources.
- Credential or access abuse follows when the agent uses its tool permissions, data connectors, or system prompts to reach information and systems beyond the user’s intent.
- Impact occurs when the compromised agent writes data, triggers code execution, exfiltrates information, or persists unsafe behaviour through modified configuration.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI BOMs create inventory assurance, not security assurance. Lists of models, vendors, and deployment locations satisfy documentation demands, but they do not describe the delegated power of the system. In agentic AI, the security boundary is defined by tools, prompts, data access, and orchestration, so the operational question is always capability, not presence. That makes inventory a governance artefact and nothing more; practitioners must judge blast radius, not asset count.
The real control plane for agentic AI sits in tool scope and prompt authority. When an AI application can query databases, run code, or send external requests, the identity problem shifts from authentication to action containment. The article’s core point is that prompt injection becomes materially different once the system can act on it. Practitioners should read that as a warning that delegated permissions now define the attack surface as much as the model itself.
Deep repository scanning is the only way to see hidden agentic exposure before runtime. Configuration files, assistant rules, model artefacts, and MCP definitions can all reveal what an application can really do. That matters because the visible BOM often omits the very elements that determine privilege, persistence, and misuse. The practical conclusion is straightforward: if the repository does not show the capability map, the organisation does not yet understand the identity model it has deployed.
Agentic permission inheritance: access controls that assume stable, human-reviewed workflows break down when model instructions and tools can be chained into autonomous action. That assumption failure is visible in frameworks that default to loop-until-solved behaviour without human approval at each step. The implication is that practitioners must govern the action boundary, not just the model inventory.
Runtime guardrails are the enforcement layer that inventory cannot supply. Scanning tells teams where risk exists, but runtime policy decides whether a risky action is blocked, redacted, or allowed to continue. That is especially important for systems that touch PII, credentials, or external communication. The practitioner takeaway is that agentic AI governance only becomes real when discovery and in-path control operate together.
From our research library:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Read next: Agentic AI Identity Guide
What this signals
Agentic permission inheritance: the decisive governance problem is no longer whether an AI system exists, but whether it can inherit action rights through tools, prompts, and external connectors. Once those rights are delegated, the security team is governing behaviour, not inventory.
Deep repository scanning should be treated as the discovery layer for agentic identity risk, while runtime guardrails become the enforcement layer. Together they answer the two questions that matter in practice: what the system can do, and what it is allowed to do at the moment it tries.
For practitioners
- Map delegated tool permissions Inventory every tool, API, and external connector an agent can invoke, then classify whether each action is read-only, write-capable, or persistent. Focus first on systems that can touch databases, code execution, or outbound communications.
- Scan repositories for hidden control paths Review model artefacts, assistant rules, MCP configuration files, and orchestration code for instructions or settings that expand agent capability beyond the documented BOM. Treat these files as access-bearing configuration, not simple developer convenience.
- Constrain high-risk actions in path Place policy enforcement between the agent and its tools so that destructive commands, sensitive data exfiltration, and unauthorised external calls can be blocked before execution completes.
- Separate compliance inventory from security review Use the AI BOM for governance reporting, but require a second review that traces effective privileges, prompt authority, and runtime reach across each high-risk application.
Key takeaways
- AI BOMs are useful for governance reporting, but they leave the operational security question unresolved because they do not describe what an AI system can actually do.
- The highest-risk conditions are agentic workflows with tool access, data access, and external communication, because they turn prompt abuse into real action.
- Security teams need repository-level discovery plus runtime enforcement if they want to control agentic AI rather than merely catalogue it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article is centered on delegated AI action, tool scope, and privilege abuse through agentic behaviour. |
| ASI02 — Tool Misuse | The core risk is that tools turn prompt abuse into database, code, and API misuse. | |
| ASI08 — Cascading Failures | The article describes how one bad step can propagate through autonomous workflows and retries. | |
| Recommendation — Map agent tool reach and privilege boundaries to ASI03 and block actions that exceed intended authority. Inventory every agent tool and restrict high-risk operations to approved execution paths. Add circuit breakers and rollback logic to prevent one compromised action from cascading across the workflow. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Agent access to tools and external systems depends on how those non-human identities are authenticated and authorized. |
| NHI-05 — Overprivileged NHI | The article repeatedly shows that excessive delegated access drives the blast radius of agent compromise. | |
| NHI-06 — Insecure Cloud Deployment Configurations | Misconfigured repositories, MCP configs, and assistant settings expose hidden control surfaces in deployed environments. | |
| Recommendation — Harden agent authentication paths and remove any implicit trust in connected tools or services. Reduce agent permissions to the minimum set of actions required for each workflow. Scan deployed AI application configurations for unsafe defaults and post-approval drift. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article frames inventory, traceability, and governance artefacts as necessary but incomplete for AI security. |
| Recommendation — Establish governance that separates compliance inventory from operational control of AI behaviour. | ||
Key terms
- AI bill of materials: An inventory of the components used by an AI development environment, including models, plugins, hooks, skills, and agent integrations. It gives security teams visibility into what is operating in the stack so they can assess trust, dependency risk, and governance coverage.
- Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
- Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
- MCP Configuration: MCP Configuration is the set of settings that tells an AI agent how to connect to Model Context Protocol tools, data sources, and permissions. It defines endpoints, authentication, allowed actions, and context boundaries. In practice, it governs how an agent discovers and uses external capabilities without exposing unnecessary data or control.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org