Who is accountable when AI asset inventories, AI-BOM evidence, or insecure MCP configurations are missing?

Why This Matters for Security Teams

When AI asset inventories, AI-BOM evidence, or MCP configuration records are missing, the issue is rarely a single technical defect. It becomes a governance failure because the organisation cannot prove what it has deployed, which components it relies on, or whether those components were configured securely. That makes risk acceptance, audit response, and incident containment much harder. The control problem is reinforced by current guidance on agentic AI security, including the OWASP Agentic AI Top 10, which treats inventory and tool governance as operational security concerns, not optional documentation.

Accountability usually sits with the organisation operating the AI environment, even when the gap was first noticed by a vendor, assessor, or red team. Security, platform engineering, and compliance each hold part of the answer: security defines the control intent, platform teams implement and maintain it, and compliance verifies evidence quality. Where MCP is in use, the same principle applies to tool exposure, permissions, and trust boundaries. In practice, many teams only discover the problem after a procurement review, audit request, or incident investigation has already exposed the absence of evidence.

How It Works in Practice

Operational accountability is easiest to manage when AI inventory and evidence collection are treated as part of the normal control stack, not as a one-time governance exercise. That means defining who owns the authoritative register for AI services, who maintains the AI-BOM or equivalent dependency record, and who signs off on MCP configuration baselines. The evidence should be tied to change management, release approval, and periodic control testing so it stays current as models, tools, and connectors change.

For most organisations, the practical workflow looks like this:

• Maintain a living inventory of AI systems, model endpoints, agents, and MCP-enabled tools.
• Record model provenance, third-party dependencies, and deployment context in AI-BOM or equivalent evidence.
• Document secure configuration standards for MCP servers, tool permissions, and secret handling.
• Assign a named control owner for evidence completeness, not just for technical implementation.
• Test that inventory data matches what is actually deployed in production and pre-production.

This is where frameworks help. NIST SP 800-53 Rev 5 Security and Privacy Controls gives organisations a control language for inventory, configuration management, and accountability. In parallel, the OWASP Top 10 for Agentic Applications 2026 helps security teams think about tool exposure, agent behaviour, and trust relationships across the runtime. The practical goal is not perfect documentation for its own sake. It is defensible evidence that shows what exists, who approved it, and how it is governed across the full lifecycle.

These controls tend to break down when AI environments are provisioned by multiple teams through rapid self-service pipelines because ownership becomes fragmented and the evidence trail no longer matches the running system.

Common Variations and Edge Cases

Tighter evidence control often increases operational overhead, requiring organisations to balance audit readiness against delivery speed. That tradeoff is real, especially in environments where models, prompts, connectors, and MCP tools change frequently. Best practice is evolving, but current guidance suggests the most defensible approach is to distinguish between the system owner, the control owner, and the person who generates the evidence. Those roles may be separate, but they should never be ambiguous.

There are also edge cases. In shared platform models, a central AI platform team may maintain the baseline inventory while product teams own their deployed agents and tool integrations. In outsourced or managed environments, the provider may supply reports or attestations, but the operating organisation still owns accountability for accepting the risk and validating the evidence. For highly dynamic agentic systems, inventory snapshots can become stale quickly, so continuous discovery and configuration drift detection are often more useful than periodic spreadsheet reviews.

For teams formalising governance, the most useful question is not who created the gap, but who had authority to prevent it. If no one owns the control, then no one owns the evidence. That is especially important where AI systems can access secrets, trigger actions, or call external tools through MCP, because missing configuration records can hide a much larger exposure.

Related resources from NHI Mgmt Group

• Who should be accountable for missing evidence in GRC audits?
• Who is accountable when AI-assisted code changes affect compliance evidence?
• Who is accountable when an AI agent takes action through an MCP server?
• Why do flat AI asset inventories miss the real security risk?