Who should be accountable when an MCP integration exposes cross-tenant data?

Accountability should sit with the team that owns the connector, the policy boundary, and the downstream service, not just with the vendor or the user who triggered the action. Under IAM and NHI governance, the control owner must prove scoping, logging, and offboarding for the integration. If those controls are absent, the organisation owns the exposure.

Why This Matters for Security Teams

Cross-tenant exposure in an mcp integration is not just a data leakage event. It is usually a governance failure across identity scope, tool permissions, and service ownership. In practice, the integration becomes a shared attack surface, which is why accountability cannot stop at the vendor boundary or the end user who invoked the agent. OWASP’s OWASP Agentic AI Top 10 treats excessive autonomy and weak authorization as first-order risks, not edge cases.

NHIMG research shows how quickly this breaks down operationally: the The State of MCP Server Security 2025 report notes that only 18% of MCP server deployments implement any form of access scoping for tool permissions, while 53% expose credentials through hard-coded configuration values. That combination makes tenant boundaries fragile long before an incident appears. The control owner must be able to show who approved access, how scope was enforced, and how offboarding or revocation worked when the integration changed.

In practice, many security teams encounter cross-tenant contamination only after a customer, auditor, or regulator spots it, rather than through intentional design review.

How It Works in Practice

Accountability should be assigned to the team that owns the connector, the policy boundary, and the downstream service because those are the places where tenant separation is actually enforced. The vendor may provide the platform, but the organisation operating the integration decides what data the agent can reach, which tools it can call, and what logs prove containment. That is the operational reality behind NHI governance and the reason ownership must be explicit in the control register.

For MCP and similar agent integrations, the practical pattern is:

• Bind the agent or connector to a workload identity, not a shared human account.
• Apply per-tenant policy at request time, using the tenant context, tool name, and data classification.
• Issue short-lived secrets or tokens with narrow scope, then revoke them when the task ends.
• Record tool invocations, data reads, and downstream writes in an auditable trail.
• Define offboarding so access is removed when the integration, tenant mapping, or business purpose changes.

That approach aligns with emerging guidance in the 52 NHI Breaches Analysis, which shows that identity sprawl and weak lifecycle control are recurring patterns in real-world incidents. It also matches the direction of the OWASP Top 10 for Agentic Applications 2026, where runtime authorization and tool isolation are central concerns. Current guidance suggests that static, role-only permissions are insufficient when an autonomous integration can change behaviour by tenant, prompt, or downstream context.

These controls tend to break down when a single MCP server serves multiple customers with shared credentials and weak per-request policy evaluation because tenant context is lost at the point of action.

Common Variations and Edge Cases

Tighter tenant isolation often increases integration overhead, requiring organisations to balance faster deployment against stronger containment. That tradeoff becomes most visible in legacy platforms, shared service accounts, and low-code connectors where teams want one integration to serve many business units. Best practice is evolving, but there is no universal standard for this yet: the safe answer is usually to make the tenant boundary explicit in policy and logging, even if that means more implementation work.

One edge case is a vendor-managed MCP service where the provider controls the runtime but the customer defines the data policy. In that model, accountability is shared, but the customer still owns the decision to connect sensitive systems and must verify that the vendor’s controls meet the required isolation level. Another case is a multi-agent workflow where one agent fetches data and another transforms or forwards it. The accountable owner is the team controlling the full chain, because leakage often happens at the handoff, not the first read.

For broader agent risk context, the Ultimate Guide to NHIs — Key Research and Survey Results and the Anthropic — first AI-orchestrated cyber espionage campaign report both reinforce the same point: autonomous systems amplify small access mistakes into cross-boundary incidents faster than traditional IAM assumptions anticipate.

Related resources from NHI Mgmt Group

• Who is accountable when an MCP client exposes data through overbroad permissions?
• Who is accountable when a SaaS integration exposes customer data?
• Who is accountable when a malicious MCP server exposes enterprise data or actions?
• Who is accountable when an MCP connector exposes sensitive data or actions?