Google Workspace trust gap in Gmail and Drive malware delivery

At a glance

What this is: Pentera describes two integration logic flaws in Google Workspace that can let malicious files bypass Gmail and Drive safety signals and reach recipients as apparently trusted attachments.

Why it matters: It matters because collaboration platforms increasingly shape email, file, and access trust decisions, and IAM teams need to understand when native safety indicators are no longer reliable control points.

By the numbers:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.

👉 Read Pentera's analysis of Gmail and Drive trust flaws in malware delivery

Context

Gmail and Drive are trusted because they sit inside the same productivity ecosystem, but that shared trust can become a governance gap when one service inherits the other service’s assumptions. In this case, the primary issue is not a single malware sample but the way platform-to-platform integration can weaken file screening, warning prompts, and user judgment in Google Workspace.

For identity and access teams, the lesson is that trust signals are part of the control surface. A label such as “Scanned by Gmail” can influence human decisions, while the underlying delivery path may still bypass the checks a security team assumes are in place. That is a security governance problem, not just an email hygiene issue.

Key questions

Q: What breaks when collaboration platforms inherit trust too aggressively?

A: When one service assumes another has already performed the necessary checks, malicious content can move across internal trust boundaries with less scrutiny than an external file would receive. That breaks the security model because the user sees a trusted workflow, while the actual inspection path may be inconsistent. The result is a false sense of assurance and a broader delivery surface for malware.

Q: Why do trusted file-sharing links increase phishing and malware risk?

A: Trusted file-sharing links reduce suspicion because they look like normal business workflows rather than obvious external downloads. Attackers exploit that familiarity to improve click and open rates, especially when the link is embedded in an email that appears to come from a known platform. The risk rises when the recipient assumes the platform has already validated the file end to end.

Q: How can security teams tell whether native scanning is actually working?

A: Look for consistency across delivery paths, warning behaviour, and endpoint execution. A file should produce the same risk outcome whether it arrives as a direct attachment, a hosted link, or a shared collaboration object. If the verdict changes by path, or the warning only appears in one interface, the control is not providing reliable assurance.

Q: What should teams do when cloud collaboration warnings and labels do not align?

A: Treat the mismatch as a control failure and escalate it into policy. Quarantine or detonate the file outside the native platform, alert users that the visible label is not a guarantee of safety, and review whether your mail, storage, and endpoint controls are sharing the same inspection state. In the meantime, assume the message is untrusted until independently verified.

Technical breakdown

Why shared trust boundaries fail in Google Workspace

Google Workspace integrates Gmail and Drive through shared services, link embedding, and native attachment-like presentation. That architecture reduces friction, but it also creates an implicit trust boundary: once content is hosted in Drive, Gmail may treat it differently from an externally hosted file. When the file inspection logic is not consistent across services, a payload can be blocked in one context and accepted in another. The result is not a new exploit class so much as a mismatch between security policy and service orchestration.

Practical implication: validate whether internal sharing paths inherit the same scanning and quarantine rules as external delivery paths.

Why security labels can become misleading trust signals

Security labels only help when they accurately reflect the underlying verdict. Pentera’s finding shows a case where a file could appear with a “Scanned by Gmail” style assurance even though it had already triggered blocking in another path, or where warning interstitials did not appear as expected. That matters because users make rapid decisions based on the visible trust cue, not on the hidden security workflow. If the visible label and the actual file handling outcome diverge, the label becomes part of the attack surface.

Practical implication: treat trust labels as user-interface signals, not proof that content has been fully inspected.

Why browser and download controls need to sit above native scanning

The second flaw is operationally important because it shows that native platform scanning is not always enough to stop execution. If a file is delivered through an integrated attachment flow, the user can reach the payload before a platform-specific warning appears, or without a warning at all. That makes real-time sandboxing, browser isolation, and download interception essential compensating controls. The control objective is not just to detect malware, but to prevent immediate execution when the file’s provenance or inspection state is uncertain.

Practical implication: put sandboxing and download interception in front of user execution, not behind the native mail client.

Threat narrative

Attacker objective: The attacker’s objective is to deliver malicious content through a trusted productivity platform in a way that maximises user confidence and increases the chance of execution.

1. Entry occurs when an attacker places a malicious payload in a Google Drive share link that can be embedded into Gmail as if it were a normal attachment.
2. Credential or trust abuse follows when the recipient relies on the platform’s visible safety label and accepts content that inherited trust from the Drive container.
3. Impact occurs when the recipient downloads and executes the payload, giving the attacker a credible malware delivery path through a trusted collaboration service.

NHI Mgmt Group analysis

This is a platform trust problem, not just an email filtering problem. The article shows how a file can be rejected in one service path and accepted in another because the integration layer inherits trust too aggressively. That is a governance issue for cloud collaboration environments, where security decisions are often distributed across products that were not designed as a single assurance chain. Practitioners should treat trust inheritance between services as a control design flaw, not a usability feature.

Misleading safety labels create a verification trust gap. Visible indicators such as “Scanned by Gmail” can encourage users to downgrade their caution even when the file has not been inspected consistently across the delivery path. In identity and access terms, this is a trust assertion problem: the interface claims assurance that the underlying control path cannot always guarantee. Security teams should assume the label can influence behaviour even when the evidence behind it is incomplete.

Native collaboration controls are not a substitute for execution controls. If a malicious file reaches the endpoint before a warning appears, the control has already lost its most important decision point. This reinforces the need for layered inspection, sandboxing, and policy enforcement outside the mail and storage service itself. Teams should evaluate whether their detection and prevention controls act before download, before open, and before execution, not after the user has already acted.

Cloud collaboration security is increasingly about orchestration consistency. The same file path can be interpreted differently by Gmail, Drive, browser, and endpoint controls, which means policy drift can emerge inside a single vendor ecosystem. That is a reminder that integrated platforms still need explicit governance for provenance, inspection state, and download behaviour. Practitioners should align these controls across mail, storage, and endpoint layers rather than assuming the platform handles them uniformly.

Compensating controls now carry more weight than vendor trust claims. Until the underlying logic is fixed, defenders need to build their own assurance chain around untrusted content even when it arrives from a familiar service. That means validating file origin, enforcing content compliance rules, and detoning downloads in real time. The practical takeaway is simple: treat integrated trust as conditional, not absolute.

What this signals

Verification trust gap: this kind of integration flaw shows that a visible safety signal is only useful when the inspection path behind it is consistent across services. For teams running Google Workspace or similar collaboration stacks, the next step is to map where mail, storage, browser, and endpoint controls diverge, then close the gaps with policy that does not depend on user interpretation.

For identity and access programmes, the signal is broader than email security. Trust inheritance is a governance decision, and governance decisions need an owner, a review cycle, and a compensating control when the platform cannot prove equivalence across paths. The practical move is to treat cloud collaboration trust as part of the access control model, not as a separate usability layer.

For practitioners

• Reclassify internal share links as high-risk delivery paths Apply the same inspection and review logic to Google Drive links inside Gmail that you already apply to direct attachments and external download URLs. Add heightened handling for executable content, scriptable file types, and any message that relies on a visible trust label rather than independent verification.
• Enforce pre-execution download sandboxing Route downloads from cloud collaboration services through a sandbox or browser security layer before the user can open the file locally. The control goal is to block execution when platform-native scanning is incomplete, inconsistent, or invisible to the recipient.
• Add native content compliance rules for shared files Use mail security policy to flag, reroute, or quarantine external messages that contain Drive share links or similar trusted-storage references. Combine that with warnings that make the origin and inspection state explicit to the recipient.
• Test for trust-label bypass conditions Run red-team and validation exercises that compare how the same file behaves in direct email attachment flow, Drive-hosted flow, and endpoint download flow. Track any case where a trust label appears without consistent inspection outcome or warning behaviour.

Key takeaways

• The core problem is inconsistent trust inheritance across integrated cloud services, which can let malicious files appear safer than they are.
• Visible labels and native warnings are only reliable when they reflect the same inspection outcome across every delivery path.
• Security teams should add sandboxing, policy enforcement, and trust-label validation before execution, not after delivery.

Key terms

• Trust Inheritance: The condition where one credential or integration is allowed to carry trust into multiple connected systems. It is often invisible until a token is replayed from outside the intended context. In practice, trust inheritance is what turns a valid login event into a cross-platform compromise.
• Safety label: A safety label is the user-facing indicator that a platform attaches to content to signal scan status, abuse status, or download risk. Labels are helpful only when they accurately reflect the underlying control path, because users often act on the label rather than the technical verdict behind it.
• Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.

What's in the full report

Pentera's full blog post covers the proof-of-concept detail this post intentionally leaves for the source:

• Step-by-step reproduction of the Gmail and Drive attachment bypass paths.
• Screenshots and proof-of-concept behaviour for the misleading “Scanned by Gmail” label.
• The precise conditions under which Google Drive warning interstitials did not appear.
• Pentera's recommended mitigations for sandboxing and content compliance enforcement.

👉 The full Pentera post covers the proof-of-concept paths, warning behaviour, and mitigation examples.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners building stronger access and assurance models. It helps security leaders connect identity controls to the broader security programme without relying on platform trust alone.