Accountability sits with the organization that granted the delegated access, not with the model itself. The deciding factors are which identity was authorized, what scope it held, and whether the request path was logged well enough to reconstruct responsibility after the fact.
Why This Matters for Security Teams
An LLM-initiated MCP request is not just “an app call gone wrong.” It is a delegated action performed through a chain of identities, scopes, and tool permissions that must be explainable after the incident. Accountability therefore follows the organization that authorized the access, the workload identity that executed the request, and the logging that proves what happened. Without those three, incident response turns into guesswork.
This is why MCP security cannot be treated as a prompt-safety problem alone. Current guidance from OWASP Top 10 for Agentic Applications 2026 and NIST’s AI Risk Management Framework both point to governance, traceability, and runtime control as the real control plane. NHIMG research shows the operational gap clearly: in The State of MCP Server Security 2025, only 18% of MCP server deployments implemented any form of access scoping for tool permissions, while 53% exposed credentials through hard-coded values.
In practice, many security teams encounter accountability failures only after data has already been exposed and the request trail is too incomplete to reconstruct responsibility.
How It Works in Practice
For MCP, accountability is determined by the control path, not by the model’s intent. The model may initiate a request, but the organization decides whether the agent had permission, the tool server enforces scope, and the identity layer determines which workload was actually allowed to act. That means the right question is not “did the model leak data?” but “which delegated identity, policy, and approval chain permitted access?”
Practically, teams should separate the agent from its credentials. Use workload identity as the primitive, then issue short-lived credentials or tokens only for the task at hand. That makes the request attributable and limits the blast radius if the agent chains tools unexpectedly. The security model should also include request-time policy evaluation, not just pre-defined roles, because autonomous systems can change behavior based on context. The combination of NIST AI 600-1 Generative AI Profile and the CSA MAESTRO agentic AI threat modeling framework reflects this shift toward runtime governance.
- Bind each MCP request to a unique workload identity, not a shared service account.
- Issue just-in-time, short-lived access tokens for each task or tool invocation.
- Log the initiating identity, policy decision, target tool, and data objects touched.
- Revoke access automatically when the task completes or the risk context changes.
NHIMG’s 52 NHI Breaches Analysis shows why this matters: when identity and secret handling are weak, investigators lose the chain of custody needed to assign responsibility. These controls tend to break down in multi-tenant MCP environments because shared tool servers and reused credentials collapse attribution across teams.
Common Variations and Edge Cases
Tighter MCP governance often increases integration overhead, requiring organisations to balance attribution quality against developer velocity. That tradeoff is real, especially where agents must call many tools, operate across business units, or work inside legacy systems that were never designed for workload identity.
There is no universal standard for this yet, so current guidance suggests treating the model as a requester, not the accountable actor. In edge cases, accountability can be shared operationally even if it is not shared legally: the business owner may approve the access, platform security may own the control plane, and the application team may own logging and policy enforcement. The critical failure is when each group assumes another layer is responsible.
This becomes more complex when MCP requests are forwarded through middleware, brokered by an orchestration layer, or executed by multiple agents in sequence. If the request path is not preserved end to end, the organization may know that data exposure occurred but not which delegated identity or policy allowed it. That is the point where incident response and compliance diverge. Emerging threat research in AI Agents: The New Attack Surface report and the broader agentic guidance in OWASP Agentic Applications Top 10 both reinforce the same lesson: if you cannot reconstruct the chain, you cannot defend the decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Covers agentic request abuse and tool misuse, central to MCP exposure accountability. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Addresses delegated identity misuse and weak attribution for non-human actors. |
| CSA MAESTRO | TRUST-4 | Focuses on runtime governance and trust boundaries for agentic workflows. |
| NIST AI RMF | AI RMF governance supports accountability, traceability, and oversight for AI actions. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control is essential when agents act through delegated scopes. |
Map each MCP tool path to runtime controls that log, limit, and explain every agent action.
Related resources from NHI Mgmt Group
- Who is accountable when a third-party identity causes data exposure?
- Who is accountable when a Salesforce integration is over-privileged and causes data exposure?
- Who is accountable when a vendor or AI workload causes bulk data exposure?
- What are MCP Authorization Extensions and how do they help organizations?
