Who is accountable for securing AI agent architectures built on MCP?

Why This Matters for Security Teams

AI agent architectures built on MCP shift accountability away from a single application boundary and into a chain of decisions: which tools an agent can call, which connectors it can trust, which secrets it can touch, and what the runtime is allowed to do when intent changes mid-task. That means security ownership cannot be left to the protocol alone. As NHIMG has noted in its The State of MCP Server Security 2025 research, only 18% of MCP server deployments implement access scoping for tool permissions, while 53% expose credentials through hard-coded configuration values.

That is why the accountable party is the deploying organisation, not the protocol vendor. In practice, the teams approving architecture decisions must treat MCP as an execution pathway that can amplify privilege, not as a neutral transport layer. Guidance from the OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework both point toward governance, runtime control, and accountability as operational requirements, not optional documentation. In real environments, responsibility is usually discovered only after an agent has already overreached its intended scope.

How It Works in Practice

Accountability should be mapped to the control points that actually shape risk. For MCP-based agent systems, that usually means AppSec, AI platform engineering, identity, and the product owner share responsibility under a clear approval model. Security teams define the guardrails; engineering implements them; the business owner accepts residual risk. The organisation remains accountable even when a vendor provides the protocol, the model, or the connector stack.

Practically, this means reviewing architecture before rollout and enforcing runtime controls at the point of tool use. Current guidance suggests four controls matter most:

• Scope tool access per agent, not per environment, so a connector cannot be reused beyond its intended task.
• Issue short-lived credentials for each task or session, and revoke them automatically when the work completes.
• Bind agent actions to workload identity rather than static shared secrets, so the system proves what it is before it acts.
• Evaluate policy at request time, using context such as tool, data sensitivity, user intent, and session state.

This is where CSA MAESTRO agentic AI threat modeling framework and NIST AI Risk Management Framework help translate abstract accountability into operational review. NHIMG’s OWASP NHI Top 10 also aligns with this view: secrets exposure, overbroad trust, and weak isolation are governance failures, not just implementation bugs. These controls tend to break down when agents are allowed to chain tools across multiple domains because no single owner has visibility into the full execution path.

Common Variations and Edge Cases

Tighter accountability often increases approval overhead, so organisations have to balance faster agent delivery against stronger pre-deployment review and runtime monitoring. That tradeoff becomes sharper when MCP is used in internal developer platforms, multi-agent workflows, or shadow deployments where connectors are added quickly and ownership is diffuse.

There is no universal standard for this yet, but current guidance suggests a few recurring edge cases:

• Shared MCP servers create ambiguous ownership unless one team is explicitly named as the control owner.
• Third-party connectors can obscure whether the risk sits with the model provider, the tool vendor, or the deploying organisation, but accountability still lands with the deployer.
• Security exceptions become dangerous when they are treated as temporary operational shortcuts rather than time-bound, reviewed approvals.
• Agent behaviour can change after prompt updates, tool additions, or policy drift, so one-time sign-off is not enough.

NHIMG’s reporting on AI Agents: The New Attack Surface shows why this matters: 80% of organisations report agent behaviour beyond intended scope, and 92% agree governance is critical while only 44% have implemented policies. That gap is exactly where accountability fails in practice. For teams comparing this with the OWASP Agentic AI Top 10 and the MITRE ATLAS adversarial AI threat matrix, the takeaway is simple: if the organisation deploys the agent, the organisation owns the risk.

Related resources from NHI Mgmt Group

• What is the difference between securing an AI model and securing an MCP-enabled agent?
• Who is accountable when an AI agent takes action through an MCP server?
• Who is accountable when an AI agent exposes sensitive Supabase data through MCP access?
• Who is accountable when an AI agent exposes regulated data through Zapier MCP workflows?