When I first started building software, security meant exactly one thing to most teams: SSL, and only because you were touching a credit card. Beyond that, it barely came up. You added a simple question to a form — a basic math check, long before reCAPTCHA existed — to keep spammers from flooding your inbox. Eventually people started actually hashing passwords instead of storing them in plain text. That was close to the whole list. Security wasn't a discipline embedded in how you built things. It was a handful of specific, narrow problems you solved when something forced you to, and otherwise it barely came up in the conversation at all.
What we were actually defending against
The threat model back then was almost quaint by today's standards: a hacker poking at a known vulnerability, or a search engine crawler indexing whatever it could reach. Both were slow, both were largely predictable, and both mostly cared about one layer at a time — a login form, an exposed directory, a SQL injection point somebody found by hand. You could reason about your exposure because a person had to go looking for it, one system at a time, and there were only so many people looking.
What we're actually defending against now
That's not the threat model anymore. We don't have hackers and crawlers anymore — we have agents, mining everything, checking every layer, correlating what they find across systems that were never designed to be looked at together. An agent doesn't get bored three directories in. It doesn't need to already know your schema to start asking useful questions about it. It strengthens every legitimate use case we actually want — and the exact same capability, aimed with bad intent, finds every hole in every layer faster and more thoroughly than any human ever did. That's not a hypothetical future risk. It's the same technology already sitting on most desks right now, just pointed in a different direction.
We used to defend against someone looking for a way in. Now we have to defend against something that can look everywhere at once.
The mindset has to reverse, and that's genuinely uncomfortable
Every instinct I've built over almost thirty years says innovation first, then worry about the edges once something real is on the line. Ship the feature, prove the value, come back and harden it if a client or a compliance requirement demands it. That instinct is now backwards, and I don't think most teams have actually caught up to that yet. Security and governance have to come first — before the next integration, before the next agent gets access to another system — because the gap that used to sit quietly for years until a person happened to stumble onto it now gets found immediately. Putting innovation first was a reasonable bet when the downside was slow. It's a bad bet when the downside can move as fast as the thing you're excited about.
What this actually looks like in practice
This isn't abstract. It's the same category of mistake I've watched happen for years, just with a much higher cost now: data quietly downloaded to a personal drive to make a report easier to build. A full export pulled out of a system into a spreadsheet that then lives forever in someone's inbox. A shared network drive with permissions nobody's audited since it was set up. An integration granted far more access than the one task it actually needs. None of that was ever a good idea. It's just that the blast radius used to be "one analyst has a stray file," and now it's "an agent with broad access can find that file, understand what's in it, and act on it," whether the agent doing the finding is yours or someone else's.
What I'd actually tell someone building with agents today
Treat every new integration, every new data access grant, every new agent capability as a security decision first and a productivity decision second — not because AI is dangerous in some abstract sense, but because it's genuinely good at exactly the kind of systematic discovery that used to be your best protection against casual exposure. Scope access tightly. Know exactly what data can leave a controlled environment and shut down the paths where it can leave casually. Audit what your integrations can actually touch, not just what they were built to touch. This isn't about slowing down. It's about making sure the fundamentals — the same unglamorous discipline that's been the throughline of everything else I've written about here — are actually in place before you hand more capability to something that will use it exactly as thoroughly as it's able to.