Reading · Edward's Substack

Every major technology wave seems to follow a familiar pattern.

First comes excitement.
Then rapid adoption.
Then uncertainty.

Soon afterward comes an explosion of products, frameworks, and commentary promising to “secure” whatever new technology has captured everyone’s attention.

Eventually, years later, we realize we were asking the first question, not the lasting one.

Phil Venables recently wrote an excellent piece titled “Technology Waves and Security: Is This Time Really Different?” His observation is not only about artificial intelligence. It is about how transformational technologies mature. Early in a wave, we tend to describe security in broad terms: Internet Security, Cloud Security, AI Security. Those phrases are useful because they help us begin the conversation.

But they rarely survive long enough to become the architecture.

The language eventually decomposes into something more precise.

Internet security became firewalls, identity, PKI, TLS, application security, secure software development, software supply chain assurance, and eventually Zero Trust.

Cloud security became workload identity, policy-as-code, posture management, secrets management, infrastructure as code, confidential computing, and shared responsibility models.

The terminology evolved because the architecture evolved.

Artificial intelligence appears to be following the same trajectory.

The question is not whether AI security matters. Of course it does. The more interesting question is whether “AI security” is the final category or merely the early language we use before the deeper architectural disciplines become clear.

I suspect it is the latter.

In my graduate class at Washington University in St. Louis, I have often used the early Internet as a reference point. I ask students to imagine it is 1994, when the firewall was emerging as the defining security technology. At the time, network security was still largely understood through perimeter defense. That was understandable. The visible problem was connectivity, and the obvious answer was controlling what crossed the network boundary.

Looking back, we know that was only the first chapter.

Few people at that moment fully appreciated how identity, applications, software supply chains, cryptographic provenance, cloud computing, and Zero Trust would eventually redefine the discipline. Not because those ideas were irrelevant, but because the technology wave had not yet revealed the problems they were meant to solve.

If I had walked into a boardroom in 1994 and said that one day we would worry less about the firewall and more about workload identity, software provenance, and cryptographic evidence, I probably would have been laughed out of the room.

Not because the statement would have been wrong.

Because the market had not yet matured enough to make the statement feel practical.

I have a growing suspicion that AI is at that same point today.

Much of the current conversation is still focused on the first visible questions. How do we secure prompts? How do we prevent data leakage? How do we detect malicious model behavior? How do we stop employees from pasting sensitive data into public tools? Those are valid questions, and organizations need practical answers now.

But they may not be the enduring questions.

The deeper question is beginning to emerge underneath them.

How do we know when AI deserves to be trusted?

Much of today’s conversation asks:

“How do we secure AI?”

It is an understandable question, but probably not the complete one.

The question that eventually reshaped our own work became something different:

“How do we know when AI deserves to be trusted inside consequential operations?”

Those are fundamentally different problems.

One produces security products.
The other produces infrastructure.

That distinction matters because AI is not simply another application to protect. AI increasingly participates in interpretation, recommendation, prioritization, escalation, documentation, workflow execution, and eventually action. The security problem is therefore not limited to protecting the AI system from abuse. It also includes determining whether AI should be allowed to influence a decision at all.

That is a different architectural challenge.

A model can be capable and still not be trustworthy in a particular context.
A recommendation can be statistically sound and still be inappropriate for a given operational environment.
An agent can have the technical ability to act and still lack the authority to act.

Those distinctions are where the next architecture begins.

Interestingly, we did not arrive at this through questioning artificial intelligence.

We arrived here through the search for reliable operational assurance and resilience.

Long before large language models became household topics, much of our work centered on Operational Technology, industrial control systems, consequence-driven cybersecurity, and the difficult reality that operational leaders rarely suffer from a shortage of data.

They suffer from a shortage of synthesis, correlation, and confidence.

Over time, I found myself returning to a deceptively simple question:

If this information does not change a decision, is it actually helping anyone?

Every alert.
Every vulnerability.
Every dashboard.
Every sensor.
Every engineering report.
Every security event.

Each exists for one reason: to help someone make a better operational decision.

If it cannot meaningfully influence a decision, it eventually becomes noise.

That realization became one of the foundational ideas behind our OT SOC Options work. As we developed what ultimately became the CIE-CORE methodology - Cyber-Informed Engineering-inspired, Consequence-Oriented Risk Evaluation, the most valuable conversations rarely centered on vulnerabilities alone. They centered on consequence.

Not simply:

“What vulnerabilities exist?”

But:

What operational decision could this influence?
What happens if that decision is wrong?
What evidence would an engineer require before acting?
Which controls actually create confidence, and which simply create visibility?

That shift changed our thinking.

Traditional cybersecurity often begins with threats, techniques, exposures, and probabilities. Operational environments begin somewhere else. They begin with what must not fail.

Personnel safety.
Environmental protection.
Production continuity.
Asset integrity.
Regulatory obligations.
Public trust.
Executive accountability.

In that setting, the value of cybersecurity is not measured by the number of alerts collected. It is measured by whether the organization can prevent, detect, understand, and respond to conditions that could produce unacceptable outcomes.

That realization pushed us toward consequence-first thinking.

It also revealed a larger problem.

Organizations were rarely lacking telemetry.

They were lacking evidence.

Traditional cybersecurity naturally emphasizes digital evidence.

Operational environments have never worked that way.

An experienced control room operator does not make decisions from network telemetry alone. A plant manager does not evaluate operational risk by looking only at security alerts. A process safety engineer does not establish confidence from a vulnerability score.

They synthesize.

They combine process historian data, vibration analysis, maintenance history, environmental conditions, operator observations, engineering procedures, physical inspections, safety system status, visual confirmation, vendor activity, prior incidents, and years of accumulated operational experience.

Trust has always been assembled from multiple forms of evidence.

The problem is that most digital architectures were not designed to preserve that relationship.

Cyber tools generated cyber evidence.
Engineering systems generated engineering evidence.
Physical security systems generated physical evidence.
Environmental systems generated environmental evidence.
Maintenance systems generated maintenance evidence.
Procedures lived somewhere else.
Human judgment lived in people’s heads.

The enterprise often had data everywhere and trust nowhere.

That realization eventually led us toward Continuous Digital and Physical Validation, or CDPV. The idea was straightforward but difficult to execute: rather than treating cyber, physical, operational, environmental, visual, and procedural information as separate disciplines, treat them as evidence contributing toward a single operational decision.

In practice, that means asking a different set of questions.

Can the digital state be confirmed by the physical state?
Can the process claim be confirmed by instrumentation?
Can the engineering record be confirmed by configuration?
Can the access event be correlated with visual or procedural evidence?
Can the safety assumption still be trusted after a change?

The more we expanded that model, the more another realization emerged.

The real problem was not only validating systems.

It was validating influence.

Enterprise technology has gone through several major trust transitions.

Systems of record gave organizations a place to store authoritative information. ERP systems, financial systems, asset inventories, customer records, and compliance repositories became the institutional memory of the enterprise.

Then systems of engagement connected people, processes, customers, and partners. Collaboration platforms, service portals, mobile applications, workflow tools, and digital channels changed how organizations interacted with the world.

For years, the trust question was largely about accuracy, access, and availability.

Is the record correct?
Who can see it?
Who can change it?
Was the change logged?

AI introduces something different.

We are moving toward systems of judgment.

These systems do not merely store information or route interaction. They interpret, summarize, recommend, prioritize, escalate, draft, decide, and in some cases act. They transform data into judgment-like outputs that humans may rely upon in operational, clinical, industrial, financial, and public-sector contexts.

That changes the trust model.

A system of record can be audited after the fact.
A system of engagement can be monitored through workflow controls.
A system of judgment must be governed at the moment influence is created.

That is the architectural break.

When AI summarizes an incident, it is influencing understanding.
When AI prioritizes a risk, it is influencing attention.
When AI recommends an engineering action, it is influencing authority.
When AI drafts a compliance response, it is influencing institutional memory.
When AI operates as an agent, it is influencing execution.

The question is no longer only whether the data is protected.

The question is whether the judgment produced from that data deserves to influence the next decision.

This is where many current AI governance conversations still feel incomplete. They focus on policies, committees, acceptable-use language, and model evaluation. Those things matter, but they do not fully govern judgment in motion.

A trustworthy system of judgment requires identity, authority, evidence, provenance, consequence classification, and enforceable boundaries before the output is allowed to matter.

That is why AI governance cannot remain a document.

It has to become part of the architecture.

Every recommendation.
Every optimization.
Every autonomous workflow.
Every AI-generated insight.
Every software agent.

Each represents a new influence entering an existing operational system.

Before asking whether that influence is intelligent, organizations must first determine whether it is appropriate.

Should this AI have access to this information?
Should it participate in this workflow?
Should it make this recommendation?
Should it influence an operator?
Should it change the priority of work?
Should it generate evidence for a regulator?
Should it ever be permitted to influence a physical process?

Those are not language model questions. Those are architectural questions.

The model may generate the output, but the system surrounding the model determines whether that output is authorized, supported, bounded, explainable, and evidenced.

That distinction became increasingly important as our work moved through OT operational assurance and resilience and into trusted AI infrastructure.

We were not following AI because AI was fashionable.

We were following the trust problem.

Eventually, it led directly into AI.

That realization fundamentally changed our perspective.

We stopped thinking about governance as documentation written after deployment.

We began viewing governance as something that had to exist before influence occurred.

Identity.
Authority.
Policy.
Consequence.
Provenance.
Evidence.
Human accountability.

These were not features we hoped organizations would eventually implement.

They became our architectural primitives that had to be continuously enforced.

Not because compliance required it.

Because trust required it.

As we continued building out the Axiom model, another pattern emerged. The industry often treated trust as a property of the model. Our experience suggested something different.

Trust is a property of the entire system.

A foundation model may be extraordinarily capable, but capability alone says nothing about whether it should participate in a particular workflow, influence a particular decision, or operate with a given level of authority.

Those questions cannot be answered by the model itself.

They must first be answered by the physics of operations and the organization, then be enforced by the architecture surrounding it.

That’s where our work naturally evolved. Operational assurance and resiliency led to consequence-first engineering. Consequence-first engineering led to continuous evidence. Continuous evidence led to governed influence. Governed influence ultimately led us to a simple conclusion:

Trust cannot remain a policy.

It has to become architecture.

One of the most important lessons from this work is that the trust problem does not primarily live inside the model.

It lives at the deployment boundary.

This does not mean model safety is unimportant. It is obviously important. Model evaluation, alignment, red-teaming, guardrails, training data governance, and misuse prevention all matter.

But regulated industries and high-consequence environments face an additional problem.

They must prove that AI operated within an authorized context.
They must prove what information it used.
They must prove what authority it had.
They must prove what it was prohibited from doing.
They must prove what evidence supported its recommendation.
They must prove who reviewed or approved the outcome.
They must prove whether the AI-influenced decision remained inside an acceptable operational envelope.

These are deployment questions.

They are not solved by model capability alone.

In industrial environments, this is especially clear. A model may be helpful in interpreting maintenance trends, correlating anomalies, or generating an executive narrative. But if that output can influence a control decision, a safety decision, a production decision, or a regulatory decision, then the surrounding architecture must define and enforce the terms of that influence.

That is not a chatbot problem or merely a SOC automation problem.

That is an operational trust problem.

One unexpected confirmation came from the students at Washington University in St. Louis.

Students adapted to AI remarkably quickly.
Prompt engineering was not perceived as particularly difficult.
Tool orchestration was grasped quickly.
Even basic agent concepts were not particularly challenging.

What emerged from the discussions was something else.

Knowing when AI should be trusted.

Not technically.

Operationally.

This past semester, while teaching graduate cybersecurity students, I adjusted the way we examined security operations. The course was built around the work of a modern security operations function, but I did not want students to think of the SOC as only a room full of analysts, dashboards, alerts, and tickets.

I wanted them to see the SOC as an influence system.

A SOC does not merely observe risk. It influences attention. It influences escalation. It influences response priorities. It influences leadership perception. It influences whether scarce people, money, and time move toward one problem instead of another.

Once students began looking at the SOC that way, the discussion changed.

We broke down security operations into a chain of influence surfaces.

An alert is an influence surface because it redirects analyst attention.
A correlation rule is an influence surface because it decides which signals deserve to be grouped together.
A severity rating is an influence surface because it changes urgency.
A threat intelligence report is an influence surface because it shapes interpretation.
A ticketing workflow is an influence surface because it determines who owns the next action.
An executive summary is an influence surface because it may change budget, staffing, policy, or risk appetite.

That framing helped students see that operational trust is not created at the end of the process. It is either preserved or degraded at every point where information changes someone’s judgment.

From there, we moved to authority surface discovery.

This was the other half of the problem. It is one thing to ask what information can influence a decision. It is another to ask who or what has the authority to act on that influence.

Who can escalate?
Who can close an incident?
Who can suppress an alert?
Who can change a detection rule?
Who can approve containment?
Who can call operations and ask for a system to be taken offline?
Who can brief the executive team?
Who can convert a technical concern into an enterprise decision?

In many environments, the formal authority model and the practical authority model are not the same. The org chart says one thing. The workflow says another. The most experienced analyst, the loudest vendor dashboard, the most confident AI-generated summary, or the most persuasive executive narrative may carry more practical influence than the documented process suggests.

That is where the SOC discussion became directly relevant to AI.

An AI system inserted into a SOC does not simply add automation. It adds influence.

If it summarizes an incident, it influences understanding.
If it ranks alerts, it influences attention.
If it recommends escalation, it influences urgency.
If it drafts an executive report, it influences leadership perception.
If it proposes containment, it approaches operational authority.

The students began to see that the key question was not merely whether the AI was accurate. Accuracy matters, but it is not sufficient.

The deeper question was whether the AI’s influence had been properly bounded by evidence, authority, consequence, and accountability.

We also spent time on what I called executive influence techniques. Not manipulation. Not salesmanship. The discipline of translating operational reality into decisions executives can actually make.

A technically correct finding that does not change a leadership decision has limited value. A well-framed finding connects signal to consequence, consequence to authority, authority to action, and action to evidence.

That is the real work of a mature SOC.

Not simply detecting more.
Not simply reporting faster.

But shaping decision confidence at the right level of the organization.

This became one of the most useful teaching moments of the semester. The SOC was no longer just a monitoring function. It became a living example of how trust moves through an organization.

Signals become narratives.
Narratives influence decisions.
Decisions activate authority.
Authority creates consequence.

AI enters that chain not as a neutral tool, but as a new participant in the organization’s influence model.

That realization matters because it forces a more serious architecture conversation.

Before we ask whether AI can help the SOC, we need to ask where AI is allowed to influence the SOC.
Before we ask whether AI can recommend action, we need to know what authority surface that recommendation touches.
Before we allow AI-generated analysis into an executive decision cycle, we need to know what evidence travels with it.

That classroom work reinforced the broader lesson.

The future SOC will not only discover attack surfaces.

It will need to discover influence surfaces.
It will need to understand authority surfaces.

And it will need to govern how human, machine, and AI-generated judgments move through the enterprise before they become operational decisions.

The next generation of cybersecurity professionals will spend less time asking whether AI is capable and far more time determining whether AI is operating within appropriate authority, supported by sufficient evidence, and producing decisions that can be independently defended.

That is a very different discipline than simply securing another tool.

This is where Phil’s article resonated so strongly with me.

I suspect that ten years from now, the phrase “AI Security” will sound every bit as imprecise as “Internet Security” does today.

Not because security will matter less.

Because the discipline will become more precise.

We will stop treating AI as a single thing to secure and start treating it as a set of influence paths to govern.

That realization is what eventually led us to NexGenomics, our trusted AI infrastructure.

The question became:

What would have to be true architecturally before an organization could trust AI inside a consequential environment?

The answer was not one control.

It was an evidence architecture.

We began to see trust as something that had to be assembled across multiple layers, each one producing proof that the AI system was operating within its intended boundary.

At the bottom, the infrastructure itself has to be governed. Cloud services, compute environments, keys, hardened baselines, and privileged access cannot be assumed. They have to produce evidence.
Then the tenant boundary has to be governed. In regulated environments, especially industrial, healthcare, and multi-client delivery models, trust begins with knowing that data, policy, evidence, and authority remain isolated by design.
Then the data layer has to be governed. The system must know what data it is using, where it came from, what classification it carries, what residency obligations apply, and whether its integrity can be defended.
Then the model layer has to be governed. Which model was used? Which version? Was it approved for this use case? Was it cleared to process this class of data? What is known about its limitations?
Then runtime safety has to be governed. The moment of output matters. A system that governs before inference and audits after inference, but does not enforce policy at the moment an output is generated, still leaves the most important gap open.
Then service access has to be governed. Every service call, API request, tool invocation, and system interaction must be attributable, authorized, and policy-bound.
Then memory and context have to be governed. Agents do not only reason from current prompts. They may retain, recall, summarize, or infer from prior context. That memory must have boundaries, retention rules, tenant isolation, provenance, and a way to forget what it is no longer permitted to know.
Then the agent itself has to be governed. The agent needs an identity. It needs an authority scope. It needs an owner. It needs a defined autonomy level. It needs a kill switch. It needs to prove that it operated inside the boundary it was given.
Then workflows have to be governed. Many of the most important risks do not arise from one agent doing one thing. They arise when multiple authorized steps combine into an unauthorized outcome. Workflow governance prevents authority from escalating simply because automation stitched together the wrong sequence.
Then orchestration has to be governed. Human-in-the-loop approvals, multi-agent coordination, rollback logic, canary testing, escalation paths, and management-of-change gates have to be part of the operating model, not after-the-fact review.
Finally, audit, evidence, and observability have to be governed continuously. Evidence cannot be reconstructed after an incident and still be called trust. It has to accumulate as the natural byproduct of governed operation.

That is the NexGenomics view of trusted AI infrastructure.

Eleven layers.

Not eleven policies, hopes and prayers.

Eleven evidence-producing boundaries.

Each layer answers a different trust question.

Was the environment controlled?
Was the tenant boundary preserved?
Was the data permitted?
Was the model appropriate?
Was the output checked before influence?
Was the service call authorized?
Was memory properly scoped?
Was the agent operating within its authority?
Was the workflow approved?
Was orchestration governed?
Can the entire chain be proven after the fact?

That is the difference between documenting AI governance and enforcing it.

Cybersecurity has spent decades becoming exceptionally good at detecting undesirable behavior.

That remains essential.

But in high-consequence AI environments, detection is not enough.

By the time an unauthorized AI recommendation has shaped an operator’s judgment, a clinician’s decision, an executive report, or an automated workflow, the influence has already occurred.

The next question is not only:

What happened?

It is:

Should this have been allowed to matter?

That is the shift.

From detection to governed influence.
From alerting after behavior to enforcing authority before consequence.
From trusting the model to proving the system around the model.

This is why I believe AI governance cannot remain trapped in committees, policy documents, or acceptable-use language. Those things matter, but they are not enough. A policy that is not enforced by architecture becomes a hope. A framework that cannot produce evidence becomes a presentation. A governance committee that cannot bound agent authority becomes a review body after the influence has already occurred.

Governance is what the architecture enforces when no one is watching.

I don’t think the next decade will be defined only by who builds the largest model.

Models will continue improving. That is almost certain.

But capability is not the same as trust.

The harder problem will be determining when those models deserve to participate in consequential decisions, under what authority, with what evidence, and within which operational boundaries.

That is the work we have been following.

From OT operational assurance.
To consequence-first analysis.
To continuous digital and physical validation.
To influence and authority surface discovery.
To trusted AI infrastructure.

In hindsight, we did not start by asking how to secure AI.

We started by asking how organizations make decisions they can defend.

AI simply made the missing trust architecture impossible to ignore.

That may be where this technology wave is headed.

Not toward more security definitions, but toward more precise trust.

For us, that architecture is NexGenomics.

And I suspect it will begin to matter more than most people realize today.

No posts

The Technology Wave After "AI Security"

Comments