Notifications
Clear all
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.
NHIMG editorial — based on content published by Apiiro: Enhancing Apiiro’s AI Bill of Materials with AI Agents and MCP Server Detection Capabilities
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.
Questions worth separating out
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.
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.
Q: What breaks when AI inventory is handled as a standalone security silo?
A: Teams lose the relationships that make risk understandable.
Practitioner guidance
- 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.
- 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.
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
👉 Read Apiiro's analysis of AI agents, MCP servers, and AI BOM governance →
AI agents and MCP servers: what this means for AppSec governance?
Explore further
19/08/2026 4:19 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: AI agents and MCP servers need inventory-led governance in AppSec
