Security Intelligence: Before the System Acts
Preemptive defense, agentic systems, and the reasoning required to protect an interconnected world.
On this page
An AI agent investigates a suspicious remote session and recommends isolating the machine. Before that recommendation becomes an action, someone needs to establish what the machine does. It could be an employee's laptop, an engineering workstation, or the only available operator interface to a running process. Its network address reveals very little about the consequences of disconnecting it.
Security teams make decisions like this every day. They work with incomplete evidence, changing environments, and people who may be actively trying to mislead them. AI can help carry out that work: gather records, examine software, reconstruct activity, and investigate questions that would otherwise wait in a queue. Giving it the ability to intervene makes the quality of its understanding consequential.
The earlier opportunity is to examine that remote access before an incident occurs. Which privileges does it confer? Which operational dependencies could it reach? Could a narrower grant preserve the engineer's work while removing an unnecessary route to harm?
Security intelligence reaches across both moments. It asks what could happen, what the evidence supports, and which protective action is justified. As agents gain the ability to investigate and intervene, these questions become part of the engineering of the system itself.
What security intelligence means
In our analysis of superintelligence, we described security intelligence as using evidence and reasoning to understand threats, assess consequences, and choose protective action across digital and physical systems. That definition places the quality of a decision at the center of the subject.
The work begins with the purpose of the system being protected. A payment service must preserve the integrity of transactions. A water utility must maintain a dependable supply. A hospital must protect information while sustaining the services needed for care. Security intelligence connects technical observations to those purposes and determines which responses remain acceptable under the circumstances.
Threat intelligence contributes knowledge about adversaries, techniques, and emerging risks. Local evidence establishes what is happening here. Engineering knowledge explains how the environment behaves. Operational authority determines who can change it. A useful security system has to bring these forms of knowledge together while retaining their sources and uncertainties.
Much of this can improve with today's AI. Broad superintelligence would raise the ambition further, potentially finding vulnerabilities, explanations, and protective designs beyond current expertise. Each useful advance still needs to demonstrate that it improves decisions in the environment where it will operate.
Preemptive cybersecurity
Preemptive cybersecurity uses evidence about exposures, dependencies, adversary capabilities, and operating conditions to identify and reduce credible routes to harm before they are exploited. We use the term to describe the reasoning that makes an early protective intervention defensible.
The current interest in preemptive cybersecurity reflects a real need to act earlier. Gartner's 2026 discussion emphasizes disrupting threats before they cause harm.1 The engineering foundations extend further back. NIST's cyber-resiliency guidance, revised in 2021, already includes anticipating adversity alongside sustaining operations, recovering, and adapting.2 AI creates an opportunity to investigate more of the conditions on which that anticipation depends.
Consider a remote maintenance account with access to an engineering workstation. The workstation can reach a controller, and a configuration change could affect production. An agent reviewing this arrangement should establish whether the account can actually authorize that change, which further checks apply, and whether its access remains necessary. A connection on a diagram establishes a relationship. A credible attack path requires evidence for the steps an adversary could complete.
This makes preemptive work an active investigation. An agent could reconcile access grants with maintenance schedules, inspect configuration drift, test a proposed restriction in a staging environment, and ask the equipment owner about an undocumented dependency. Each answer changes the case for intervention. A narrowly scoped, time-limited grant might preserve maintenance access while removing standing privileges.
The next question is counterfactual: if we change this condition, which harmful outcomes become harder to reach, and which legitimate activities become harder to perform? That question connects exposure management to operational consequence. It also gives simulation a useful purpose before anyone is responding to an alarm.
The more ambitious capability is to discover combinations that existing checks overlook. A familiar permission, an ordinary maintenance change, and a new service dependency may jointly create an unfamiliar route to harm. An intelligent defender should be able to formulate that possibility, seek evidence for each necessary step, and revise it when the evidence disagrees. This is one place where advances in reasoning could materially expand the work of security teams.
Protection still needs authorization. An inferred future threat can justify closer examination or a proposed change; the power to execute that change comes from an explicit policy and accountable approval. Especially in physical operations, intrusive testing and protective interventions can themselves interrupt the service being protected.
The result should be a traceable decision: the condition identified, the evidence supporting its significance, the intervention selected, and the observation used to confirm that it worked. New software, permissions, suppliers, and operating states can invalidate that decision's assumptions. Preemptive intelligence has to keep checking them.
The SOC becomes an investigator
A security operations center, or SOC, connects observations to an organized response. Its analysts may need to reconstruct one event from identity records, endpoint activity, network traffic, application logs, and information held by a system owner. An agent can choose the next query, inspect the result, and revise its investigation. The opportunity is sustained work across these sources.
Microsoft's September 2026 account of its integrated SOC connects sensors and signals, context, models, agents, and actuators within one protection loop. IBM describes agents gathering missing asset information before choosing a response. These approaches address a practical obstacle: security tools often contain only part of the information needed for the next decision.34
There is evidence of useful gains in narrower tasks. A Microsoft-authored 2025 phishing study used a randomized experiment to examine analyst behavior. Combining those measurements with a workflow that automatically resolves agent-labeled benign messages, the paper estimated up to 6.5 times as many correctly identified malicious emails per analyst minute. That estimate depends on the workflow, attack prevalence, and assumed agent accuracy.5
The same study found that analysts shown the agent's advice missed more deliberately introduced false-negative classifications. This deserves attention alongside the productivity result. A system can direct human effort effectively while also influencing which mistakes receive further scrutiny.5
The larger SOC challenge extends into the information itself. Asset ownership may be outdated. Two tools may disagree about identity. Event timestamps may refer to different clocks. Several alerts may repeat the same underlying observation. A successful investigation needs to expose those weaknesses before they become a confident account of what happened.
What would resolve the uncertainty? Sometimes the answer is another query. Sometimes it is a call to an operator, an independent measurement, or a record that the organization has never collected. An agent that recognizes the missing evidence can make a valuable contribution even before it reaches a verdict.
When the evidence leaves the cause open
Consider a temperature measurement that rises unexpectedly. The process may have become hotter. The sensor may have developed a bias. Someone may have altered the reported value. These explanations lead to different investigations, and the reported temperature alone may leave several of them possible.
A simple model makes the problem visible. If the true temperature is T, a sensor offset b produces a reported value T+b. An attacker who changes the reported value by a produces T+a. When a=b, the two reports coincide:
A detector receiving only that report has the same input in both cases. Additional reasoning cannot create a distinguishing observation that was never supplied. An independent thermometer could establish whether the process itself is hot; identifying the source of a reporting discrepancy may require further evidence about calibration, configuration changes, or access to the measurement path.
This is a first-principles question about observability: which parts of the situation can the available measurements actually distinguish? The answer should determine the strength of the conclusion. A system may establish that a measurement is unreliable while leaving its cause unresolved.
That distinction matters operationally. Evidence of a dangerous process condition can justify a pre-engineered protective response while an investigation continues. Accusing an account of malicious activity requires evidence relevant to that claim. Security intelligence should preserve both the urgency of protection and the limits of attribution.
Equal changes to a sensor reading can produce identical reported traces. An independent measurement establishes the discrepancy while leaving its cause open.
Why Extended OT makes sense
Extended operational technology (Extended OT) gives useful language to the reach of modern operations. In its June 2026 definition, Dragos includes systems that can influence a control loop or physical process, across conventional classifications and ownership boundaries. That makes the operational consequence of a dependency central to its security significance.6
We support that direction. A cloud service that influences production, a remote-access platform used by engineers, or a building system supporting essential equipment can belong within an operational security assessment. The relevant question is what would happen to the operation if that dependency were compromised, unavailable, or wrong.
The underlying systems view has a substantial history. NIST's 2019 Situational Awareness for Electric Utilities demonstrated a combined view of operational, IT, and physical-access information. Its aim included closing the gaps created by monitoring those environments separately.7 NIST's 2023 OT guidance also covers building automation, transportation, physical access, and environmental monitoring alongside industrial control systems.8
Those publications establish that the interconnected physical environment was already within the field's scope. Extended OT can help organizations put that understanding into practice where their inventories, responsibilities, and monitoring still follow narrower boundaries. Its value should become visible in the dependencies they discover and the protective decisions they improve.
Consider an industrial site using a cloud service to recommend operating settings. A dependency map should identify how a recommendation reaches an engineer, how an approved change reaches a controller, and which physical process the controller affects. It should also establish what happens if the recommendation is unavailable. The cloud service might support optimization while local control continues independently. That difference changes both priority and response.
Operational security follows the dependencies that influence a service. Their role, ownership, and failure behavior determine the significance of a disruption.
The same action carries different consequences
Isolation is a good example. Disconnecting a compromised laptop can limit an intrusion. Disconnecting a shared gateway might remove access to several otherwise healthy systems. In a plant, an intervention can also affect an operator's ability to observe or control equipment. NIST's OT guidance places security decisions alongside performance, reliability, and safety requirements.8
In electricity systems, an investigation may need to consider the current network configuration, protective equipment, and the consequences of losing visibility. In water treatment, it may involve storage, pumping capacity, and treatment constraints. The response needs knowledge of the particular installation and its operating state.
Healthcare introduces clinical dependencies and decisions about service continuity. Manufacturing adds production sequences, maintenance states, and material already moving through a process. Data centers connect digital services to power distribution and cooling. A financial service faces its own constraints around transaction integrity, settlement, and recovery.
These examples expose a requirement that carries across industries: understand the service supported by an asset, the dependencies it shares, and the conditions under which an intervention is permissible. The appropriate response can change even when the security alert does not.
A dependency graph helps locate possible consequences. Predicting their magnitude and timing requires further knowledge. A line connecting two assets cannot tell an agent how quickly a storage tank will empty or whether a second service can take over.
First principles become executable
In 1975, Jerome Saltzer and Michael Schroeder expressed complete mediation in a sentence that remains unusually direct:
“Every access to every object must be checked for authority.”
For an agent, that principle reaches every consequential tool call. Which identity is making the request? Who delegated its authority? Does that authority cover this action, this target, and this moment? A task that began legitimately can encounter new information, a different target, or a permission that has expired.
The checks need an enforcement mechanism the agent cannot rewrite through its own output. A security agent might be allowed to query telemetry, prepare a firewall change, and terminate a specific remote session. Changing controller logic could require a separate approval path. The permissions should describe those capabilities precisely enough to be enforced.
Cisco's 2026 agent-security work emphasizes verified identities, accountable owners, and permissions limited by task and time. NIST is also developing work on software-agent identity and authorization; its September 2026 update identifies secure software development as an initial implementation use case.1011
The importance of first principles grows with the number of decisions software can make. Each added tool introduces questions about authority, input integrity, and failure. Each new dependency changes what a response might affect. Returning to the mechanism behind a claim helps identify which assumptions need testing before those decisions multiply.
Some limits should be explicit design constraints. An agent's confidence should not grant it permission to exceed an approved scope. A persuasive explanation should still pass through the same access checks. The organization needs to decide in advance which actions can proceed automatically, which require review, and what the system should do when a required check is unavailable.
The defender becomes an attack surface
A security agent studies material that an adversary may control. An email, a support ticket, a log field, or a retrieved page can contain instructions intended to redirect its behavior. When those instructions influence subsequent tool use, the investigation itself becomes an entry point.
AgentDojo, introduced in 2024, provides an environment for testing agents that use tools over untrusted data. Its tasks and attacks show why evaluation must examine both useful task completion and resistance to hostile instructions.12 In a SOC, this leads to a concrete requirement: preserve the distinction between evidence being examined and instructions authorized to govern the investigation.
Research on CaMeL explores one architectural response. It separates control and data flows and enforces policies around tool use. The approach demonstrates how established software-security mechanisms can constrain an agent whose underlying model remains susceptible to misleading content. Its guarantees depend on the defined policies and threat model.13
The same scrutiny should reach memory and delegation. A mistaken summary saved for future investigations can repeatedly influence later decisions. Several agents reading that summary may reproduce the same error. Agreement among them supplies little independent corroboration when their evidence has one common source.
Records of execution need scrutiny as well. A generated explanation that says a host was isolated should be checked against the control system's receipt and a fresh observation of the result. The record should preserve the request, the authority under which it ran, the response from the tool, and the evidence used to verify its effect.
Human review also needs design. A reviewer requires access to the important evidence, the proposed action's scope, and the consequence of declining or delaying it. Routing an unfamiliar decision to a busy person with a reassuring summary can leave the underlying uncertainty intact.
Test the consequence before intervention
Simulation can help examine a proposed response. A network model can explore which connections isolation would remove. A process model can estimate how equipment might react. Co-simulation connects models of interacting systems, allowing communication timing, control behavior, and physical dynamics to be examined together.
For a cooling installation, an agent could compare terminating a remote session with isolating the gateway that also carries operational traffic. The comparison should reveal which communications each action removes and whether local control continues. Its usefulness would depend on the model representing the actual dependencies and current operating state.
A digital twin brings additional questions about synchronization and trust. How old are its measurements? Which operating conditions have been validated? Could the same compromised source mislead both the live system and its twin? NIST's 2025 report on digital twins addresses the technology's security and trust considerations.14
The model's uncertainty belongs in the decision. If a protective action depends on a failover mechanism working, that mechanism needs evidence of its own. For important physical operations, testing may require hardware, operators, and failure conditions that a software-only demonstration does not reproduce.
Joint guidance on AI in OT, published in December 2025 by CISA, ASD's ACSC, and international partners, emphasizes testing, oversight, and failsafe practices. It also recognizes the danger of changes developing faster than operators can respond.15 This gives the engineering work a practical direction: define operating limits, establish how the system detects a failed assumption, and provide an appropriate fallback.
Recovery deserves equal attention. Reversing a configuration change may leave interrupted transactions, damaged material, or lost production. The design should establish what can be restored, how restoration will be verified, and which consequences require a different response.
A remote session remains active after its maintenance window. An independently enforced policy limits the protective action to revoking that session, followed by checks of the connection states.
What would count as progress?
An effective evaluation should follow an investigation through to its operational result. Useful measures include time to justified containment, missed incidents, unnecessary interventions, service disruption, and the effort required to recover. A fast verdict has limited meaning until those outcomes are examined.
The comparison should include competent analysts and existing automation working with equivalent evidence, access, and time. Testing should introduce ordinary changes and equipment faults alongside attacks. It should also include missing telemetry, contradictory records, unfamiliar operating states, and hostile content encountered during the investigation.
Preemptive capability needs an additional test. After an intervention, can a previously viable attack path still be completed under the stated conditions? Did the change disrupt legitimate work or leave an equivalent route open? Controlled comparisons and independently designed test cases can examine those questions. A quiet period after deployment provides limited evidence on its own: the anticipated attack may never have been attempted.
One demanding question is whether the system can recognize when its available evidence is insufficient. Another is whether it can find an observation that would materially improve the decision. These abilities can be tested by withholding a decisive source, then restoring it and examining how the conclusion changes.
Permission boundaries require direct tests. Give the agent a persuasive reason to exceed its scope and examine whether the enforcement mechanism prevents the action. Repeat the test when a tool fails, a credential expires, or a delegated task reaches a different asset. The outcome should remain traceable to the applicable rule and the evidence available at the time.
Operational trials can begin with recommendations recorded for comparison, followed by narrowly authorized actions where consequences and recovery are understood. Broader autonomy needs evidence covering the broader responsibility. It also needs ongoing examination as the environment, models, and tools change.
The prospect is substantial. Security intelligence could help teams investigate more deeply, connect expertise across industries, and discover weaknesses before an adversary exploits them. Its most valuable contribution may sometimes be a better question: which observation are we missing, which dependency have we overlooked, or which assumption makes this action appear safe?
Before a system acts, its authority should be clear. After it acts, we should be able to establish what changed and whether the result served the people and operations it was meant to protect.
Published by First Principles SI.
References
- Gartner, “When Reactive Security Falls Behind AI-Driven Threats,” October 6, 2026. Industry analysis. ↑
- NIST SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach, December 2021. Final guidance. ↑
- Rob Lefferts, Microsoft, “Reimagining the SOC for the agentic era in Microsoft Defender,” September 23, 2026. Company announcement. ↑
- John Velisaris, IBM, “How agentic AI enables an autonomous SOC with minimal human involvement.” Company perspective. ↑
- James Bono, “Randomized Controlled Trials for Phishing Triage Agent,” November 2025. Microsoft-authored study, especially Sections 2, 3.1, and 3.3. The productivity estimate combines measured behavior with the resolve-benign workflow; the false-negative observation concerns deliberately altered agent verdicts in the study. ↑a↑b
- Robert M. Lee, Dragos, “Defining xOT: What Is Extended Operational Technology?” June 2, 2026. Industry definition. ↑
- NIST SP 1800-7, Situational Awareness for Electric Utilities, August 2019. Executive summary; complete guide. ↑
- NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, September 2023. Final guidance. ↑a↑b
- Jerome H. Saltzer and Michael D. Schroeder, “The Protection of Information in Computer Systems,” Proceedings of the IEEE 63(9), September 1975, 1278–1308. Authors' hosted text, Section I.A.3(c), Complete mediation. ↑
- Jeetu Patel, Cisco, “Reimagining Security for the Agentic Workforce,” March 2026. Company announcement. ↑
- NIST, “Comments on Software and Agentic AI Identity Concept Paper,” September 29, 2026. Project update. ↑
- Edoardo Debenedetti et al., “AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents,” NeurIPS 2024, Datasets and Benchmarks. Paper. ↑
- Edoardo Debenedetti et al., “Defeating Prompt Injections by Design,” 2025, version 2. CaMeL research paper. ↑
- NIST IR 8356, Security and Trust Considerations for Digital Twin Technology, February 2025. Report. ↑
- CISA, ASD's ACSC, and international partners, Principles for the Secure Integration of Artificial Intelligence in Operational Technology, December 2025. Joint guidance hosted by ASD's ACSC. ↑
About the author
Related
Superintelligence: Beyond Human Expertise
How today's AI could advance beyond human intelligence, and what that would mean for discovery and security.