AI-Speed Risk Requires Identity-Defined Reachability

Why Zero Trust Steps 3, 4, and 5 must evolve beyond patching, topology, and ticket-driven connectivity

 

Executive Summary

AI is compressing the time between vulnerability discovery, exploitation, and impact. Patching, secure engineering, and vulnerability management remain essential, but “find and fix faster” is no longer enough. CISA’s risk-based remediation model reinforces the architectural point that exposure changes urgency. If a vulnerable service is broadly reachable, defenders may have only days to remediate and investigate. If unnecessary reachability has already been removed, organisations gain safer operating room to prioritise, test, and patch without leaving services exposed to everyone.

Zero Trust therefore needs to evolve beyond topology, tickets, and perimeter thinking. Steps 3, 4, and 5 should reduce reachability before connection; write policy around strong identities, not merely reusable credentials, as well as services, actions, context, and blast radius; and continuously validate whether policy decisions remain bound to real sessions and flows. The practical goal is to make the secure path the simplest path. Public-by-design services must be hardened and patched quickly; private or unnecessarily exposed services should become unreachable unless identity, policy, posture, service intent, and context allow access. That is identity-defined reachability.

AI is changing the economics of cyber risk.

The 2026 Verizon Data Breach Investigations Report shows exploitation of vulnerabilities as the leading initial access vector in breaches, accounting for 31% of the dataset. At the same time, public time-to-exploit data shows the defensive window collapsing. Vulnerabilities that once took months or years to be exploited are now being weaponized in days, hours, or even before disclosure - see Zero Day Clock for the latest metrics.

That changes the assumptions behind Zero Trust implementation.

For years, security teams have lived with the uncomfortable but familiar fact that attackers often discover and exploit faster than defenders can patch. What is different now is the scale and speed of that imbalance. AI-assisted vulnerability discovery, exploit generation, code analysis, and autonomous testing are compressing the time between exposure and impact. Jim Reavis (CSA CEO) has described this as a growing patch-debt crisis: Discovery is moving toward machine speed, while remediation still depends on human-speed triage, patch development, testing, coordination, and deployment.

Recent reporting around Anthropic’s Mythos and Project Glasswing points in the same direction. In a controlled government security evaluation, officials reportedly said the model rapidly identified weaknesses across highly sensitive U.S. government systems. The important point is not the headline claim that “AI hacked the NSA”; public reporting is more nuanced, and rapid vulnerability discovery is not always the same as exploitation. The lesson is that AI is compressing the time available for defenders to find, assess, patch, and safely change exposed systems.

This does not mean patching is obsolete. Patching remains essential. Secure engineering remains essential. Vulnerability management remains essential. For public-by-design services, organisations should absolutely use AI to find and fix more defects, harden exposed infrastructure, shield public applications where appropriate, and accelerate remediation.

But in the era of AI-speed risk, “find and fix faster” cannot be the only answer.

CISA’s Binding Operational Directive 26-04 reinforces the same architectural lesson. Its risk-based remediation model treats public exposure as one of the key variables that determines patching urgency. That matters because exposure is not fixed. If a vulnerable service is publicly reachable, automatable, actively exploited, and high impact, defenders may have only days to remediate and investigate. But if that same service is not broadly exposed, and access is limited to the specific users, workloads, partners, or systems that genuinely need it, the risk profile changes. The obligation to patch remains, but the organisation gains safer operating room to test, prioritise, and remediate without leaving the service unnecessarily reachable.

So, the harder architectural question is: What if the next exploitable service is already in your environment, but it does not need to be reachable by most users, workloads, agents, tools, or networks in the first place?

That question sits at the heart of Zero Trust. It also changes how we should think about Steps 3, 4, and 5 of Zero Trust implementation.

Steps 1 and 2 help us understand what is important. We must define the protect surface and map the transaction flows. But Steps 3, 4, and 5 determine whether Zero Trust can survive real operational pressure. These steps decide how the architecture is built, how policy is expressed, and whether the environment is continuously validated as systems, threats, identities, agents, applications, and dependencies change.

If those steps do not address AI-speed risk, our guidance risks being obsolete on arrival.

 

Not every application needs the same answer

Before talking about architecture, we should acknowledge the reality that not every application should be treated the same.

Some applications are public by design. Public websites, customer-facing portals, public APIs, browser-facing services, and some control or data-plane services must remain reachable. For these systems, the answer is not to pretend they can disappear from the internet. They need to be heavily hardened, continuously tested, shielded where appropriate, rapidly patched, and increasingly assessed using AI-assisted vulnerability discovery. We should absolutely use AI to find and fix more defects, faster.

But many applications are not truly public by design.

Internal admin tools, partner portals, support paths, development systems, service APIs, data stores, observability systems, management planes, and agent-accessible tools often become broadly reachable because that was operationally convenient at the time. They may sit behind a VPN, a broad firewall rule, a shared subnet, or an allow-list that grew over years of exceptions. They are “private” in intent, but not always private in reachability.

A third category is perhaps the most interesting: Applications that are public today but could be made private if the user experience were seamless enough. Many organisations expose systems because making them private has historically been too hard, too slow, or too disruptive. If every change requires firewall tickets, routing changes, NAT rules, DNS exceptions, VPN profiles, and weeks of coordination, teams naturally choose the path of least resistance.

That is the connectivity tax.

In an AI-speed risk environment, reducing that tax matters. Security-by-default should not depend on every application owner, administrator, data engineer, or operations team understanding routing, VPNs, firewall rules, DNS, certificates, identity, posture, and logging just to avoid creating an attack surface. The objective is to improve security, but also to make the secure path easier than the insecure one.

 

Step 3: Architect for reduced reachability, not just better routing

Step 3 is where Zero Trust architecture becomes real.

Historically, access control was often expressed through topology because location was one of the few practical signals available: IP address, subnet, VLAN, zone, route, firewall rule, or security group. Over time, we added more context — ports, protocols, segments, tags, and policy objects — but the control model still often treated network position as a proxy for identity.

Those controls are still useful. They provide deterministic containment, regulatory boundaries, OT/ICS zones and conduits, local enforcement, and blast-radius reduction when systems or credentials are compromised.

But topology alone (“Where can traffic flow?”) is not enough. Recent reporting on residential proxy networks shows why network location is a weakening trust signal. Attackers can route through compromised consumer devices and residential IP space, making malicious activity appear to originate from ordinary home networks rather than hostile infrastructure. Location, IP address, subnet, or “inside the network” status may still provide useful context, but they should not be treated as proof of trust.

AI-speed risk therefore forces the harder question: Which user, workload, agent, tool, or service should be able to establish a connection to which specific service, for what purpose, under what conditions?

A useful way to think about this is that identity-defined reachability should collapse the graph before the dynamic decision layer is asked to adjudicate anything. The policy engine should not be responsible for evaluating every theoretically possible path across the environment. Most services should be unreachable by default. Only the small set of services that an identity could legitimately need should remain candidates for access.

Then, for that smaller candidate set, the system must require identity-defined policy before connectivity: identity, policy, posture, session state, purpose, risk, time, and action context. In other words, identity-defined reachability narrows the graph first; the policy decision governs the residue.

Policy is service-specific, continuously enforced. Effective Zero Trust enforcement combines identity, service-specific policy, posture/context, and session state so connectivity remains authorised only while the required conditions remain valid.

That is where the Software-Defined Perimeter model remains highly relevant. CSA’s SDP v3 provides a clear architecture for authenticate/authorise-before-connect. It says that a protected resource should not become reachable merely because a network path exists. Identity, context, posture, authorisation, and policy should be evaluated before connectivity is established.

Forthcoming CSA Zero Trust Microsegmentation guidance builds on this idea by distinguishing two related but different patterns:

• Topology-defined segmentation asks: Where may traffic flow?
• Connection-defined segmentation asks: Who or what may establish a session, to which service, under what conditions?

Mature Zero Trust architectures need both.

Topology-defined controls are often strongest for deterministic containment inside an environment. Connection-defined controls are strongest where reachability should not exist until identity, posture, entitlement, and service intent have been evaluated.

This becomes especially important for agentic AI.

This is no longer a theoretical concern. Anthropic’s analysis of AI-enabled cyber threats found that malicious actors are already using AI beyond preparation and initial access, including account discovery, privilege escalation, and lateral movement inside compromised environments. That matters for Zero Trust because perimeter protection alone is insufficient once AI lowers the skill and time required to navigate laterally. The architecture must assume compromise and make east-west movement harder. Services should remain unreachable unless an identity-defined, service-specific policy authorizes the path.

Agents do not behave like static users or simple applications. They may discover tools, invoke APIs, retrieve data, act on delegated authority, chain workflows, and operate across SaaS, cloud, internal applications, models, and data stores. If every new agent, tool, API, or workflow requires traditional topology changes, agentic AI will “melt the firewall.”

The point is not that firewalls go away. They remain. The point is that ticket-driven topology changes cannot be the only operating model for dynamic, identity-driven, agentic workflows.

Step 3 therefore needs to architect for reachability reduction. Public-by-design services must be hardened and shielded. Private services should be unreachable by default. Public-today-but-should-be-private services should move toward per-service, identity-defined access where the experience remains usable.

The architectural goal is to make unnecessary reachability disappear.

Identity-defined policy before connectivity. After transaction flows are mapped, connectivity should be established only when identity, policy, posture/context, and session conditions permit access to a specific service path. Both source and destination use outbound-only connections, keeping protected services dark unless policy authorizes access.

 

Step 4: Write policy for identities, services, actions, and blast radius

 

Step 4 is where Zero Trust becomes enforceable.

Traditional policy often starts with network constructs such as source, destination, port, protocol, subnet, zone, or route. These constructs remain useful, but they are not sufficient for modern systems and they are especially insufficient for agentic AI.

In an AI-speed risk environment, policy needs to assume that vulnerabilities may be discovered and weaponized faster than organisations can reliably patch every exposed service. The policy layer therefore needs to reduce blast radius before the next vulnerability is known.

The question is not only: Is this source allowed to reach this destination?

It becomes: Should this identity, workload, agent, or tool be able to reach this specific service, for this purpose, under this context, with this level of authority, and with this worst-case chain impact?

That is a very different policy model. The Kipling Method is useful here because policy must answer who or what is acting, what service or action is requested, when and where it is occurring, why it is justified, and how the connection will be enforced.

This is also where Zero Trust has to move beyond a primarily human-access model. Many Zero Trust and ZTNA deployments began with users, devices, SSO, MFA, and application access, but the same principles must govern workloads, services, APIs, agents, tools, sites, and machines. As I argued in my DoW Zero Trust Symposium talk, identity is foundational, but governance is the destination. Every human and non-human identity needs bounded scope, purpose, context, session control, and evidence.

Not all credentials provide the same security properties. A reusable password, API key, or bearer token is different from a cryptographic identity that proves possession of a private key and can be bound to a device, workload, posture state, and policy. In a stronger Zero Trust model, stealing a credential should not automatically give an attacker reachability to a protected service. Possession of a reusable secret should be insufficient unless the identity can satisfy the required policy, posture, context, and session conditions.

In practical terms, the policy decision should combine identity, policy, posture/context, and session state. Identity answers who or what is acting. Policy answers which named service, tool, API, or action path is permitted. Posture and context answer whether the device, workload, agent, environment, risk state, and purpose are acceptable. Session state ensures the connection remains authorised only while those conditions continue to hold.

The default posture should be deny all. No authorised identity should mean no service route, no application session, no permitted data packet, and no service visibility.

This decision should not be static. Posture, context, and risk signals can change during the life of a session. A device may fall out of compliance, a workload may lose attestation, an agent may request a different action class, or a threat signal may raise the risk of a service path. Step 4 therefore needs a policy that can consume dynamic assurance signals and define the consequence: allow, deny, suspend, step up, re-authorise, or terminate. Existing standards work such as the OpenID Shared Signals Framework and CAEP show how changes in session, credential, assurance level, or device compliance can be communicated across systems; identity-defined reachability needs to consume those kinds of signals so connectivity decisions can change when risk or posture changes.

This is where agentic AI raises the bar.

An agent may authenticate successfully to a tool. The tool may authenticate successfully to an API. The API may authenticate successfully to a data service. Each step may appear valid in isolation. But the combined chain may still produce an outcome that was never intended: access to a higher-risk action, invocation of a non-reversible workflow, movement into a different trust zone, or escalation into a broader blast radius.

Per-step authorisation is necessary, but not sufficient. The chain itself must remain within the intended authority, action class, and blast radius.

This is where AI security verification work around action classification and chain-level reasoning comes in. OWASP AISVS provides useful anchors for this idea. It says that actions can be classified by reversibility, runtime enforcement can be tied to that class, and multi-step or multi-agent chains can be governed by the highest-impact classification present anywhere in the chain. This classification must be trusted metadata declared at design time or by an authoritative control plane, not a label asserted by the agent at runtime. Otherwise, a prompt-injected or compromised agent could relabel an irreversible or high-impact action as low risk, reducing chain-level reasoning to advisory guidance rather than enforceable policy.

If a tool can read data, write data, modify infrastructure, trigger payments, change identity policy, deploy code, or take operational action, policy should know that. If an agent can chain several individually-permitted actions into a higher-risk workflow, policy and monitoring should understand the worst-case outcome of that chain.

The CSA Agentic Trust Framework helps here by framing AI agents as governed actors that require identity, scope, policy, monitoring, and lifecycle controls. SDP v3 provides the authenticate/authorise-before-connect foundation. The microsegmentation guidance helps by explaining how connection-defined admission and topology-defined containment can be layered across real environments.

The next architectural step is to connect these ideas. Service identity attestation tells us who or what is acting. Action classification tells us what kind of authority and risk is involved. Identity-defined reachability determines whether any connection path should exist at all.

 

Step 5: Continuously validate reachability, evidence, and drift

Step 5 is often described as monitoring and maintaining the environment. In practice, it is the step that determines whether Zero Trust remains true over time.

Environments drift.

New applications are deployed. New APIs appear. New cloud resources are created. New agents are introduced. New tools are connected. New vendors need access. New exceptions are approved. New vulnerabilities are discovered. New dependencies are observed that were never captured in the original design.

In the AI-speed era, validation cannot be a quarterly audit exercise.

Step 5 must continuously ask: Does reality still match the intended policy?

That means observing actual communication, comparing it to expected flows, validating identity and posture, detecting new reachability, identifying stale exceptions, logging policy decisions, and tightening controls as systems change.

It also means the policy lifecycle must be observable. A Zero Trust system should be able to show which policy decision authorised a connection, which enforcement point applied it, which identity and service were involved, when the decision expires, what context was used, and whether the session or flow still matches the original decision. Without that binding between policy intent and runtime behavior, least privilege can silently degrade into coarse network access.

This matters for normal enterprise applications, but it matters even more for agentic systems. If an agent calls a tool, retrieves data, invokes an API, or attempts egress, the organisation needs evidence. It needs to know what identity acted, what service was reached, what policy allowed or denied the action, what context was used, and whether the chain remained inside the approved workflow.

This is also where microsegmentation must avoid a common false tradeoff. Effective segmentation should not reduce visibility. It should preserve and improve evidence. The goal is not simply to block traffic. The goal is to understand and govern who or what communicated with which service, under which policy, from which context, and with what enforcement outcome.

That evidence is what makes policy maintainable. It is also what makes governance possible and interoperability critical. Zero Trust outcomes are only portable when policy intent, enforcement action, session state, and telemetry can be correlated across heterogeneous systems.

 

The 80/20 adoption model: reducing the connectivity tax

There is a cost to all of this.

Organisations do not have unlimited budget, engineering capacity, firewall expertise, or patience from application teams. Any Zero Trust guidance that ignores operational economics will struggle in the real world.

This is why the connectivity model matters.

A progressive reachability model avoids the common trap of treating Zero Trust as a big-bang transformation. Most organisations will operate hybrid environments for years: existing networks, firewalls, VPNs, applications, and operational processes. The adoption question is therefore not “how do we redesign everything first?” but “which flows can we move first from topology-defined reachability to identity-defined reachability, while proving lower risk and lower operational drag?”

A useful analogy comes from identity and access management. Many organisations have reduced standing privileges by moving toward just-in-time access. No one holds broad access permanently, but authorised users can request access for a defined purpose, scope, duration, and approval path.

Identity-defined reachability can follow a similar transition pattern. Rather than mapping every possible access path across the entire environment before taking action, organisations can start with a known service or painful production flow, observe which authenticated identities request access, and progressively tighten policy from “known identities may request access” toward “only these identities, under these conditions, for this duration, with this approval path, may reach this service.”

The important distinction is that this is a transition model, not the end state. The goal is to replace standing network connectivity with governed, time-bound, service-specific reachability that can be observed, approved, revoked, and continuously refined without breaking production on day one.

In many enterprises, connectivity is still a coordination problem rather than a policy decision. A single new application path may require firewall changes, routing updates, NAT rules, VPN profiles, cloud security group changes, load balancer updates, DNS changes, access reviews, security exceptions, and cross-team troubleshooting. Over time, this creates a recurring connectivity tax across infrastructure, governance, transport, security operations, and application teams.

That tax shows up in several ways:

• Long change windows and delayed application delivery
• Duplicated policy changes across multiple tools and teams
• Growing firewall, VPN, ACL, and security-group estates
• Brittle IP-based allow-lists and static secrets
• Noisy telemetry from unauthenticated or irrelevant connection attempts
• More alerts, more false positives, and more cross-team debugging
• Permanent exceptions that no one wants to own or remove
• Reduced ability to safely adopt dynamic workflows such as agentic AI

In this model, least privilege is often expensive to maintain. The more precise the policy needs to be, the more operational coordination is required. That is the wrong default: the safest pattern should be the simplest path to deploy, not the one that requires the most cross-team expertise. When security-by-default depends on routing changes, firewall rules, VPN profiles, DNS, certificates, identity, posture, and logging all being assembled correctly across multiple teams, organisations naturally drift back toward broad access, standing privileges, and “temporary” exceptions that become permanent.

Instead of asking multiple infrastructure teams to create and maintain many topology-specific rules, the policy can be expressed closer to business intent: his identity, workload, agent, or partner may reach this specific service, for this purpose, under these conditions.

If there is no authorised identity, there is no route, no session, no packet, and no service visibility. The SOC sees less unauthenticated connection noise and more real activity tied to known identities, services, and policy decisions. Application teams get a faster path to approved access. Security teams get stronger evidence of who or what accessed which service. Network teams spend less time maintaining brittle exception paths across firewalls, VPNs, NAT, and routing boundaries.

This is also a business case.

Reducing the connectivity tax can free up budget and people currently consumed by rule management, firewall operations, troubleshooting, exception handling, and manual approval workflows. It can also reduce the opportunity cost of saying “no” to new business capabilities because the connectivity and governance model cannot keep up. This is relevant for agentic AI, internal process automation, third-party collaboration, cloud-to-data-center flows, support access, and workload-to-workload modernization.

The practical adoption model is therefore not “redesign the WAN first.” It is “Pick one painful production flow, remove unnecessary reachability, prove the operational and security value, then expand.”

Start with a third-party access path. Or one VPN use case, cloud-to-data-center application, support-access path, sensitive workload-to-workload dependency, or agent-to-tool workflow.

Then apply a simple maturity journey:

• Good: Remove unnecessary reachability and reduce the connectivity tax.
• Even better: Reduce excessive access, standing privileges, and lateral movement.
• Best: embed Identity into applications, agents, workloads, services, and workflows so policy follows business intent rather than network location.

This is how organisations get meaningful outcomes without waiting for a multi-year transformation. They can start with the flows that are painful, risky, expensive, or blocking new business capabilities. Each successful flow becomes evidence of fewer manual changes, fewer exceptions, faster access approval, better telemetry, lower operational friction, and reduced blast radius.

Over time, those wins become a migration factory:

• Discover the flow
• Deploy the control
• Measure the outcome
• Expand the pattern

The end state is not only fewer VPNs, firewall rules, and brittle exceptions. It is less technical debt, less support burden, faster change, lower operating cost, and a more flexible foundation for agentic AI.

 

From SDP and microsegmentation to identity-defined reachability

CSA already has several important pieces of this architecture.

SDP v3 gives us the underlying authenticate/authorize-before-connect model. It shows how identity-centric connectivity can reduce exposure before a resource becomes reachable.

The Agentic Trust Framework gives us a governance model for autonomous agents, where trust must be managed across agents, users, tools, data, models, memory, and execution environments.

The forthcoming Zero Trust Microsegmentation guidance expands the operating model by separating topology-defined containment from connection-defined admission, and by showing how enforcement, telemetry, governance, exception handling, failure behavior, and continuous validation must work across IT, OT, cloud, edge, and agentic environments.

The next step is to make the common architectural thread explicit.

That thread is identity-defined reachability.

By identity-defined reachability, I mean an architecture in which the ability to reach a service is not assumed from network location, broad internal connectivity, static IP allow-lists, or inherited trust. Reachability is created only when identity, policy, posture, service intent, and context allow it. It is constrained to the required service or action path. It is observable, revocable, and continuously validated.

Identity provides the foundation. Governance determines whether that identity can create reachability, invoke a tool, access a service, chain an action, or continue a session as context changes.

Identity-defined reachability as the architectural roll-up. SDP provides the authenticate-before-connect foundation; microsegmentation adds topology-defined containment and connection-defined admission; and identity-defined reachability expresses the common direction. Service reachability exists only when identity, policy, posture, and context allow it.

That architectural direction also creates an interoperability challenge. If identity-defined reachability remains trapped inside proprietary and/or closed-source control planes, organizations will struggle to apply it consistently across gateways, agents, workloads, service meshes, cloud controls, OT environments, and emerging agentic systems. The next layer of standards work, and open source, is therefore about portable policy lifecycle, dynamic context signaling, and verifiable binding between policy decisions and the sessions, flows, or channels that enforce them.

This also points toward the interoperability problem now being discussed in the IETF Zero Trust Control and Policy Protocols research group. It is not enough for each product or architecture to make its own policy decision in isolation. The ecosystem needs interoperable ways to express identity- and service-based policy intent, distribute and update that intent across enforcement points, and bind policy decisions to concrete sessions, flows, or channels with verifiable enforcement outcomes. Otherwise, authenticated-before-connect reduces exposure, but least privilege may still be diluted when policy is translated into runtime enforcement.

This does not replace SDP. It does not replace microsegmentation. It does not replace topology-defined containment. It provides the architectural direction they are all moving toward.

Risk-based patching reduces vulnerability where remediation is most urgent. Identity-defined reachability reduces exposure, which can change how urgent and dangerous that vulnerability is while remediation is planned, tested, and completed. In the era of AI-speed risk, organisations need both.

 

The practical takeaway

The answer to AI-speed risk is not only “find and fix faster.”

It is also “Make sure newly exploitable services are not broadly reachable in the first place.”

For Zero Trust Steps 3, 4, and 5, that means:

• Step 3: Architect for containment and pre-connect admission across internal and external paths, not only the perimeter.
• Step 4: Write policy around identities, services, tools, actions, context, and blast radius.
• Step 5: Continuously validate reachability, evidence, exceptions, drift, and whether policy decisions remain correctly bound to active sessions and flows.

This is how Zero Trust remains relevant as AI accelerates discovery, exploitation, and autonomous action.

And it is why the next phase of Zero Trust architecture is not simply better segmentation, faster patching, or more firewall rules.

It is making the secure path the simplest path.

It is identity-defined reachability.