Technology Waves and Security - Is This Time Really Different?

Most people have been through at least one wave of technology transformation. Some of us have been through a few and all carry the wisdom and scars from these. When you’ve experienced these changes you learn to appreciate, as the adage goes, that history might not repeat but it certainly does rhyme. 

In my working lifetime I caught the tail end of the mainframe to PC transition, the proliferation of client/server and distributed system architectures, wide-spread Internet adoption, mobile technologies, and the migration to cloud or cloud-like on premise technologies. Now, we have the massive take-up of AI. 

I won’t spend time in this post talking about the relative impact of each of these technology waves. But what remains constant is that we always over estimate the short term impact of these changes while also underestimating their long term impact. On this latter point we also, perhaps inevitably, fail to see the potential second order effects and risks that come after the first wave of change. I talk more about this, for AI, here. 

In my experience there are at least three constants in every wave of change:

1. Security is never built in enough.

2. Security comes when design patterns, not just technology, crystallize.

3. Investment priorities are initially unclear but signals can be seen. 

Let’s look at each.

1.Security is Never Built in Enough

This doesn’t just apply to security. Scaling, reliability, resilience and many other properties don’t come until an initial wave of innovation and market take up has happened. There are some exceptions to this, and even when security isn’t baked-in fully there are sometimes sufficient "stubs" to build on so that the end architecture isn’t fatally flawed. 

Many prior waves of transformation have failed to build in sufficient security from the outset and we’ve lived the consequences of that. Often these consequences led to risk that was not sufficiently mitigated with papered-on compensating controls. Others required a wholesale layering of a security architecture on top of the initial design. For example, the mainframe to PC phase transitioned us from a reasonably secure environment to the early versions of Windows with, essentially, no security. When this was coupled with a TCP/IP stack, to paraphrase Dan Geer, every sociopath became your next door neighbor. 

We didn’t do much better with the Internet overall. Much has been written about the security design flaws of the base Internet protocols. I’m generally more sympathetic to this. I was around in the early days of widespread commercial propagation of TCP/IP, on the Internet and internal networks. These went head to head with the nascent OSI stack of protocols and some others. The former assumed security would be layered on it, the latter had it built in to a greater extent albeit in a massively clunky and bureaucratic way. We all know which won, decisively. People can debate that it wasn’t the security that slowed OSI adoption and I think they’d be right. But, it’s also pretty obvious that the ease of TCP/IP adoption, and the promulgation of the Internet was driven by the portability, interoperability, scaling and many other properties that even the best concept of security at the time would have inevitably impeded. 

We fared better on mobile, especially in the smart phone era due to the admirable efforts of Apple and Google. Again, not perfect, but actually not bad. Similarly, cloud (or at least some clouds) also came with a better substrate of security than existed in many enterprises, like encryption, partitioning, and more frequent updates. But, we still had to learn the need for the so-called shared responsibility model to stop customers doing things like leaving storage buckets wide open and unencrypted by default. There was then a transition to not only secure by design but secure by default, encapsulated by the "shared fate" model we championed when I was at Google which shipped more products with full safeties on. This recognized that most customers are happy to take a high default level of security when engineered well enough to not break other things significantly. 

With AI we’re not in a whole new ball game. Instead, it’s more like 5 new ball games all played at once on the same field with 10 different teams. We have all the same challenges but it’s being played out in consumer and business, at the edge and the core, in the software lifecycle and the business process, and more. We have even more fundamental challenges in the technology itself given our continued need to strap deterministic guards on fundamentally non-deterministic technology, to give just one example. 

But the good news is, as with prior waves of technology we are collectively responding by building in the security needed. This is into the technology, the protocols, the standards, all of which are augmented by constant innovation in the labs, the CSPs and neoclouds, and a vibrant eco-system of start-ups competing over ideas and implementation. This is even more so than prior waves of technology transformation, that in each of those cases needed their own development of standards and technology, and whole waves of start-ups to come, fade away or sustain with the security we now have built in (more or less). 

2.Security Comes When Design Patterns Crystalize 

Now we could say, perhaps fairly, that we should all just do better and build security in from the beginning of everything. But, even if we ignore the innovation pattern to release early and then tighten things up, it’s often the case that we can’t even conceive of the right security designs when things are too early. 

Yes, security absolutely should be to be built in at the foundational platform and component level. But, the hardest security challenges live in the seams between interconnected systems and components. It also lives and dies in the seams between technology, business processes, people, other organizations upstream and downstream in supply chains. 

The problem when technology is early, or when we’re early in a wave of disruption, is that the design patterns are not locked in. In most waves of technology change it’s worse than not locked in, rather it’s total chaos and we collectively experiment with how different components are arranged, how they work together, and which element does what function.

Above all, it is unclear which aspect of security exists at a component level, a systems level, a protocol level and beyond. Then, for the system level, which element contributes what security property to other elements or for the system as a whole. 

Let’s look at the Internet for example. In the early days of the commercial adoption of the Internet (late 1990’s to 2000’s) we had browsers, web servers, firewalls, intrusion detection systems, proxies, load balancers, NAT gateways, routers, servers, and so on. Each had some security built in, often not enough, and people worked hard to improve on that. But, more broadly, it took a while for the common design patterns to emerge of how all these components should be arranged to deliver what was needed for business outcomes in reliable and secure ways. For example, we got the design pattern of the DMZ where tiers of segmented networks intermediated internal networks and services from the Internet. Each layer housed firewall and/or proxy shielded layers of functionality. At each concentration point security properties were built in like identity, access control, encryption, traffic filtering, intrusion detection, and so on. It wasn’t until that design pattern crystallized that we were able to lock in the right security elements in the right place and have them work together to deliver an overall systems level concept of security. 

We saw similar crystallization of design patterns for VPN/remote access, remote monitoring, branch networking, edge networking, resiliency and load balancing, API access and more. Then when business e-commerce patterns themselves crystallized we solved (more or less) for end to end encryption, end point security, identity and access management, and transaction protection. It wasn’t until the systems (technology and business) patterns crystallized that we could fully lock in the security design, despite earlier great work at the component level. Along the way there were failed approaches that either died or morphed or merged into another concept. 

We see the same thing now in AI. Design patterns for agent integration and interaction, where data, memory and context is managed, and a myriad of other decisions are up for grabs. Every week brings a host of new design patterns, of shifts where intelligence is, along with different ideas of where the locus of control should be. We are far from seeing a stable set of patterns emerge.

So, it’s unsurprising that many are frustrated about the state of things. The frustration is great and needed, because that is what drives the improvement. It was the same in each prior wave of transformation from Internet, mobile to cloud. There’s no reason things should be different now. We’re just observing it even more clearly because of the scale and pace of change. 

3. The Investment Priorities are Less Clear - But Emerging 

So what to do? Where should security teams invest now? Where should security teams wait? Where should technology firms and start-ups focus? 

All good questions. Of course, no-one has the precise answers, such is the nature of things. But we can pick some constants or invariants out of the noise. Such invariants are things we need now that even when different design patterns crystallize we’ll still need them, even if the approach needs to adjust to accommodate that. 

These are at least:

• Agentic identity. Agents need an identity. The concept of that identity is likely to change depending on whether an agent is a delegated servant of a person, a long-lived agent running a business workflow, or a task-executing agent spun up to do something for another agent and then spun down. All of this shapes whether identity is long-lived or ephemeral, and if ephemeral then it begs the question of who sustains the time series record of what identity existed at what time and did what. Again, the types of agents we will have and how they are usefully arranged in what design patterns will dictate the right security patterns to build into and overlay on that. 

• Agentic security, access, and sandbox posture. Agents need to be configured appropriately, be controlled in what they are permitted to do, and exist in the right sandboxes themselves configured appropriately, with underlying software, data, context, memory and other elements managed for integrity. 

• Testing and validation. Everything in an agent pipeline or other AI-embedded system needs testing and validation. Not just regular software validation but a wider form of testing and validation to monitor for and correct for things like model drift. 

• Enterprise agentic control planes. Opinions may differ on this one, but I don’t believe we can secure agents in the enterprise as a function of only controlling what the agents can do. No matter what deterministic or layered probabilistic guards one needs in and around the agent you also need to couple that with corresponding access controls enforced at the resource level (be it CLI, API, MCP gateway, or other future pattern). Your agentic control plane is then a means of taking a business policy (for example, no person or agent should be able to send out more than a $1M payment without another independent agent and human approving that) and then applying that to agents and the resources they interact with. To do otherwise would be like, in human terms, removing all access controls and just hoping to train the humans to never try and do something against policy. By the way, this example is not me saying all agent actions need human-in-the-loop approvals, they clearly can’t and won’t because of scale and speed. Although in this particular example I would say they do. More generally a human-on-the-loop model is more appropriate. This is where humans with appropriate tools and data supervise multi-agent approval flows. More on this in a future post.  

• Immutable observability and transactional auditing. We will need to know which agent did what, when, how and why under what instruction, be it from a human or another agent or system trigger. In other words, to capture an audit trail of the creation of an agent, what it was asked to do, the context it was given, its chain of thought in determining actions to take, what it tried to do, if it was blocked and what it then did, what it ultimately did, and how it affected the resources it accessed. All of this can then be captured in a time series immutable log (e.g. append-only log or blockchain) that can be replayed as needed when required by law, regulation or incident to show what really happened. 

There will be more invariants as our design patterns crystalize. 

Bottom line: every wave of technology change feels frustrating because security is never built in enough. The pace of innovation and experimentation make this almost inevitable despite our best intent. Even when we have the foresight to get component security features designed-in we mostly can’t yet see what we need at the systems level. Security success and failure lives in the seams between things. At the early stage of technology change we haven’t yet crystalized the common set of design patterns to then layer in the right concept of system-wide security. We experienced the same issue during the Internet, mobile and cloud transformations. We didn’t get better security until we’d locked in on a range of design patterns that we could build toward. We’re in one of those moments now with AI. Normally at this point I use the adage, "we’re careering into the future at the speed of light, relax and enjoy the ride". But perhaps, as before, us security people are the ones who need to feel indignant and positively not relaxed. In doing so we will get the security we need. We did a lot of this before and we’ll do it again. History might not repeat but it definitely rhymes.