Not a pricing problem

The claim that AI costs more than the engineer is a measurement, and the measurement is real. A security operations team stands up an LLM-driven triage layer, or a SOAR platform such as Cortex XSOAR or Splunk SOAR, and within a single budget cycle the annual spend on inference, tuning, integration, and vendor licensing exceeds the fully loaded cost of the analyst it was meant to reduce. The number is not in dispute. What the number describes is.

A security automation system does one thing precisely: it converts signals into classifications and classifications into actions. An EDR agent emits telemetry. A correlation engine matches that telemetry against a rule or a model. A playbook executes a predetermined response. The system does not evaluate whether the response was correct. It evaluates whether the conditions to execute were met. This is its documented behavior, and it performs that behavior faithfully, every time, without regard to whether the outcome served the environment.

The organization did not buy the system to convert signals into classifications. It bought the system to remove operational complexity, to reduce the number of humans required to hold the environment together. The cost comparison, AI versus engineer, is the proxy the organization uses to confirm it received what it bought. When the proxy inverts, when the automation costs more than the person it was meant to displace, the reflex is to treat this as a pricing problem. It is not a pricing problem. The price is reporting something structural, and the structure was decided long before the invoice arrived.

The assumption underneath the purchase was that operational complexity is a fixed quantity that can be moved. That the work an analyst performs, reading an alert, judging context, deciding what is real, is a discrete load that automation absorbs, and that once absorbed it stays absorbed. Trust in the automation was treated as persistent: a playbook validated once is assumed valid across every future firing. Trust was treated as transferable: a model trained on last quarter’s environment is assumed to apply, unchanged, to this quarter’s.

More precisely, the assumption was that abstraction reduces complexity rather than relocating it. When a SOAR platform wraps 40 manual steps into one automated workflow, the environment looks simpler. The console shows one action where there were 40. But the 40 steps did not disappear. They moved beneath a layer of abstraction where they are no longer visible and no longer questioned. The assumption was that what cannot be seen is no longer a load, that hiding the work is the same as removing it.

The trust model also assumed that the automation’s confidence and the environment’s reality remain aligned. An ML classifier outputs a probability. The system treats that probability as a judgment. The assumption was that the ground truth the model learned, what normal looks like and what malicious looks like, holds still. Trust in each classification was inherited from the training state, not re-derived from the current state. The system was built to trust its own past, and to keep trusting it whether or not the present still resembled it.

What changed was not the capability of the tool and not the diligence of anyone operating it. What changed was the validity of the assumption that complexity had been removed. It had not. Complexity was relocated beneath the abstraction, and beneath the abstraction it compounded. Every integration the automation touched became a dependency. Every model became a thing to retune as the environment drifted. Every playbook became a rule that had to keep matching a world that kept moving. The labor did not leave. It changed shape, from analysis into maintenance of the thing that was supposed to replace analysis.

The assumption that trust transfers across states stopped holding the moment the environment moved and the automation did not. A model trained on one distribution of normal continues to classify against that distribution after the distribution has shifted. It does not know the ground moved. It cannot know. The system was not built to revalidate its own basis for trust; it was built to apply it. So it applied a stale judgment with full confidence, and that confidence was indistinguishable, on the console, from a correct one.

This is where the cost inverts. The spend on AI did not rise because the vendor raised prices. It rose because the hidden complexity surfaced as continuous operational load: tuning, exception handling, false-positive suppression, integration repair, model drift correction. That load required engineers. The organization now pays for the automation and for the labor to keep the automation aligned with reality. The engineer was not replaced. The engineer was moved upstream of the machine, and the machine was placed on the balance sheet beside them. The cost comparison did not reveal an expensive tool. It revealed that the assumption of reduced labor demand was never valid, and the system was faithfully reporting the difference.

The failure is not that the automation makes wrong calls. It is that the system cannot distinguish a judgment it formed against the present environment from one it formed against a state that no longer exists. A Splunk SOAR playbook fires when its trigger conditions match. That match is a reference. This alert resembles the pattern that was validated when the playbook was authored, so the playbook executes. The system acts on the resemblance. It does not re-open the question the resemblance was standing in for, which was whether this response is correct in this environment at this moment. The reference was created to make that question unnecessary. Once created, it is treated as the answer rather than a pointer to an answer that was true once.

What happened inside the failure is that identity of source replaced integrity of content. An alert arrives carrying a classification from an ML model. The downstream automation trusts the classification because of where it originated, the model, not because the classification was tested against the environment it describes. On the console this is externally indistinguishable from correct operation. A verdict appears. An action is taken. A case is closed. The console shows that the conditions to execute were met. It does not show whether the verdict corresponded to anything true in the environment, because the system was never built to display the difference between a match and a fact. The behavior executed is the documented behavior. Nothing was bypassed. The automation did exactly what it was purchased to do, which was to act on references quickly and without pausing to reconfirm them.

Beneath that, references stack on references. The model’s probability points back to its training distribution. The playbook points back to the runbook that was correct when it was written. The correlation rule points back to a threat that was current when the rule was cut. None of these re-derive their basis. Each layer inherits the trust of the layer below it and passes that inherited trust upward without testing it. An EDR agent emits telemetry, a correlation engine references a rule, a playbook references a validated response, and every handoff carries forward a confidence that was earned in a prior state. The load that surfaces as cost is precisely the labor required to re-derive by hand what the system references but will not check on its own. That labor has a name on the payroll. It is the engineer the automation was supposed to remove, now employed to supply the verification the automation structurally omits.

The pattern is execution based on reference, not verification. A system resolves a question once, stores the resolution, and every subsequent action points at the stored resolution instead of asking the question again. This is not a defect in the design. It is the design. Re-asking is expensive, and eliminating the expense of re-asking is the entire reason the reference exists. The system is correct for exactly as long as the referenced state matches the present state, and it has no mechanism to notice when that stops being true, because a mechanism to notice would be the cost the reference was built to avoid.

The same mechanism runs in DNS resolution. Under RFC 1035, a recursive resolver answers a query by returning a cached record whose TTL has not expired. It does not contact the authoritative server. The answer is served on the strength of a reference to a prior resolution, held valid until the clock says otherwise. If the authoritative record changed inside the TTL window, the resolver returns an answer that is confidently wrong and, on the wire, structurally identical to a correct one. The resolver did not malfunction. It executed its documented behavior faithfully. It resolved the name once, and for the length of the TTL it referenced that resolution rather than re-deriving it. This is the ML classifier applying a training distribution to a shifted environment, expressed in a different protocol. Both trade verification for reference to gain speed. Both are right until the referenced state diverges from the present. Both fail silently at the moment of divergence, because neither was constructed to detect the gap between what it stored and what is now true.

A SOAR platform and a DNS resolver are the same machine at different altitudes. One references a validated playbook, the other references a cached record, and each substitutes the identity of a trusted prior answer for the integrity of a current one. The abstraction that made each fast is the same abstraction that hides the moment it goes stale. The efficiency and the blind spot are not two properties that happen to coexist. They are one property described from two sides.

A security automation resolves the question of trust once. Every action after that is a reference to that answer, not a re-examination of it. The system does not revalidate, because revalidation is the cost it was purchased to remove. The control exists. The outcome does not.