By Brian Holyfield, Co-Founder & Chief Product Officer — SendSafely
At least 18,033 terabytes of company information passed through apps powered by artificial intelligence just last year. That’s 93% more information than the year before, and the amount is rising. The troubling fact is that approximately 39.7% of AI interactions in those apps make sensitive data vulnerable.
Today’s automated systems are wired directly into your business. They touch ticketing queues, the CRM, internal knowledge base, and the workflow automations in between. And they’re being given access to highly sensitive data.
To make automation work, companies need a boundary between sensitive customer data and their growing ecosystems of AI applications and agents. With that boundary in place, AI can still drive workflows without gaining direct visibility into the sensitive data inside.
The unique vulnerability of automated systems to data exposure
Automation needs access, but every integration is a new doorway. Automated systems tend to collect more data than they need, because it’s easier to bring everything in than to sort first. A lot of data gets swept into workflows where it doesn’t belong.
One study shows that 78% of employees say they now use intelligent agents and tools, but more than half (58%) admit to pasting sensitive client or company information into those models. Another 45% have used “banned AI tools on the job,” and another 40% admitted that they don’t always follow data security procedures if it meant completing a task more quickly.
Additionally, many teams aren’t clear on what information is being sent where, who can access it, or how long it is stored. Most assume someone else has read the fine print. Often nobody has, and the fine print is not reassuring. Salesforce improves Einstein and Agentforce from the activity flowing across its platform. Atlassian and Slack both drew scrutiny for defaulting customers into AI training programs unless someone actively opted out. The question is not only whether a vendor can protect your data, but whether it wants access at all, and what it is permitted to do once it has it.
What’s more, these tools are persuadable. Automated systems interpret instructions. If a system can take actions such as sending emails or creating tickets, it can be tricked into doing those actions in unsafe ways.
Exploring the risk of cyberattacks and leaks with automated systems
Making AI helpful means plugging it into tools like Zendesk, Salesforce, ServiceNow, Slack, Intercom, internal APIs, and file stores. In that setup, the AI isn’t generating text; it’s summarizing accounts, pulling history, attaching documents, routing cases, and making decisions based on what it can see.
Scale magnifies the consequence. A human mistake might affect one customer or one spreadsheet. An automated system’s mistake can affect thousands of customers or an organization’s entire knowledge base.
The first risk is the fragility of the API pipeline. Modern software gets built incredibly fast. It’s great for speed, but it’s not always hardened like core systems. When an application in that pipeline is compromised, the fallout expands to everything the app can access.
More risk is introduced when AI agents become over-permissioned. To make agents useful, organizations grant broad access across systems such as the help desk, the CRM, and file repositories. If an agent is compromised, you’ve built a ready-made lateral movement route through your stack.
The third risk is retention. Many AI platforms log and keep data, sometimes as a default that shifts over time. Even when vendors offer opt-outs, the burden is on you to notice policy changes, configure the control correctly, and monitor it across a growing list of integrations.
How to protect automated systems against data exposure
The response can’t be panic or prohibition. Assume that automated systems are here to stay and build a trust layer to meet them.
You can’t audit every vendor flawlessly, predict every vulnerability, or control how AI platforms will evolve over the next two years. What you can control is what these systems are allowed to see.
Instead of handing the keys to every integrated tool, you design the workflow so that only what must be shared is shared, and only with those authorized to see it.
A trust layer encrypts sensitive data before it ever reaches the application layer. It allows agents to trigger workflows without exposing sensitive customer data by default. Since the data never reaches the model layer in readable form, it never enters model logs or training pipelines.
This is also the only version of vendor trust that survives contact with a changing privacy policy. You can only trust a vendor that actively does not want access to your data and can prove cryptographically that it does not have it. Everyone else is either training on your data or will be soon.
A trust layer only works if it’s the easiest path for real customers and real support teams. The model needs to blend into the places where work happens. Done properly, sensitive data is protected before it leaves the customer’s device, and remains encrypted end-to-end.
AI moves fast, and it often demands more access than it deserves. The danger creeps in when automation is added everywhere and nobody wants to be the person slowing it down.
A dedicated trust layer allows you to adopt AI aggressively without turning customer data into collateral damage. You scale automation while keeping a clear and enforceable boundary.
— Brian Holyfield is the Co-Founder and Chief Product Officer of SendSafely. He and his fellow co-founders each have more than 25 years of experience in the cybersecurity industry. Brian is one of the original architects behind SendSafely’s end-to-end encryption platform. Before SendSafely, he co-founded Gotham Digital Science (GDS), a boutique cybersecurity firm specializing in Red Team penetration testing and application security for Fortune 100 and FTSE 100 clients, which was acquired by Stroz Friedberg (Aon) Before SendSafely, he co-founded Gotham DigitalScience (GDS), an elite cybersecurity consulting firm serving Fortune 100 and FTSE 100 clients, which was acquired by Stroz Friedberg (Aon). Prior to founding GDS, he was a Manager at Ernst & Young’s Advanced Security Center. Brian holds a Master’s in Information Systems Auditing and a Bachelor’s from the University of Florida. He is a published security author with speaking engagements at BlackHat, RSA, and other premier conferences.
