Security Spans Multiple Layers
A person opening an application may look like a simple interaction, but underneath it sits a surprisingly large collection of decisions.
Who is the person? What device are they using? What is the condition of that device? Where are they connecting from? Which application are they trying to reach? What data can that application access? Which APIs, services and infrastructure support it? What other systems does it trust?
Now add machine identities, service accounts, APIs, containers and AI agents to the same environment. The identity making a request may no longer belong to a human at all, and the path between that identity and the information or action it is trying to reach may cross several different environments.
That is why I find it useful to look at security across several interconnected layers:
- Human — the people interacting with systems, the choices they make and the context surrounding those interactions.
- Identity — human identities, machine identities, service accounts, credentials and the permissions attached to them.
- Infrastructure — networks, endpoints, compute, storage, cloud platforms and the physical and virtual environments supporting them.
- Application & Software — applications, APIs, code, libraries, containers and the development processes that create and maintain them.
- Data — where information lives, how it moves, who can reach it and how its sensitivity changes over time.
- Intelligence — AI models, agents, prompts, automation and increasingly autonomous interactions with systems and information.
- Dependency — vendors, SaaS platforms, software suppliers, partners and the other external systems on which an organization relies.
None of these layers operates independently. A change in identity can alter access to data; a software vulnerability can create an infrastructure exposure; an AI agent can connect identity, applications and information in ways the original architecture may never have anticipated.
And once an interaction starts moving between the layers, another problem becomes visible.
The Blind Spots
Every security platform has a different view of what is happening. Identity systems understand authentication and access, endpoint platforms observe activity on devices, and the network provides visibility into connections and flows. Cloud and application platforms add context about workloads and transactions, while data platforms help us understand the information moving through those interactions. AI introduces another dimension through prompts, models and agents, while a third party may see only the portion of an interaction that passes through its environment.
Each produces a piece of the picture.
The difficulty appears when something moves across those views.
Imagine a user authenticates successfully from a managed laptop. The identity is valid and the device is compliant. That user then accesses an AI tool, which reaches another service through an API and retrieves information from a data source. Each action may look entirely reasonable within the platform observing it, while the sequence of actions tells a different story.
The same challenge becomes more complicated when an AI agent acts on someone's behalf. A valid identity may initiate the interaction, but what follows can move through applications, APIs, data stores and infrastructure without another human decision being made.
Seeing that journey requires context to travel across platforms with the interaction. Without it, the blind spot may sit between controls that are individually working exactly as designed.
Accelerated Response Is Expected
The environment itself is becoming more dynamic. A workload may change quickly, containers may exist only briefly, and cloud services can evolve without the kind of infrastructure lifecycle that once gave security teams more time to understand what had changed.
Vulnerability management makes the pressure particularly visible. Discovering a vulnerability is only the beginning of the work. Teams still have to determine where the affected technology exists, whether it is exposed, what depends on it, what could happen if it is changed, and how quickly remediation can safely occur.
As vulnerabilities are discovered more frequently, that cycle has to become faster. Asset and dependency information needs to be current enough to answer where an affected component exists, architecture needs to provide options for reducing exposure when an immediate fix is not possible, and automation can help shorten the path between discovery and action.
There will still be situations where patching immediately creates a different kind of risk because a critical application or business process depends on the affected technology. The ability to respond quickly therefore depends as much on understanding the environment as it does on the speed of the tools.
Vendors and Third Parties Are Part of the Security Strategy
Few enterprise systems exist entirely within the enterprise anymore. An application may depend on commercial software, open-source libraries, SaaS platforms, cloud infrastructure and APIs operated by several different organizations. Those providers have dependencies of their own, creating a chain that can extend far beyond what the enterprise directly manages.
That means decisions made elsewhere can change your security posture.
How a vendor develops software, manages identities, responds to vulnerabilities, protects its own supply chain and communicates during an incident all become relevant to the organizations relying on its services.
AI makes those relationships more interesting because the dependency may not always be obvious to the person using the application. Information submitted to one service may be processed by another model or platform behind it, while agents and tools can initiate additional interactions across systems.
Understanding where information goes, which services are involved, what is retained and who is responsible when something fails therefore becomes part of the architecture itself.
Valid Identity Is Important
Identity has become one of the strongest anchors in modern security architecture, and for good reason. Knowing who or what is requesting access is fundamental.
The challenge is that authentication tells us who successfully presented an identity; it does not necessarily tell us whether everything that follows should be trusted.
A legitimate employee can have compromised credentials, while a correctly authenticated service account may have accumulated more access than it needs. A machine identity can still be valid after the workload around it has changed, and an AI agent may operate with legitimate delegated permissions while taking an action the person did not anticipate.
The context surrounding an identity therefore becomes increasingly useful. What does this identity normally do? Which device or workload is involved? What information is being accessed? Has the pattern changed? Is an agent acting for a person, and does the requested action make sense given everything else happening around it?
A valid identity gives us an important point of reference. Understanding what that identity is doing requires seeing the layers around it.
The Technical Debt Around Data
Years of change leave their mark on an enterprise environment.
An acquisition may leave the organization operating systems built around a different architecture and security model. An older application may still be running because a business process depends on it, even though much of the surrounding technology has changed. A service account created for one purpose may gradually be used for several others, collecting access along the way, while an older protocol may remain because removing it would break something the business still needs.
Over time, these decisions begin to intersect. What made sense within one system or at one point in time can look very different once the surrounding environment has changed.
Data carries much of that history with it.
Information can be copied into applications, databases, analytics environments, collaboration platforms and cloud services over many years. The system where it originated may disappear while the information continues to exist elsewhere. Ownership can change, and the classification or controls surrounding the data may not always follow it as it moves.
AI changes what can be done with information that is already there. Data that was previously difficult to locate across multiple systems can become much easier to retrieve, correlate and summarize. The resulting exposure may come from information and permissions that have existed for years, but are now being used in a very different way.
That makes understanding the history and movement of data increasingly connected to identity, architecture and AI security.
When Something Still Gets Through
Even a well-designed security environment has to account for the possibility that something will eventually go wrong. Credentials can be compromised, a vulnerability may be exploited before remediation is complete, a configuration can be incorrect, or a dependency outside the organization can become the path into something inside it.
What happens next depends heavily on how quickly the organization can understand the sequence of events.
Can teams reconstruct the path an identity took across systems and determine what information it reached? Can they see which workloads, APIs and external services were involved? Can part of the environment be isolated without unnecessarily disrupting everything around it?
Those questions become much harder to answer when every platform tells its own version of the story and people have to assemble the sequence manually while an incident is still unfolding.
This is where observability, architecture and security operations begin to overlap. The value is not in generating more telemetry for its own sake; it is in connecting enough context to understand what happened and make a better decision about what to do next.
Finding the Levers
When security spans this many layers, adding another control can feel like the natural response to every new risk. Sometimes another control is exactly what is needed.
The multi-layer question is where an intentional change can reduce risk across several layers at once.
Reducing unnecessary privilege, for example, can change the consequences of a compromised identity across applications and data. Removing an obsolete dependency may eliminate several exposures rather than adding controls around each one. Better segmentation can limit how far an incident travels, while improving the way information moves between existing security platforms can reveal patterns that none of them could see independently.
The same thinking applies to AI and automation. They can help connect signals across platforms, recognize patterns that would be difficult to identify manually, accelerate investigation and shorten parts of the response cycle. Where they are most useful will depend on the problem we are trying to solve, the quality of the information available and the consequences of getting a decision wrong.
This is why I keep coming back to the layers. People, identities, infrastructure, software, data, intelligence and external dependencies are changing at different speeds while becoming increasingly connected to one another. Looking across those relationships gives us a better chance of seeing where an intentional change in one part of the system can reduce risk well beyond it.
The layers will keep moving.
Our ability to observe, understand and adapt with them may become one of the most important security capabilities we build.
