Introduction
In Part I of our Cybersecurity essay, we introduced the thesis that AI is breaking the historical parity between offense and defense, mapped the cybersecurity landscape through the Cyber Attack Chain, and explored two downstream effects: AI collapsing the cost and time of producing software, and humans becoming the new bottleneck in the security response cycle.
In Part II, we reintroduce the attack chain mapping and explore two additional downstream effects, along with how early-stage companies are tackling the opportunities they create.
Today’s Landscape
We’ve created a framework we call the “Cyber Attack Chain” to organize the cybersecurity landscape around two components: the attack chain itself and the security layers that operate across it. This provides the baseline for examining where AI is reshaping existing security paradigms.
First and foremost, we must understand the attack chain component which illustrates the typical sequence of a modern intrusion. We model this framework after the April 2026 Vercel incident,, in which attackers compromised an employee device at a third-party vendor, used the OAuth token that vendor held to traverse into Vercel’s internal systems, and ultimately reached credentials belonging to downstream customers.
The chain consists of four stages:
Initial Access — gaining an entry point through the software supply chain, phishing, vulnerable code, devices, or other exposed assets.
Identity & Trust — abusing human or non-human identities, credentials, permissions, and trust relationships to expand access.
Target Infrastructure — interacting with the systems where workloads, applications, and data reside.
Downstream Impact — achieving the attacker’s objective, such as data exfiltration, ransomware, disruption, or persistence.
This ordering reflects how an attacker progresses, not necessarily how security products are marketed.
Cross-Cutting Security Functions
Second, there are three main layers which span across the entire attack chain rather than embodying a single stage:
Exposure Management (CTEM) continuously discovers, validates, and prioritizes weaknesses before they are exploited.
Security Operations (SecOps) detects, investigates, and responds to threats throughout an attack.
Governance, Risk, and Compliance (GRC) defines policies, manages risk, and ensures regulatory compliance across the organization.
These functions provide organization-wide visibility and coordination, making them cross-cutting capabilities rather than point solutions.
With this framework in place, we can better understand how today’s inflections propagate across the security landscape.
Downstream Effect 3: AI Brings More of the Attack Surface In-House
AI adoption is increasingly splitting between proprietary foundation models and open-weight alternatives. OpenRouter’s analysis of more than 100 trillion tokens routed through its platform found that open-weight models grew steadily to roughly one-third of usage by late 2025 (OpenRouter). Proprietary models still serve the majority of tokens, but the trend is early evidence of a durable multi-model ecosystem rather than convergence on a single provider.
Deploying open-weight models at scale still requires specialized infrastructure and operational expertise. However, advances in inference infrastructure, orchestration frameworks, and deployment tooling are rapidly lowering these barriers. As hosting and fine-tuning become easier, enterprises will increasingly deploy models tailored to their own data and workflows. For many organizations, this will still mean renting cloud compute rather than owning physical infrastructure, while others will continue relying on proprietary APIs for frontier intelligence. The result is not a wholesale replacement of proprietary models, but a more fragmented AI stack in which enterprises operate across proprietary APIs, third-party inference providers, and models they increasingly configure or operate themselves.
The security boundary moves with that ownership. When an enterprise consumes a frontier model through a managed API, much of the underlying model-serving infrastructure remains the provider’s responsibility. As enterprises host, fine-tune, and deploy models through their own infrastructure, they inherit responsibility for a larger portion of the stack: model artifacts and repositories, fine-tuning pipelines, inference frameworks, containers, gateways, and the workloads on which those systems run.
Increased Need for Cross-Environment Security
As enterprises take ownership of more AI infrastructure, that infrastructure is unlikely to consolidate into a single environment. An enterprise may simultaneously rely on proprietary model APIs, third-party inference providers, and models running within its own infrastructure. A fragmented AI stack increases the value of security tooling that can maintain visibility and control across proprietary APIs, third-party inference, and enterprise-hosted models. Open-weight adoption matters not because it implies the disappearance of proprietary AI, but because it provides evidence that enterprise AI may remain structurally fragmented (OpenRouter). As responsibility spreads across more of the stack, the security problem shifts from protecting any one environment to maintaining consistent controls across all of them.
Downstream Effect 4: Machine Identity Explosion and Emergence of the Least Agency Principle
While non-human identities (NHIs) such as service accounts, API keys, and certificates have become commonplace along with the growth of cloud native infrastructure, they had generally been associated with a human identity and governed under a model of implicit trust. Once provisioned, access was largely trusted based on the identity’s owner and assigned permissions rather than continuously reevaluated based on its behavior.
Artificial intelligence has, again, fundamentally expanded what constitutes an identity. Today’s NHIs include not only service accounts and API keys, but also OAuth tokens, machine credentials, workload identities, and increasingly, autonomous AI agents. Their impact stems not only from their growing capabilities, but also from their sheer scale. According to KPMG, “non-human identities (NHIs) now outnumber human users by 82 to 1”, making them the dominant identity class that enterprises must secure.
How NHIs reshape identity
The explosion of NHIs is reshaping the identity problem across three dimensions: scale, velocity, and capability.
First is scale. Every additional workload, service, automation, and agent can introduce another machine principal and set of privileges for enterprises to govern. As the number of machine identities grows, so does the attack surface surrounding them, giving Identity & Trust greater weight within the attack chain.
Second is velocity. Machine identities can be created and changed programmatically, often in seconds. Identity controls built around periodic reviews and manual administration cannot keep pace with an environment that changes at machine speed, creating a need for faster, more continuous governance.
The immediate response to these first two problems remains rooted in traditional identity controls. Enterprises first need to discover which NHIs exist, determine who or what owns them, understand what resources they can access, and eliminate stale or unnecessary credentials. As the population grows, static secrets and persistent permissions increasingly give way to workload identity, automated rotation, short-lived credentials, and just-in-time or task-scoped authorization. This creates opportunities for machine-native platforms such as Infisical and Keycard, while identity incumbents including Idira (previously CyberArk; acquired by Palo Alto), Okta, Microsoft, SailPoint, and platforms such as ConductorOne have natural expansion paths into NHI governance.
The third and final change is capability. Traditional service identities typically execute predefined application logic; AI agents can make decisions about which tools to use, what information to retrieve, and what actions to take next. This turns machine identities from passive credentials into active actors, expanding the identity problem from governing access to governing what autonomous systems can actually do with that access.
The controls described above extend the logic of Zero Trust and least privilege to a much larger population of machine identities. But autonomous agents introduce an additional question. Least privilege can constrain what resources an agent may access, but it does not determine how much autonomy the agent should have given that access. An agent may legitimately require access to GitHub, AWS, and a production database to complete a task without requiring unrestricted authority across all three.
Driven primarily by expanding capability, but reinforced by the scale and velocity of NHIs, this shift points toward what we believe will become an important governing principle for identity security: Least Agency.
What is Least Agency and how does it work?
Least privilege governs what an identity can access; What OWASP has termed “Least Agency” extends that principle to what an autonomous system can do once access is granted. Rather than assigning an agent a fixed level of autonomy, Least Agency aims to constrain its ability to act to the minimum required for a given task and context, with that autonomy expanding or contracting as risk changes.
Jason Stanley breaks down Least Agency into three primary design patterns:
Capability contracts and local guards: Constrain individual actions at execution — what tools an agent can call, on which resources, with what arguments and credentials.
Trajectory-level controllers and watchdogs: Monitor behavior across actions and time, intervening when an agent deviates from its expected operating envelope.
Staged and conditional autonomy: Dynamically expands or contracts an agent’s autonomy based on task risk, observed behavior, and environmental context.
For the purposes of the market, we condense Stanley’s three patterns into two investable control surfaces: action-level and trajectory-level control. Action-level control governs whether an individual agent action should execute while trajectory-level control governs whether an agent’s behavior over time warrants maintaining, expanding, or restricting its authority. Staged autonomy is the resulting state — how much agency the system should have at a given moment.
Within the existing Identity & Trust layer, the near-term opportunity is clearest at the action level. Action-level control determines whether a specific agent action should be permitted to execute given its identity, permissions, task, and context. Security can issue scoped credentials, authorize tool calls, constrain resources and arguments, and enforce approval boundaries directly in the execution path. These controls are necessary infrastructure, but their proximity to execution also creates platform risk: IAM and PAM vendors, MCP gateways, harnesses, and cloud platforms are all naturally positioned to incorporate them as native capabilities.
Trajectory-level control is far less settled. Rather than evaluating an action in isolation, it asks whether an agent’s behavior across a sequence of actions still warrants the authority it holds. That question cannot be answered from identity and permissions alone. It requires visibility into how an execution has actually unfolded, which is not something the Identity & Trust layer was built to provide.
We believe Least Agency is likely to become an important governing principle for autonomous systems. What remains unclear is the architecture through which it will be enforced. Identity establishes the authority; governing that authority dynamically requires context that sits outside the identity layer entirely. That is where the existing attack-chain framework begins to reach its limit.
Conclusion
The AI stack is fragmenting rather than consolidating: enterprises increasingly operate across proprietary APIs, third-party inference, and self-hosted open-weight models, and as more infrastructure moves in-house, the security boundary shifts with it. We like companies built for this fragmentation rather than for any single environment — tooling that maintains consistent visibility and control across proprietary APIs, third-party inference, and enterprise-hosted models, since the value comes from spanning the stack, not securing one piece of it well.
Furthermore, non-human identities are exploding in number — now vastly outnumbering human ones — while also changing in kind, from passive service accounts into autonomous agents capable of deciding, not just executing. This is straining identity controls along scale, velocity, and capability at once. We like two types of companies here. First, machine-native identity platforms addressing scale and velocity through workload identity, automated rotation, short-lived credentials, and just-in-time authorization. Second, companies building trajectory-level control for agent autonomy. Action-level control is real but crowded, easily absorbed natively by IAM/PAM vendors, MCP gateways, harnesses, and cloud providers. Trajectory-level control looks more durable, since it demands behavioral visibility over time that no adjacent incumbent already owns.