Who is accountable when AI agents expose sensitive Google Drive data through MCP tool calls?

Accountability usually sits with the organisation operating the agent, the identity team defining access, and the security team governing data controls. If regulated data is involved, compliance must also verify logging, disclosure tracking, and policy enforcement. The key is to assign ownership for both access decisions and data handling before deployment.

Why This Matters for Security Teams

When an AI agent exposes sensitive Google Drive content through MCP tool calls, the failure is rarely just “bad output.” It is usually an identity, authorization, and data-governance breakdown happening at runtime. Static role assignments do not map cleanly to autonomous behaviour, especially when an agent can decide which tools to invoke, in what sequence, and with what context. That is why current guidance increasingly treats agent risk as an access-and-control problem, not only a model-safety problem, as reflected in the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework.

The accountability question matters because the blast radius spans three layers at once: the agent operator, the team that issued the underlying access, and the data owners whose content can be surfaced or copied. NHIMG research shows why this cannot be treated as theoretical. In the AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already acted beyond intended scope, including inappropriate data sharing. In practice, many security teams discover these failures only after a sensitive file has already been exposed, rather than through intentional access review.

How It Works in Practice

Accountability in this scenario should be assigned before deployment, but enforcement has to happen every time the agent makes a request. The organisation operating the agent owns the outcome, because the agent is acting under delegated authority. The identity team usually owns the workload identity, token lifecycle, and access boundaries. The security team owns logging, alerting, DLP, and policy enforcement. Compliance and legal become accountable for evidence retention and disclosure obligations when regulated content is involved.

The practical control model is moving away from broad, static grants and toward context-aware decisions. An agent should not receive open-ended Drive access just because it belongs to a general “assistant” role. Instead, use workload identity and short-lived credentials so access is issued per task and revoked automatically when the task ends. This is the operating model behind current guidance on agentic systems, and it aligns with emerging thinking in the CSA MAESTRO agentic AI threat modeling framework and the MITRE ATLAS adversarial AI threat matrix.

• Define the agent as a distinct workload identity, not as a human proxy.
• Scope MCP tools to the minimum files, folders, and actions required for the task.
• Use runtime policy checks before each sensitive tool call, not just at login.
• Log the prompt, tool invocation, file target, policy decision, and human approver where applicable.
• Revoke or rotate credentials immediately after the task completes.

This is where MCP-specific risk becomes visible. NHIMG research on OWASP NHI Top 10 and the State of MCP Server Security 2025 shows how quickly tool permissions and secrets exposure can outpace governance. These controls tend to break down when MCP servers are wired to broad Drive scopes, because the agent can chain tool calls faster than reviewers can reconstruct the access path.

Common Variations and Edge Cases

Tighter agent control often increases operational overhead, requiring organisations to balance faster automation against stronger approval and monitoring processes. That tradeoff becomes harder when the agent supports multiple business units, because one static permission model may not fit different data classifications or regional obligations.

There is no universal standard for this yet, but current guidance suggests three common edge cases need special handling. First, delegated human workflows can blur ownership if an agent is “helping” an employee with Drive actions. Second, multi-agent pipelines complicate blame assignment because one agent may retrieve data, another may summarise it, and a third may distribute it. Third, regulated records and legal hold requirements mean that a technically permitted disclosure can still be a governance failure if it bypasses retention or review rules.

For teams building policy, the safest interpretation is simple: the operator is accountable for the agent’s behaviour, the identity team is accountable for the credentials and scoping model, and the data owner is accountable for classification and disclosure requirements. NHIMG has documented similar failures in incidents such as the Gemini AI Breach, where tool-connected data access became the real incident surface. Where the agent can act without real-time policy checks or human review, accountability may be assigned on paper, but control is already lost in practice.

Related resources from NHI Mgmt Group

• Who is accountable when sensitive data leaks through consumer AI tools?
• Who is accountable when a malicious MCP tool exfiltrates data through an agent?
• Who is accountable when sensitive data is retained in a third-party AI tool?
• Who is accountable when a compromised AI gateway injects tool calls into agents?