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

At a glance

What this is: This is an AppSec analysis of why AI agents and MCP servers need to be discovered, inventoried, and governed as part of the software graph rather than treated as isolated AI assets.

Why it matters: It matters because AppSec teams cannot manage AI-driven risk, secrets exposure, or data leakage if AI components sit outside existing ownership, policy, and remediation workflows.

By the numbers:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.

Context

AI agents and MCP servers expand the attack surface because they add new execution paths, new data flows, and new secrets-bearing components into existing applications. When those resources are tracked in separate AI tools, teams lose the context needed to understand what reaches sensitive systems, who owns it, and how quickly it can be remediated.

The governance problem is not just visibility but correlation. AppSec teams already know that isolated scanners create backlog and blind spots, and the same failure mode now applies to AI resources that sit inside codebases, APIs, and service dependencies. The identity angle is real here because agents, servers, and service accounts all rely on inventory, authorization, and accountability to stay governable.

Key questions

Q: What breaks when organizations do not inventory AI agents and MCP connections?

A: Security teams lose the ability to answer what exists, what it can reach, and who owns it. Without that baseline, policy, monitoring, and incident response all become incomplete. The result is blind spots where agents can act, connect, and expand their effective scope without clear governance.

Q: Why do enterprise AI agents create governance risk even when MCP is approved?

A: MCP is only one path an agent can use. Agents may also run CLIs, execute Skills, or generate code that calls APIs directly, which can bypass narrow controls if governance is tied only to one interface. Organisations need a control plane that spans all agent actions, with logging, access review, and clear approval boundaries.

Q: What mistakes do AppSec teams make when they treat AI as a separate silo?

A: They usually overvalue narrow AI scanners and undervalue the surrounding application graph. That leads to duplicate alerts, poor severity ranking, and weak remediation because the team cannot see how the AI component interacts with APIs, code, secrets, and infrastructure.

Q: How should teams govern AI resources once they are connected to business services?

A: Map each AI component to a service owner, link it to policy enforcement, and require the same review path used for other production assets. That turns AI from an unmanaged object into something with lifecycle accountability, traceability, and a clear remediation route.

Technical breakdown

Why AI agents and MCP servers create a new inventory problem

AI agents are software entities that can select actions and tools at runtime, while MCP servers broker access between those agents and external systems. That combination creates a moving target for AppSec because the risk is not just code presence, but the runtime relationships among agents, tools, APIs, datasets, and secrets. Traditional scanners usually see a narrow artifact, not the connected control plane around it. When inventory is incomplete, governance fails upstream: ownership, reachability, and data handling decisions are made without a full map of the environment.

Practical implication: inventory AI components as first-class software assets, not as sidecar findings.

Why reachability and data flow matter more than isolated findings

An AI framework, secret, or model file may look low risk in isolation, but its exposure changes once it is reachable from external inputs or connected to sensitive data. That is the core reason AI risk cannot be judged by presence alone. In practice, the meaningful question is whether an AI resource can be influenced, supplied with sensitive context, or made to act on production data. This is where software graph context matters: it links code, infrastructure, and security findings into a single risk picture instead of separate alert streams.

Practical implication: correlate AI findings with API, SAST, CSPM, and data-flow context before assigning severity.

Why accountability has to sit inside the same workflow as detection

AppSec governance breaks down when teams can identify an AI resource but cannot tie it to an owner, service, or remediation path. AI BOM thinking only works when inventory connects to accountability, because policy enforcement depends on someone being responsible for approving, fixing, or removing the asset. That is especially important for agents and MCP servers, which can be introduced quickly and forgotten just as fast. A governed AI component is one with a traceable owner, a defined business service, and an enforceable review path.

Practical implication: bind AI inventory to CMDB and service ownership before you rely on policy enforcement.

Threat narrative

Attacker objective: The attacker aims to exploit poorly governed AI components to reach sensitive data, abuse trusted integrations, or trigger unsafe application behaviour.

1. Entry occurs when AI agents, MCP servers, or related frameworks are introduced into application code and exposed through reachable inputs or APIs.
2. Credential and data exposure follow when those components carry secrets, tokens, or sensitive prompts into connected workflows.
3. Escalation happens when an AI component can influence broader application behaviour or access downstream services without sufficient governance.
4. Impact is delivered through secrets leakage, sensitive data disclosure, or unsafe AI-driven actions inside production systems.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

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

Inventory-led governance is now the decisive AppSec control for AI systems. AI agents and MCP servers do not become governable simply because they are detected; they become governable when they are mapped to code, owners, services, and data flows. This is the same lesson AppSec learned with APIs and cloud assets, but AI raises the stakes because runtime behaviour can change after deployment. The practitioner conclusion is straightforward: if the AI component is outside the software graph, the control is already incomplete.

AI risk becomes operationally visible only when detection is joined to reachability and accountability. A scanner that finds a framework or secret in isolation does not tell a team whether it can be reached from an external input, whether it touches sensitive data, or who must remediate it. That is why fragmented AI tooling creates backlog instead of control. The field should treat AI BOM capability as a governance layer, not a discovery novelty, with the software graph acting as the authoritative record.

AI agents are forcing AppSec to confront a familiar but sharper form of context collapse. Security teams have repeatedly seen specialised scanners fragment responsibility across point tools, and AI is repeating that pattern in a more dynamic environment. The difference is that agents and MCP servers can combine runtime decision-making with access to sensitive services, making ownership and authorisation failures more consequential. The practitioner takeaway is to govern AI components where the existing application controls already live, rather than building a separate AI silo.

AI governance debt is the right named concept for this pattern. It is the accumulation of AI resources that were introduced faster than teams could inventory, own, and policy-check them. Once that debt builds, alerts multiply while assurance declines, because no one has a complete picture of which AI assets exist or how they connect. The practical response is to reduce that debt by making AI inventory, ownership, and policy enforcement part of the standard AppSec lifecycle.

This shift does not replace AppSec practice, it extends it. The strongest organisations will not ask whether AI needs special handling in isolation, but whether their existing application governance can see AI components with enough fidelity to be trusted. That means inventory, reachability, ownership, and remediation workflows must all converge on the same record. The practitioner conclusion is to treat AI governance as an application-security operating model problem, not a point-solution problem.

From our research library:

• Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to the 2026 Infrastructure Identity Survey.
• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
• Read next: MCP Security Guide

What this signals

AI governance debt: the longer teams leave AI agents and MCP servers outside the standard application inventory, the harder it becomes to recover trustworthy ownership and policy enforcement. AppSec programmes should assume that every unmanaged AI component will eventually create a control exception, then reduce that exposure by making discovery part of the normal development and review workflow.

Inventory without correlation creates noise, not assurance. The practical programme shift is to tie AI component discovery to existing application security evidence so that sensitive inputs, external reachability, and accountable ownership are evaluated together rather than in separate queues.

For practitioners

• Embed AI components into the software graph Classify AI agents, MCP servers, models, datasets, and AI-related secrets as first-class application assets so they inherit existing reachability and ownership context.
• Correlate AI findings with existing security telemetry Join AI detection to SAST, SCA, DAST, CSPM, and API security results so isolated issues can be ranked by actual exposure and data-flow risk.
• Bind AI inventory to service ownership Tie each AI resource to a business service and accountable owner in CMDB or equivalent workflow before allowing policy enforcement to rely on it.
• Review AI-related secrets and tokens as a distinct class Track keys and tokens tied to AI services separately from general application secrets so hidden exposure does not get lost in generic credential inventories.

Key takeaways

• AI agents and MCP servers should be governed as part of the software graph because standalone AI scanners cannot reliably show reachability, ownership, or data flow.
• The main control gap is not discovery by itself but inventory-led governance that ties AI components to services, secrets, and remediation workflows.
• AppSec teams should treat AI inventory as an operating model issue, because policy enforcement only works when the AI asset is already inside the normal security workflow.

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.
• Software Graph: A software graph is a structured model of code, APIs, packages, data flows, and related components. It gives agents and analysts a reusable view of the application landscape so they do not have to reconstruct architecture from scratch on each query.
• 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.
• Contextualised finding: A contextualised finding is a security issue enriched with reachability, ownership, and business or runtime context. That context turns a raw detection into something a practitioner can rank, assign, and remediate without guessing whether the issue is real or exploitable.

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 helps security practitioners connect identity controls to the broader application and cloud workflows that now include AI systems.