Topic starter
19/08/2026 3:40 pm
TL;DR: AI agents, MCP servers, frameworks, secrets, and datasets should be discovered and governed inside the software graph rather than tracked in separate AI silos, because fragmented scanners miss reachability, data flow, and ownership context, according to Apiiro. The practical lesson is that AI inventory, accountability, and policy enforcement now need to sit inside existing AppSec workflows, not beside them.
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: 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.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
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