We've Been Building This Wrong
Last week I was architecting a workflow integration for a client—nothing exotic, just connecting Slack to their CRM through Zapier. Standard stuff. But halfway through, I realized something that made me uncomfortable: I was creating a direct pipeline from their messaging layer straight into their database, and I'd barely thought about what happens if that pipe gets compromised.
The breach narratives we read about usually frame this as a people problem. Someone clicks the wrong link. But that's incomplete, I think. Or maybe I'm rationalizing because I spend my time removing people from processes, automating away the human element. I'm not sure which.
What actually keeps me up now is this: every workflow we build is a potential attack surface we're adding to the system. Each integration, each API connection, each automated trigger—these aren't just efficiency gains. They're doorways.
The Real Problem With "One Click"
- A compromised service account can execute thousands of actions before anyone notices
- By the time your monitoring alerts fire, the workflow has already propagated across three different systems spreading laterally through your infrastructure like a compromised employee would, except faster and without needing to sleep or ask permission
- Detection
In March 2023, the MOVEit vulnerability showed us exactly this. Organizations had automated their file transfers so completely that when the vulnerability was exploited, attackers didn't need to break in multiple times. One infection point became total access. One automated workflow became the weapon.
The irony—and I genuinely don't know if I'm overthinking this or not—is that the more we automate, the more we reduce human friction, the more we create these perfect pathways for an attack to move unmolested through a system. We're not eliminating risk. We're paving it a highway.
What I'm Actually Doing About It
I've started implementing what I call "friction points" in every workflow I build. Not enough to destroy the efficiency. But enough to make lateral movement harder.
- Service accounts with minimal permissions—not just in theory but actually enforced through code
- Time-window restrictions on sensitive operations. If your payroll automation suddenly tries to run at 3 AM on Tuesday, something is wrong, and the system should know that
- Audit logs that aren't just logs but actually get read by something. An alert service, a human, something other than empty storage.
- Honestly though I'm not convinced most organizations have the engineering bandwidth to maintain this properly, which means it becomes security theater
I'm also pushing back harder on scope creep in integrations. A client will ask me to connect their email system to their project management tool to their CRM to their accounting software, and I used to just build it. Now I stop and ask: why do these things need to talk to each other? Is the efficiency worth expanding the attack surface?
Sometimes the answer is yes. Sometimes it's no. But we were pretending the question didn't exist.
The Part I Don't Have Figured Out
Here's what troubles me: I don't think the solution is to stop automating. That's not realistic and honestly it would be terrible for the businesses I work with. But I also can't shake the feeling that every workflow I build is a bet—a bet that our monitoring is good enough, that our access controls are tight enough, that nothing will slip through the cracks.
And the honest answer is some of them will. Some attack will find a gap I didn't think to close because I was focused on making something work fast, not making it impossible to weaponize. An employee will still click the wrong link. A contractor will still use a weak password. A service account will still get rotated wrong.
The difference is now it travels faster. Now it travels automatically.
So what? Do I stop building integrations? Do I add so much friction that automation becomes pointless? Do I just accept this as the cost of modern business?
I genuinely don't have a clean answer, which is probably why I'm writing this instead of sleeping.
