As an early-stage cybersecurity investor, I spend a lot of time with founders trying to build what comes next. But just as importantly, I spend a significant amount of time with #CISOs evaluating those ideas before we invest.
That combination keeps me grounded.
Founders show you what could be possible.
CISOs quickly tell you what is actually deployable.
And from that vantage point, one thing is becoming increasingly clear:
As agents are becoming new actors inside the enterprise, with identities, privileges, access to data, and the ability to take consequential actions, and with AI compressing the time between vulnerability discovery, exploitation, lateral movement, and response.
For CISOs, that means the challenge is no longer simply securing another technology and attack surface. It is adapting the security architecture for an environment where both attackers and defenders increasingly operate at machine speed.
CISOs therefore have to do two things simultaneously:
Secure the new AI runtime while using AI to rethink how security itself operates.
The first generation of enterprise AI security focused heavily on models and prompts:
Can sensitive data leak?
Can the model be manipulated?
Can we trust what it generates?
Those questions still matter.
But agents fundamentally change the problem.
An AI agent can call APIs, access databases, modify code, provision infrastructure, create credentials, invoke other agents, and take actions inside production systems.
So the key question increasingly becomes less:
“What can the AI say?”
and more:
“What is the AI allowed to do?”
That pushes AI security toward familiar cybersecurity disciplines:
Identity.
Authorization.
Least privilege.
Context.
Behavior.
Runtime enforcement.
Auditability.
Every production agent should eventually force us to answer:
Who is this agent?
What can it access?
What can it do?
Under what conditions?
Can I stop it?
Can I reconstruct what happened?
Most enterprises have started AI governance with policies, inventories, review boards, and risk classifications.
All of that is necessary.
But governance that cannot be enforced at runtime is incomplete.
This is one reason I am increasingly focused on runtime security across our portfolio.
Eve Security is tackling the problem of governing autonomous agents as they interact with enterprise systems.
Nirmata approaches the problem through policy-as-code and deterministic enforcement across cloud-native infrastructure and AI workloads.
AccuKnox focuses on runtime protection across cloud workloads, identities, APIs, and AI infrastructure.
These are different approaches, solving different problems, but they reflect a broader pattern:
Runtime is becoming the point where AI governance and cybersecurity converge.
And the principle is simple:
AI may be probabilistic. Security policy often cannot be.
There is enormous energy going into AI security.
That is exciting, but CISOs should resist recreating the same fragmentation that already exists across cybersecurity.
One of the questions we increasingly ask when evaluating an AI security startup is:
Is this genuinely a new security control, or is AI exposing an existing security problem that needs to become AI-aware?
Many risks still map back to fundamentals we already understand:
Identity.
Secrets.
Application security.
Data security.
Workload protection.
Vulnerability management.
Logging.
Incident response.
So rather than starting with AI-security product categories, start with the control architecture.
Map innovation to controls. Don't map controls to vendors.
Buy something new because it provides a capability or enforcement point you genuinely do not have.
The industry naturally focuses on novel AI threats:
Prompt injection.
Agent hijacking.
Model poisoning.
MCP attacks.
AI supply-chain risk.
Those are real.
But the more immediate danger may be that AI dramatically lowers the cost of exploiting ordinary security weaknesses.
An attacker may not need a new class of vulnerability.
AI can already make it easier to analyze code, identify exposures, generate exploits, customize social engineering, and navigate unfamiliar environments.
An overprivileged account is still overprivileged.
An exposed API is still exposed.
An unpatched workload is still unpatched.
The difference is how quickly an attacker can find and exploit it.
AI increases the premium on getting security fundamentals right.
The other side of this transformation is much more exciting.
The first wave of AI in cybersecurity largely focused on copilots:
Summarize this alert.
Write this query.
Explain this vulnerability.
Useful, but incremental.
The bigger transition is from:
AI assisting a task
to:
AI taking responsibility for a bounded security workflow.
And eventually to teams of specialized agents working together.
That is the direction Bricklayer AI is pursuing with specialized security agents across SOC functions such as alert triage, investigation, threat intelligence, hunting, and vulnerability management.
The long-term vision is an #AI-native #SOC in which agents perform the majority of repetitive operational work, while humans focus on the areas requiring judgment, strategy, accountability, and business context.
Think of it as moving toward a 90/10 operating model:
Agents do much of the investigation, enrichment, correlation, and workflow execution.
Humans focus on the 10% where human judgment really matters.
That is far more interesting than simply adding another chatbot to the SIEM.
The biggest productivity gain may not come from making an analyst 20% faster.
It may come from collapsing a ten-step workflow into one governed process.
Traditional automation works well when the workflow is deterministic:
If X happens, do Y.
But security investigations require reasoning.
Is this behavior normal?
Is this vulnerability exploitable?
Does the identity activity change the meaning of the cloud event?
What should we investigate next?
The SOC already has plenty of telemetry.
What it has lacked is scalable reasoning.
That is why the combination of specialized models and coordinated agents is so interesting.
The architecture increasingly looks like:
Reason → Coordinate → Govern → Enforce → Verify
That is a very different operating model from today's security stack.
There is another assumption CISOs should start questioning:
Does every security AI workload need to depend indefinitely on a general-purpose frontier model?
Cybersecurity workloads are different.
They generate large volumes of sensitive data and rely heavily on proprietary context:
Code.
Telemetry.
Identity relationships.
Threat intelligence.
Detection logic.
Policies.
Playbooks.
Historical incidents.
That is what makes Stealth (our most recent investment to be announced soon) particularly interesting!
Stealth is developing open-weight foundation models specifically for #offensive and #defensive cybersecurity use cases.
The broader idea is that enterprises and security vendors may be able to own more of the intelligence layer itself.
Through pre-training, mid-training, and post-training on proprietary data, they can potentially gain greater control over:
The model.
The data.
The harness.
The workflows.
The resulting intellectual property.
The privacy boundary.
And the economics.
For high-volume security workloads, a specialized cyber model may ultimately prove more economical and, for selected use cases, more accurate than repeatedly sending every task to the largest general-purpose model available.
The broader architectural principle is:
Treat the model as a strategic choice, not a permanent dependency.
Own your context, data, workflows, and controls.
Where it makes sense, consider owning or specializing the model as well.
This leads to a bigger question.
Today we buy separate products for application security, vulnerability management, identity, cloud, threat intelligence, detection engineering, SIEM, endpoint, attack-path analysis, and incident response.
Some of that specialization will remain necessary.
But many of the analytical boundaries exist because humans have historically been the integration layer between the tools.
AI changes that assumption.
If a security reasoning layer can understand identities, code, vulnerabilities, infrastructure, telemetry, and threat intelligence together, some of those analytical layers will begin to consolidate.
The sensors and enforcement points will remain important.
But some of the products required simply to reason across their data may not.
AI will not just make today's security products better. It will change how many products we need.
None of this means CISOs should immediately hand production security decisions to autonomous agents.
Autonomy should progress in stages:
Observe → Recommend → Human-approved action → Bounded autonomy
And the principle should be simple:
Give AI autonomy proportional to the blast radius.
Collecting logs is different from disabling an identity.
Drafting a detection is different from deploying it globally.
Recommending a configuration change is different from modifying production infrastructure.
The greater the consequence, the stronger the controls around identity, policy, verification, auditability, human oversight, and rollback should become.
If I were sitting in the CISO chair today, I would focus on five things:
1. Inventory agents, not just models. Know what can take actions, what identities agents use, and what systems they can reach.
2. Define runtime control points. Determine where unsafe actions can actually be stopped.
3. Make existing controls AI-aware before building a separate AI security stack.
4. Pick two or three bounded security workflows for AI automation. Investigation, detection engineering, vulnerability prioritization, and control validation are good starting points.
5. Measure outcomes, not AI activity. Measure analyst work eliminated, investigation time reduced, attack paths removed, vulnerabilities remediated, detection coverage improved, and autonomous actions safely completed.
The biggest challenge facing CISOs isn't choosing the right AI framework or the next AI security category.
It is designing the security architecture for a world where AI becomes both:
an execution layer inside the enterprise
and
an increasingly important part of the security workforce defending it.
That requires us to secure identity, context, permissions, workloads, models, data, and actions at runtime.
But it also gives us an extraordinary opportunity to rethink security operations:
To reason across silos.
To deploy specialized agents.
To connect offense and defense.
To automate repetitive security engineering.
To preserve human judgment where it matters most.
And potentially to simplify a security stack that has become far too fragmented.
For years, cybersecurity has asked humans to compensate for the limitations of our tools.
AI gives us an opportunity to reverse that equation: let machines handle the volume and repetition, while humans focus on judgment, strategy, creativity, and accountability.
The organizations that get this right won't simply have a better AI security program.
They will operate security differently.
This version preserves the core thesis and all five portfolio-company references while cutting a lot of the repetition and secondary examples.
