One of the more interesting cybersecurity stories this week wasn’t interesting because an attacker got in. It was interesting because of what happened after they did.
ReliaQuest disclosed that an employee was targeted in a social engineering attack that temporarily exposed a single identity session. The attacker was able to see an identity dashboard, but the activity was detected and contained before they could access company applications, backend systems, or customer data.
That’s an important distinction.
For the longest time, cybersecurity operated around fairly static ideas of trust. If you were inside the corporate network, using a managed device, and authenticated with valid credentials, there was a reasonable assumption that you belonged there. We built networks, applications, and access controls around that assumption, but we know now that authentication isn’t the same thing as trust.
Credentials get stolen. Sessions get hijacked. Devices get compromised. Vendors get breached. People get fooled. This week’s headlines provide examples across nearly all of those categories.
That’s why I think the underlying idea behind Zero Trust remains so important. Zero Trust was never really about trusting nothing. Businesses can’t operate that way. It’s about recognizing that trust should be earned, limited, and continuously evaluated.
Authentication can establish identity, but it shouldn’t establish unlimited or permanent trust.
That distinction becomes even more important as identity increasingly becomes the control plane for modern technology. Our applications are distributed across cloud providers and SaaS platforms. Employees work from everywhere. Systems communicate through APIs. Workloads authenticate to other workloads. Access that once depended heavily on where something was located now depends much more on who or what is requesting access, what they’re allowed to do, and whether their behavior still makes sense.
We’re also approaching another interesting evolution in that model.
The identity requesting access won’t always represent a person sitting at a keyboard.
It may be an application, an automated process, or increasingly an AI agent acting on someone’s behalf. Those agents may read email, query databases, write code, create tickets, interact with business systems, and eventually communicate with other agents.
That creates some fascinating questions for Security teams.
Who authorized the agent? What should it be allowed to access? How long should that authorization exist? Can it delegate authority to something else? What happens when its behavior changes? And how quickly can we remove that access when something doesn’t look right?
Those may sound like new questions created by AI, but they’re really extensions of a problem we’ve been working on for years.
Trust.
The technologies will continue to change. The entities requesting access will change with them. The architecture underneath our Security programs needs to be capable of making increasingly dynamic decisions about both.
The goal isn’t to eliminate trust. It’s to become much better at deciding who and what deserves it, how much they should receive, and when that trust should end.
