Your Vendors Are Your Perimeter

Lesson summary

A lawsuit filed against EY describes an attacker who got in through a third-party help desk platform used by its tax practice, not through EY’s own systems, and stayed for 26 days with access to tickets and confidential client documents. This lesson uses that case to explain trusted-party attacks and why AI is making them more important.

The pattern isn’t new. The lesson connects it to Target’s breach through a refrigeration vendor’s login credentials and to Okta’s customer support breach. In each case, the attacker used the access an organization had granted to someone it trusted. Every vendor, contractor and support tool with access to your data widens your attack surface, and a breach at a vendor can become a client liability question, as it has for EY.

AI turns up the volume. Integrations are one of AI’s biggest benefits, but connecting an assistant to email, a CRM or Microsoft 365 often requires broad access. The lesson shares two real examples: an assistant nudging a user toward full mailbox access just to send event invitations, and a CRM connection that required super-admin rights before permissions could be narrowed. Easy integration doesn’t make broad access the right decision.

The lesson then lays out a practical response. Map your “trust graph”: every vendor, contractor and tool that touches client data, what kind of data it is, and what AI capabilities each tool has out of the box. It also covers data minimization in both directions, which is often the hardest idea to get across to non-technical colleagues.

Key takeaways

• Inventory who has access to client data, including vendors’ own contractors.
• Ask vendors to document how they manage and monitor access.
• Know where raw sensitive attachments land internally, and who can touch them.
• Apply the same least-privilege standard internally that you demand from vendors.
• Treat AI connectors like contractors: give them only the access a task needs, and narrow it per task where you can.