AI versus AI: what a Mythos-class defender and a GPT-plus attacker mean for the SOC

The framing: security is becoming AI-vs-AI

The defender's job used to be a contest of humans against humans, mediated by tools. An operator on the other side ran reconnaissance, wrote a phishing lure, triaged stolen credentials, and moved laterally — each step gated by their own time, attention, and skill. Those human constraints were, quietly, one of the defender's most reliable allies: they set the tempo of every intrusion, and the SOC calibrated its own tempo to match.

That alliance is dissolving. A growing share of the attacker's workflow — recon, targeting, lure generation, exploit triage, obfuscation, and the chaining between them — can now be handed to a frontier-capability model that does not tire or need to sleep. The consequence is not that attacks become smarter in some abstract sense. It is that the interval between "attacker decides to act" and "attacker has acted" collapses, and it collapses on the parts of the kill chain that used to give defenders their warning time.

This is the asymmetry that matters. The attacker can afford to be wrong most of the time because the marginal cost of another attempt is near zero. The defender gets no such luxury: a defensive AI that is wrong at machine speed doesn't just waste effort, it can take a consequential action against production, close a real incident as benign, or be steered into doing the attacker's work. Matching the attacker's tempo is necessary. Matching it without matching the attacker's tolerance for error is the actual problem.

What the attacker side gains from frontier AI

It is worth being concrete about where automation actually helps an adversary, because the honest answer is "a lot, but not everywhere," and the exceptions are load-bearing for the defence.

Faster, cheaper reconnaissance and targeting

The most immediate gain is at the top of the funnel. Enumerating an organisation's external surface, correlating employees against public data, inferring reporting lines, and assembling a target dossier used to be hours of skilled work per target. A GPT-plus archetype compresses that to minutes and scales it near-linearly across thousands of targets at once. The reconnaissance is not qualitatively superhuman; it is the same reconnaissance a competent operator would do, produced at a rate no human team can sustain.

Tailored phishing, pretexting, and synthetic media

Language is where frontier models are strongest, and social engineering is a language problem. Lures that are grammatically native, contextually specific, and personalised to the recipient's role and recent activity are now cheap to produce at volume. Voice and video synthesis extend the same logic to pretexting and business-email-compromise callbacks. The signal defenders relied on for a decade — that phishing "looks off" — is degrading, and it will keep degrading.

Exploit triage and agentic chaining

Given a foothold and a set of observations, a capable model can summarise a target environment, rank plausible next moves, translate a public proof-of-concept into a working variant faster than before, and — where it is wired into tools — chain steps together with less human babysitting between them. This is the shift that most directly compresses attacker tempo: the glue work between stages, historically slow because it needed a human, gets automated.

Obfuscation and polymorphism

The same generative capacity that writes a lure can rewrite a payload, mutate an implant's surface, and produce enough variants to defeat signature-only detection. Content-based indicators — hashes, exact strings, static YARA on a known sample — lose durability against an adversary who can regenerate the artefact on demand.

And the limits, which matter

Here is where the honest accounting pays off. Frontier AI makes the attacker faster and broader; it does not repeal physics. Two constraints survive intact:

First, the attacker still needs access. A perfectly-worded lure still has to land on someone who clicks; a beautifully-triaged exploit still needs a reachable, vulnerable target. Automation multiplies attempts, but every attempt still terminates in a real action against a real system.

Second, and decisively, every one of those actions still leaves telemetry. An automated recon sweep is still a burst of connections. A machine-generated lure still transits a mail gateway. An agentically-chained lateral move still authenticates, still touches hosts, still crosses trust boundaries. The adversary can generate infinite variants of an artefact, but they cannot generate an intrusion that leaves no trace of behaviour. The defence therefore has to move its centre of gravity off the artefact — which is now cheap to mutate — and onto behaviour and relationships, which are not.

Why "more AI on the console" isn't automatically the answer

The reflexive response to an AI-enabled attacker is an AI-enabled defender: bolt a language model onto the SOC console, let it summarise alerts and suggest actions, call it a copilot, ship it. This is where a great deal of security spend is going, and a great deal of it will be wasted, because bolting a fluent model onto an ungrounded workflow reproduces every failure mode of the model at the speed and scale of the SOC.

Hallucinated entities

A model asked to reason about an environment it cannot actually see will confidently invent the parts it lacks. It will reference a host that does not exist, attribute an alert to a CVE that does not apply, or assert a lateral path through an edge that was never in the data. In a SOC, a fluent wrong answer is worse than a blank one, because it is more likely to be actioned. If the assistant cannot tie every claim to a real entity, its fluency is a liability.

Unauditable reasoning

When the assistant reaches a verdict, can you reconstruct why? If the answer is "it said so," the SOC has introduced an actor it cannot govern into the middle of its most consequential decisions. Regulators, incident retrospectives, and your own analysts will all eventually ask the same question — show me the trace — and "the model was confident" is not an answer that survives it.

Automating the wrong thing

Alert-fatigue automation is a real and worthy goal, but automation applied to a flawed judgement doesn't reduce fatigue; it manufactures consequences faster. An assistant that auto-closes alerts on a shaky basis simply moves the analyst's burden from "triage the queue" to "audit the auto-closures," which is worse, because now the queue looks clean while incidents slip through it.

Prompt injection turning your assistant against you

The failure mode with no analogue in the pre-AI SOC: the defensive assistant reads attacker-controlled content as part of its normal job — an email body, a log line, a filename, a ticket comment — and that content contains instructions. A model that does not sharply distinguish data from instruction can be steered to ignore an alert, exfiltrate context, or invoke a tool the attacker chose. The assistant you deployed to defend the estate becomes an actor inside it, taking direction from outside it. We return to this in section 6, because it reframes the whole design problem.

The four properties a defensive AI must have to win

The through-line of the failures above is that they are all failures of discipline, not of capability. A more capable model does not fix a hallucinated host, an unauditable verdict, an over-eager auto-closure, or a susceptible-to-injection prompt. Those are fixed by four properties, each of which has to be built into the platform rather than prompted into the model.

(a) Grounding — answers tied to real graph edges

Every claim the defensive AI makes must resolve to a real node or edge in the environment's graph. Not "a host that is probably named this" but this host, with these observed connections, reachable via these edges. When the answer isn't in the graph, the honest output is "not found," not a plausible fabrication. This is precisely the discipline behind Netgraph's graph-grounded retrieval: the assistant's answers are anchored in real nodes and edges from the live property graph, so an invented host or an inapplicable CVE has nowhere to come from. Grounding is what turns fluency from a liability back into an asset.

(b) Auditability — govern your defenders too

If you are going to put an autonomous agent in the loop, you must be able to inspect exactly what it did: the prompt it received, the tools it called, the data those tools touched, and the disposition it reached. Netgraph treats its own agents as first-class subjects of monitoring through AI LLM Observability — a full prompt-and-tool trace of the platform's own agents. The principle is uncomfortable but correct: you must govern your defenders with the same rigour you apply to your adversaries, because an unobserved defensive agent is just an insider you happen to trust.

(c) Human-in-the-loop on consequences — graduated autonomy

Reading, correlating, and enriching can run wide open at machine speed; those actions are reversible. Consequential actions — isolating a host, disabling an account, pushing a block to a firewall — must pass through a human. Netgraph's eight-agent SOC is built around exactly this graduated model, with a durable human-in-the-loop approval gate in front of every action that changes the world. Approvals persist; an approval re-invokes the precise tool call that was proposed, so what the human authorised is byte-for-byte what runs. Autonomy is a dial, not a switch, and the dial is set per action-class by consequence and reversibility.

(d) Tempo — autonomous triage of every alert

None of the above matters if the defence is slower than the attack. Grounding, auditability, and human gates are only affordable if the volume they sit on top of has already been reduced to what humans should actually see. Netgraph's central, source-attributed alerts feed an autonomous L1 triage that works every new alert across every active tenant in near-real-time — machine-speed on the reversible, high-volume work, so human attention is reserved for the irreversible, low-volume decisions. Meanwhile UEBA models watch for the behaviour shifts that give an automated intrusion away — the machine-speed change in a user or entity's pattern that a signature would never catch. Tempo is what makes discipline sustainable.

The comparison, laid out

The three archetypes — a frontier attacker, an ungrounded defensive AI, and a graph-grounded defence — differ less in raw model capability than in the properties around the model. The table makes the differences explicit.

Dimension	Frontier attacker (GPT-plus archetype)	Ungrounded defensive AI	Mythos-class graph-grounded defense
Source of truth	Whatever it can observe or infer; free to guess, cost of error is low	Model priors + prompt context; invents the parts it cannot see	The live property graph; every claim resolves to a real node/edge or returns "not found"
Speed	Machine speed across many targets in parallel	Fast, but fast at producing unverified output	Machine-speed triage of every alert; consequential steps deliberately gated
Auditability	None owed to anyone; opacity is an asset	Poor — verdicts arrive without a reconstructable trace	Full prompt-and-tool trace of every agent action (LLM Observability)
Failure mode	Wasted attempt; try again for near-zero marginal cost	Confident wrong action at SOC scale; clean-looking queue hiding misses	Honest "not found" / escalate-to-human; failures are visible and bounded
Human oversight	Operator optional and increasingly removed from the loop	Often bypassed in the name of reducing fatigue	Graduated autonomy; durable approval gate on every consequential action
Telemetry left behind	Unavoidable — every real action emits behaviour and relationships	Sees artefacts, misses the behavioural/graph signal	Centres on behaviour + graph edges, precisely where the attacker cannot hide
Resistance to prompt injection	N/A — injection is a technique it wields, not a risk it carries	High exposure; treats attacker-controlled content as instruction	Shadow-AI inventory + prompt-injection detection + full observability as controls

The pattern in the right-hand column is not "a better model." It is the same class of model, wrapped in properties that convert its fluency into something a SOC can actually trust with consequences. The middle column — the ungrounded copilot — is in several rows worse than no AI at all, because it adds speed and confidence to an ability that was never verified.

Prompt injection as the new insider threat

Return to the failure mode with no pre-AI analogue. The moment a defensive AI reads attacker-influenced content — and in a SOC, reading attacker-influenced content is the entire job — the assistant becomes an attack surface. Prompt injection is best understood not as a prompt-engineering curiosity but as an insider-threat problem: a trusted actor inside your perimeter, with access to your tools, that can be given instructions by someone outside it.

Framed that way, the controls are the same controls you would apply to any insider risk, adapted to AI:

• Know what agents exist. A shadow-AI inventory — one of Netgraph's endpoint skills — enumerates the AI tools and agents actually running across the estate, including the ones nobody registered. You cannot govern an assistant you don't know is there.
• Detect the manipulation. Prompt-injection detection at the endpoint watches for the tell-tale patterns of content trying to hijack a model's instructions, and flags them as the adversarial input they are.
• Observe every action. AI LLM Observability means that if an agent is steered off-task, the deviation is visible in its trace — a tool it should not have called, a graph region it should not have touched, a disposition that does not match the evidence. Observability turns a silent compromise into a detectable one.

Concretely, every agent action produces an observability record. An illustrative one — schematic, not a real capture — looks like this:

# AI LLM Observability trace record (illustrative — not a real capture)

trace_id            : obs-2026-07-24-4f1a9c
agent               : soc.l1_triage           # eight-agent SOC, L1 autopilot
tenant              : acme-eu
input_source        : alert#A-88421 (source: EDR)  # source-attributed alert
prompt_sha256       : 9d0c…e2b7               # hash, not the raw prompt
graph_edges_touched : [Host:web-07]-AUTH_AS->[Id:svc-deploy],
                       [Id:svc-deploy]-CAN_ACCESS->[DB:orders-prod]
tools_called        : [ graph.reachability, ueba.entity_risk,
                        tip.indicator_match ]
injection_check     : PASS   # prompt-injection detector, no hijack pattern
grounding           : 3/3 claims resolved to live nodes; 0 invented
verdict             : suspicious
autonomy            : reversible-only         # no world-changing action taken
hitl_disposition    : ESCALATED_TO_L2 (approval-gated action queued)
approver            : pending — analyst j.rao

The point of the record is not any single field. It is that the whole thing exists, is retained, and is queryable — so that "why did the AI do that?" has a mechanical answer, the grounding is verifiable after the fact, and an injection attempt has a place it would have shown up. An assistant without a record like this is not defensible in the ordinary sense of the word.

The durable investment thesis

The strongest temptation in this market is to buy the newest model, because the newest model is genuinely more capable than the last one and will be less capable than the next. That is exactly why capability is the wrong thing to anchor on. Capability churns monthly. The GPT-plus archetype your adversary wields this quarter will be superseded next quarter, and so will the Mythos-class tier you defend with. Anything you build that depends on which model is inside it has a shelf life measured in weeks.

What does not churn are the invariants: grounding (answers tied to real graph edges), auditability (a full trace of every agent action), human oversight on consequences (graduated autonomy with a durable approval gate), and unified telemetry that keeps the defence centred on behaviour and relationships rather than mutable artefacts. These are architectural commitments, not model choices. Swap the model underneath and they still hold. They are the parts of the system that survive the next release, and therefore the parts worth investing in.

The corollary is a purchasing discipline. When evaluating a defensive AI, the productive questions are not "which model, how big, what benchmark," but: can it prove every claim against my real environment; can I reconstruct every action it took; can I set where the human gate falls; and does it keep working when the model behind it is replaced? A vendor who leads with the model is selling the perishable part. A platform that leads with the four properties is selling the part that lasts.

About this analysis

Authored by Autocops Desk. "Mythos-class" and "GPT-plus" are generic capability archetypes defined in the text for the purpose of the argument; they are not references to specific vendor products, benchmarks, or release dates, and no factual claims about any commercial model are made or implied. Model capabilities move on a monthly cadence — the properties this piece argues for are chosen precisely because they do not.

As one head of detection engineering at a large enterprise put it to us: "We stopped asking whether the assistant was smart and started asking whether we could prove what it did. The day we could answer that, it stopped being a risk and started being a colleague." For related reading see frontier AI threats and visibility through Netgraph, the Agentic AI SOC and UEBA solution pages, and the closed-loop detection engineering whitepaper for how authored detections are validated against real telemetry rather than assumed to work.