Some of the hardest security failures do not look like failures when they happen.
The access is technically allowed. The identity is known. The API call is valid. The application is approved. The data movement may even pass through the right systems. If you inspect each step in isolation, nothing looks obviously broken.
The problem shows up only when you ask a harder question.
Was this access appropriate?
That is the question modern security has to answer. Not just whether something was allowed. Not just whether a policy existed. Not just whether the data was sensitive. But whether a specific identity, workload, or agent should be doing a specific action, to specific data, through a specific path, at that specific moment.
That question cannot be answered by one control point. It needs context.
My view is that security is becoming a context problem.
Not because “context” is the latest AI word, but because the systems we are trying to secure are becoming too dynamic for static controls alone. Identity, data, permissions, runtime behavior, actual usage, application chains, third-party movement, and agent activity all have to come together before a security system can make a good decision.
Without that, we are mostly staring at fragments.
The harder problem is not access. It is appropriate use.
My bias comes from my time at Meta.
At that scale, securing data was never only about finding where data lived. Of course that mattered. You needed to know what data existed, where it was stored, how it was classified, and which systems could access it.
But the harder problem was understanding the chain.
Who or what caused the data to be accessed? Which service touched it? Which application path triggered it? Was there an original user behind the action? Did the downstream service preserve enough context to explain why the access happened? Did the usage match the policy, product intent, and user expectation?
That is a very different problem from simply saying, “this system has access to this data.”
The lesson from Cambridge Analytica was similar. The interesting part was not that there were no systems or no permissions. The deeper lesson was that technically legitimate access can still be misused. Access can be allowed and still violate trust.
That distinction matters.
A permission system can tell you whether an identity is allowed to access something. A data inventory can tell you whether sensitive data exists. A gateway can tell you whether a request passed through a control point.
But none of those, by itself, tells you whether the access was appropriate.
For that, you need the surrounding context.
Context mattered before it became an AI word
Today, everyone talks about context because of LLMs.
Context windows. Context engineering. Agent memory. Retrieval. Tool context. The language is new, but the underlying idea is not. Any large-scale decision system has always depended on the quality of context it receives.
I saw this closely in Ads and good old ML.
A model is only as good as the signals you give it. If the input variables are weak, the output is weak. If you lose signal, performance drops. If you want better decisions, you do not just keep tuning the same model and hope for magic. You rebuild the signal layer. You improve measurement. You find better features. You understand which data actually helps the system reason.
That is what happened after Apple’s privacy changes. Meta lost access to signals that had historically helped with attribution and optimization. The easy outside narrative was that this would permanently weaken the ads business. Internally, the problem was treated differently: if signal is lost, rebuild signal. Meta ads did not become irrelevant because the core signal source got weaker. The system adapted because the company understood that better decisions come from better context.
Security is going through a similar shift.
For years, we have treated many security problems as control problems. Who has access? What data exists? Which policy fired? Which permission is risky? Which request was blocked?
Those questions matter, but they are individual signals. A security system has to reason across them.
- Knowing that a database contains sensitive data is a signal.
- Knowing that a service account can access it is a signal.
- Knowing that a workload queried it yesterday is a signal.
- Knowing that the original request came from a specific user, through a specific application, for a specific workflow, is another signal.
- Knowing that the data then moved to a third party is another signal.
The decision only becomes meaningful when these signals come together.
This is why I do not think “context” is just an AI buzzword. It is the foundation of any system that has to make good decisions under uncertainty. In ML, better context improves predictions. In ads, better context improves optimization. In security, better context improves risk decisions.
A security agent with weak context will behave like a noisy rule engine. It will over-alert, under-block, miss the chain, and treat every signal in isolation. A security agent with rich context can understand whether an action is normal, risky, expected, malicious, or worth escalating.
That is the real shift.
The future of security is not just better dashboards or more posture findings. It is better context for better decisions. This becomes even more important as security teams start using AI agents to triage, explain, and act on risk, because an agent with poor context is just another noisy decision system.
The ‘X’SPM are context layers, not the whole decision
This is how I think about Static Security Postures.
Both are foundational. DSPM gives you data context: what sensitive data exists, where it lives, how exposed it is. ISPM gives you identity and permission context: which users, service accounts, roles, and non-human identities can access systems, and where access is excessive or stale. Without either, teams are flying blind.
But neither answers whether behavior is appropriate.
A service account having access is one signal. A database containing sensitive data is another. That same service account suddenly querying a new sensitive table through an automated workflow and sending results to an external system is a very different risk. No single layer sees that.
DSPM tells you what data exists && who or what can access it. Runtime tells you what actually happened. Egress tells you where the data moved. Identity propagation tells you who originally caused the action.
The security decision needs all of it. The end goal is not a prettier inventory. It is better decisioning.
Agents make the context problem urgent
Agents make this problem harder because they change both the speed and shape of access.
A human user may click through an application slowly. An agent can call a tool, hit an API, query a database, summarize results, trigger another workflow, and send data elsewhere in seconds.
The actor may not be a person directly touching a system. It may be an agent acting on behalf of a human. Or a service account. Or an MCP server. Or a workflow automation. Or another NHI several hops downstream.
That breaks many of our old assumptions.
Useful agents will often need broad permissions. Nobody wants an agent that needs a ticket for every action. If agents are going to automate real work, they will need access to tools, APIs, databases, SaaS applications, and internal systems.
But broad permissions create a simple problem: “was this allowed?” becomes the wrong question.
A better question is “was this appropriate?” :
- Was this agent expected to access this data?
- Was it acting on behalf of the right user or workflow?
- Was the tool call normal?
- Was the database query expected?
- Was the destination trusted?
- Did the data movement match the business purpose?
- Was this behavior consistent with historical usage?
- Could this be a compromised agent, a prompt injection, a misused service account, or an automation doing something outside its intended scope?
These questions cannot be answered with static posture alone.
They need runtime context. They need identity context. They need data context. They need agent and tool context. They need egress context. Most importantly, they need the chain.
The chain is where a lot of the truth lives.
A user asks an agent to do something. The agent calls a tool. The tool invokes a service. The service queries a database. The result goes back to the agent. The agent sends something to another system.
Picture it concretely. A support agent pulls a customer record to resolve a ticket. The database sees a service account it has seen a thousand times before. The API sees a valid workload. The gateway sees an approved request. Every hop checks out. Nobody sees that the ticket was closed yesterday, or that the record left in a summary to an external system an hour later.
If each system only sees its own local hop, nobody understands the full action. Who actually caused the access? What was the business context? Was the agent acting within its intended scope? Did the downstream data access make sense?
Without original accessor context, the system loses the plot.
Some of this will be solved at the identity layer. For example, passing human context into agentic workflows is an important first step. Some of it will be solved through runtime observability. Some may require better standards, instrumentation, or organizational policy changes.
But the direction is clear. Security systems will need more context, not less.
Gateways are enforcement points, not the brain
Gateways will matter. They are useful and necessary.
A gateway can block, allow, redact, throttle, approve, log, or kill a flow. Every security architecture needs enforcement points. Static policies can stop obvious misuse: block known bad domains, prevent secrets from leaving, restrict certain tools.
That helps.
But dynamic agents will not always fail in obvious ways. They may use approved tools, valid identities, allowed APIs, systems they are technically permitted to access. The risk comes from the combination: the user, the agent, the tool, the data, the destination, the timing, the deviation from normal.
The brain is not the gateway. The brain is the context graph that tells the gateway what decision to make.
Enforcement without context becomes blunt. Context without enforcement becomes passive. Agent security is not just about putting a gate in front of the agent. It is about understanding what the agent is doing, why, whose authority it is using, and where the data is going. Only then can the gate make a useful decision.
The shift from posture to decisioning
I do not think the future belongs to one acronym.
Not DSPM alone. Not ISPM alone. Not DLP alone. Not gateways alone.
The shift is from static control points to context-driven security decisions.
Security teams need to understand not just what exists, but what is happening.
- Not just who can access, but who actually did.
- Not just whether data is sensitive, but whether its usage is appropriate.
- Not just whether an agent is allowed, but whether its behavior should be trusted.
- Not just whether a gateway has a policy, but whether the policy has enough context to make the right call.
This is the problem worth solving.
As more work moves to agents and non-human identities, the volume and speed of actions will increase. Attacks will also happen at machine speed. The blast radius of a bad decision will grow. Static reviews, periodic scans, and isolated alerts will not be enough.
The security layer that matters will be the one that can connect the dots quickly enough to make a decision.
The security architectures that work will not be the ones that only know where data is, or only know who has access, or only sit at a gateway. They will be the ones that help security teams answer the question that actually matters:
Is this identity, workload, or agent supposed to be doing this, to this data, through this path, right now? Answering it takes data context. Identity context. Runtime context. Agent context. Egress context. Original accessor context. Historical behavior. Business intent. No single signal gets you there. The question only becomes answerable when the fragments come together.
