AI agents and MCP servers need inventory-led governance in AppSec

At a glance

What this is: Apiiro frames AI BOM as a way to discover AI agents, MCP servers, models, secrets, and datasets inside the software graph and correlate them with broader application risk.

Why it matters: For IAM and NHI teams, the key issue is that AI resources now behave like governed identities and privileged components, so visibility, ownership, and access scope become control problems, not just detection problems.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Apiiro's analysis of AI agents, MCP servers, and AI BOM governance

Context

AI BOM matters because AI resources are now embedded in code, pipelines, and runtime services rather than living as isolated experiments. When AI agents, MCP servers, and model integrations are treated as separate from the rest of the application graph, teams lose the ability to connect exposure, ownership, and remediation.

This is also where identity governance re-enters the discussion. AI agents and MCP servers create new trust boundaries around tool use, data access, and delegated action, which means IAM, PAM, and NHI-style controls become relevant whenever these systems can reach sensitive APIs or secrets. Apiiro’s central claim is that security teams need a unified inventory, not another standalone scanner.

Key questions

Q: How should security teams govern MCP servers used by AI coding assistants?

A: Treat MCP servers as privileged trust boundaries, not simple data sources. Security teams should classify each server by the authority it can influence, sanitize any user-generated or third-party content before delivery, and limit the agent’s tool access so malicious context cannot easily become destructive action.

Q: Why do local AI agents complicate identity and access management?

A: They can retain legitimate permissions while changing timing, prioritisation, and action sequence outside human presence. That means the visible identity may remain stable even as the operational behaviour becomes autonomous. IAM teams then lose the simple link between user session, authorisation, and accountability.

Q: What breaks when AI inventory is handled as a standalone security silo?

A: Teams lose the relationships that make risk understandable. A standalone inventory can show that an agent exists, but not whether it is reachable from untrusted input, connected to secrets, or owned by a service team. Without those links, severity is guessed and remediation stalls in review.

Q: How do security teams decide whether an AI risk is operationally serious?

A: Ask whether the component is reachable, whether it can touch sensitive data, and whether its access can be changed or revoked quickly. If the answer to any of those is unclear, the finding is already governance-relevant. Serious AI risk is usually defined by connected exposure, not by the presence of a model alone.

Technical breakdown

Why AI BOMs need to map AI agents and MCP servers into the software graph

An AI Bill of Materials only becomes useful when it describes relationships, not just objects. In practice, that means mapping AI agents, MCP servers, frameworks, datasets, secrets, and APIs into the same dependency graph that already tracks application code and infrastructure. Once those relationships are visible, teams can see whether an AI component is reachable from untrusted input, whether it touches sensitive data, and whether it is tied to a business service or owner. That is the difference between a catalog and a control plane.

Practical implication: inventory AI components in the same graph as APIs, secrets, and services so reachability and ownership can be assessed together.

How contextual correlation turns AI findings into actionable risk

Point-in-time AI scanning is weak because it produces isolated findings with no sense of combined exposure. Correlation fixes that by normalising signals from SAST, SCA, DAST, CSPM, and API security into a single view of the application. A Hugging Face client, a sensitive API, and an exposed path may each look acceptable alone, but together they create a materially different risk profile. Context is what allows the security team to distinguish noise from exploitability.

Practical implication: prioritise correlation logic that joins AI findings to code, cloud, and API signals before assigning severity.

Why ownership and governance need to sit beside AI inventory

Visibility without accountability does not change behaviour. If an AI agent, dataset, or MCP server cannot be tied to a service owner, development team, and review workflow, remediation becomes a queue rather than a decision. That is why governance must connect AI assets to CMDB records, service ownership, and policy enforcement. For IAM and NHI practitioners, this is the familiar lesson of identity lifecycle control applied to AI-adjacent systems: who owns it, who approves it, and who can change its access model.

Practical implication: bind each AI resource to an accountable owner and a workflow that can approve, review, and revoke access decisions.

NHI Mgmt Group analysis

AI BOM is becoming an identity problem as much as an AppSec problem: once AI agents and MCP servers can call tools, reach data, and trigger workflows, they behave like governed non-human actors. The important question is no longer whether the component exists, but whether its access scope, ownership, and lifecycle are controlled. That shifts the discussion from detection to identity governance, especially where delegated action touches sensitive systems.

Apiiro’s framing reflects a broader market shift away from single-purpose scanners: teams do not need another point tool that spots one AI issue in isolation. They need a model that explains how AI assets interact with APIs, secrets, cloud services, and business ownership. The category is moving toward contextual governance, and practitioners should expect AI security to be measured by integration depth rather than alert volume.

Tool reachability is the named concept practitioners should watch: AI risk becomes materially worse when a model, agent, or MCP server can reach external tools without strong scoping and accountability. That is the real governance gap behind many AI security failures. For practitioners, the test is simple: if the system can act, it needs an access model that is as explicit as any other privileged workload.

Inventory alone will not solve AI governance debt: organisations can discover AI components faster than they can classify, approve, and retire them. That creates a governance backlog similar to what identity teams saw with service accounts and API keys, only now the surface includes agentic workflows and model dependencies. The mature response is to align discovery with policy, ownership, and lifecycle controls from the start.

NHI and IAM teams should treat AI resources as control-plane participants, not passive software artifacts: if an AI system can consume secrets, call tools, or access datasets, it sits inside the same trust model as other privileged non-human identities. That makes least privilege, reviewability, and revocation the right governance lens. Practitioners should therefore fold AI inventory into identity governance rather than leaving it solely to AppSec.

What this signals

Tool reachability will become the deciding control in AI governance. As AI agents and MCP servers proliferate, security programmes will need to know not just what exists, but what each component can reach and modify. That pushes teams toward combined identity, application, and secret governance rather than isolated AI scanning, and it aligns closely with the governance concerns described in OWASP Agentic AI Top 10.

AI governance debt will show up first as ownership debt. If teams can discover AI resources faster than they can assign accountability, the backlog will grow in the same way service-account sprawl did in earlier identity programmes. The next maturity step is not just discovery, but policy-backed ownership and revocation.

IAM and NHI teams should prepare for AI systems to enter the privileged inventory. Once agents can use tools and secrets, they need controls closer to NIST Cybersecurity Framework 2.0 and NIST AI Risk Management Framework thinking than to simple asset tracking. The programme shift is from counting AI components to governing what they are allowed to do.

For practitioners

• Map AI components to accountable owners Bind each AI agent, MCP server, model, and dataset to a named service owner and a review workflow so every component has a lifecycle and escalation path. Use CMDB or service catalog records to keep ownership current.
• Correlate AI findings with code and cloud signals Join AI detection with SAST, SCA, DAST, CSPM, and API security data so exposure is scored by reachability, sensitive data flow, and exploit chain context rather than by isolated scanner output.
• Treat MCP access as scoped privileged access Apply least-privilege thinking to tool permissions, external API reach, and secret access for MCP servers and agents, then review whether any integration can act beyond the narrow task it needs.
• Insert AI assets into remediation workflows Route AI-related findings into the same pull request, ticketing, and approval paths used for other application risks so remediation does not depend on a separate AI queue.

Key takeaways

• AI BOMs matter because AI agents and MCP servers now create governance problems that look a lot like privileged non-human identity risk.
• Fragmented AI scanners miss the relationships that determine real exposure, especially reachability, data flow, and ownership.
• Practitioners should treat AI inventory, policy enforcement, and lifecycle accountability as one control problem rather than three separate ones.

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.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• Tool Permission Scoping: The practice of limiting what a non-human identity can do with each tool, including which data sources it can reach and which actions it can trigger. Strong scoping is a core control for agent governance because it reduces overreach, improves auditability, and supports revocation.

What's in the full article

Apiiro's full post covers the operational detail this post intentionally leaves for the source:

• How Deep Code Analysis maps AI agents, MCP servers, models, datasets, and secrets into the application graph
• How AI findings are correlated with SAST, SCA, DAST, CSPM, and API security signals for prioritisation
• How ownership is linked through CMDB integrations such as ServiceNow to support governance workflows
• How AI-specific risks are surfaced inside developer workflows and remediation guidance

👉 Apiiro's full post covers the AI BOM model, correlation approach, and ownership mapping details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a structured way to connect identity controls to emerging AI and application risks.