Security Signals Do Not Authorize Actions
Cisco Talos observed phishing as the initial-access method in 50 percent of its incident-response engagements in the first quarter of 2025. This was a quarterly observation from Talos’s own engagements, not a measure of all breaches. It still shows why security workflows must handle changing attack patterns without treating one model score as authority to act.
Software teams face a related control problem. Veracode reported that 45 percent of the AI-generated code samples in its 2025 evaluation failed its security tests. Google’s 2025 DORA research found near-universal AI use among survey respondents and a negative relationship between AI adoption and delivery stability. Neither finding proves that AI assistance causes every defect. But, both support testing AI-assisted work inside the actual delivery system.
Detection And Decision Are Different Jobs
Neural models can classify malware, summarize alerts, and detect patterns in large volumes of telemetry. Their output remains evidence. It doesn’t establish whether the organization may isolate a host, disable an account, block traffic, or change production configuration.
Those actions depend on asset criticality, confidence, corroborating evidence, business impact, policy, and the authority of the responder. A security architecture should make that distinction explicit: probabilistic components help perceive; policy and authorization controls govern action.
Separate Perception From Enforcement
A neurosymbolic pattern can separate these concerns:
1. Neural Perception Produces Evidence
A model may report that traffic resembles a known pattern or that user behavior differs from a baseline. In this case, preserve the source, model version, confidence, and relevant context.
2. Explicit Policy Evaluates The Conditions
Rules can require corroborating evidence, check asset classification, and determine whether the workflow should recommend containment or request approval. Rules are inspectable, but they can still be incomplete or wrong. Version and test them.
3. Authority Controls Execution
A named incident role or a tightly scoped service identity executes the approved action. Low-consequence, reversible actions may be automated within policy, and high-consequence or ambiguous actions should route to an authorized person with the evidence and recovery option.
4. A Decision Record Supports Review
Capture the evidence, policy, authority, action, outcome, and any exception. That record is more useful than asking a model to generate a retrospective explanation.
Deployment Is Part Of The Threat Model
Some security workflows can’t send telemetry or incident evidence to an external service. Others can, subject to defined contractual and technical controls. Decide based on data sensitivity, latency, connectivity, model custody, logging, and recovery requirements.
On-premises or disconnected deployment reduces some dependencies but creates patching, monitoring, capacity, and model-lifecycle responsibilities. Record those tradeoffs instead of treating location as proof of security.
Start With One Security Decision
Choose one action, such as isolating an endpoint or disabling a compromised account. Define the required evidence, policy conditions, approval authority, execution identity, and recovery path. Test normal cases, conflicting signals, stale evidence, unavailable approvers, and attempted actions outside scope.
The goal is not certainty from a model, it’s a governed decision system that can use uncertain evidence without granting it uncontrolled authority.
Governing a security action from evidence through execution? Book a Consultation.