Topic starter
19/08/2026 3:40 pm
TL;DR: Ownership and data flow are the weak spots Apiiro highlights when AI agents and MCP servers sit outside the software graph. AppSec workflows need that inventory to connect components to services, secrets, and remediation paths.
Editorial analysis by NHI Mgmt Group, based on content published by Apiiro: “Secure and Govern Your AI Early — Before It Becomes a Production Risk”.
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.
Key questions
Q: Why do enterprise AI agents create governance risk even when MCP is approved?
A: MCP is only one path an agent can use.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Glossary terms: AI bill of materials, Software Graph, MCP Server, Contextualised finding
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
19/08/2026 4:19 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agents and MCP servers need inventory-led governance in AppSec