DEF CON 34 — Part 9 of 13

Why the systems protecting us deserve the most hostile threat model

By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.

Imagine an attacker who never compromises your SOC.

They do not exploit the SIEM.

They do not steal the SOC analyst’s credentials.

They do not compromise the EDR console.

They do not deploy malware onto the security infrastructure.

Instead, they write something into a log.

The log is collected exactly as designed.

The SIEM processes it exactly as designed.

A security agent reads it exactly as designed.

And the agent reaches the conclusion the attacker wanted.

At DEF CON 34, this stopped being a hypothetical.

John Seymour of Salesforce presented research with a title that should make every CISO running an AI-enabled SOC uncomfortable:

Poisoning the SOC: Prompt Injection via Ingested Telemetry.

His starting point was simple.

Security organizations are connecting LLM agents to alert triage, investigation, threat hunting and increasingly autonomous response.

But those agents consume logs.

And significant parts of those logs are created — directly or indirectly — by attackers.

Seymour’s research examined which attacker-controlled fields survive ingestion into a production SIEM and whether malicious content placed inside those fields could influence agents operating above the telemetry pipeline.

The demonstrated consequences included suppressed detections, decoy investigations, denial of analysis and attacker-directed tool calls. (⁠AI Village)

The attacker had discovered something important.

They did not necessarily have to compromise the security system.

They could potentially weaponize the information the security system was designed to consume.

That distinction matters.

Because it exposes a new property of modern security infrastructure:

The defender is becoming an interpreter of hostile input — while simultaneously acquiring authority to act on the enterprise.

And that combination may create one of the most consequential new attack surfaces inside modern organizations.

The SOC Has Always Consumed Attacker-Controlled Data

This problem did not begin with artificial intelligence.

SOC infrastructure has always processed information influenced by adversaries.

Consider what appears in enterprise telemetry:

• URLs.
• HTTP headers.
• User agents.
• DNS queries.
• File names.
• Email subjects.
• Process command lines.
• PowerShell arguments.
• API requests.
• Repository metadata.
• Error messages.
• Application logs.
• Cloud events.
• Malware metadata.

The attacker often controls at least part of these values.

Historically, that was manageable because most security infrastructure treated them as data.

A SIEM indexed them.

A detection rule compared them.

An analyst inspected them.

But an agentic security system does something fundamentally different.

It interprets them.

It reasons about them.

It correlates them with other information.

It decides what they mean.

And increasingly, it may decide what should happen next.

The security pipeline therefore changes from:

Attacker Activity
↓
Telemetry
↓
Detection
↓
Human Analyst
into something closer to:
Attacker Activity
↓
Attacker-Influenced Telemetry
↓
AI Interpretation
↓
Reasoning
↓
Tool Selection
↓
Privileged Action

The data has not become executable code in the traditional sense.

But it may now influence something that can execute.

This is the same transition discussed earlier in this DEF CON 34 series.

Data → Interpretation → Authority → Execution

I called this Semantic Execution in Part 1.

Inside the SOC, its implications become particularly uncomfortable.

Because the interpreter is part of the defensive control plane.

What If the Evidence Contains Instructions?

Another DEF CON 34 presentation made the problem even clearer.

Sophena Wilson of Microsoft presented:

The Weight of Evidence: How an Agentic SOC Analyst Earns Your Trust.

Wilson examined a representative agentic SOC analyst performing triage.

Such an agent reads alerts.

It gathers evidence.

It evaluates context.

Eventually it helps determine whether an incident should be escalated or closed.

But the research identifies a structural problem:

The agent cannot reliably distinguish between evidence it is supposed to interpret and instructions contained inside that evidence.

Wilson manipulated one artifact at a time.

The important result was not that the system crashed.

It was not that the agent produced obviously absurd output.

It was more dangerous.

A single attacker-controlled field could change an autonomous verdict while the agent’s reasoning remained coherent.

The failure could therefore look like successful security analysis. (⁠AI Village)

That suggests an uncomfortable principle:

The most dangerous attack against an agentic SOC may not make the SOC fail. It may make the SOC confidently reach the wrong conclusion.

Consider the difference.

A broken SIEM is visible.

A crashed security agent is visible.

A disconnected EDR platform is visible.

But an autonomous analyst that quietly closes the wrong incident?

That can look like normal operation.

From Defense Evasion to Defense Manipulation

Security teams have spent decades thinking about defense evasion.

Attackers disable antivirus.

They terminate EDR processes.

They delete logs.

They manipulate timestamps.

They disable monitoring.

They attempt to become invisible.

Agentic security introduces another possibility.

The attacker may no longer need to hide from the defender.

The attacker may attempt to influence what the defender believes.

That represents an important transition:

Defense Evasion

→ avoid being observed.

Defense Manipulation

→ influence how observations are interpreted.

The second can be much more subtle.

If an attacker can influence the evidence entering an autonomous security workflow, they may potentially influence:

what gets investigated,

what gets ignored,

which system is considered suspicious,

which identity is blamed,

which tool gets called,

or which remediation action is initiated.

The attack surface has moved from the detection mechanism toward the reasoning chain behind the detection.

DEF CON 34 Showed the Same Problem in Security Scanners

The problem does not stop at the SOC.

At DEF CON 34, another talk approached essentially the same architectural weakness from the opposite direction.

Bait the Bot: Hacking Back Autonomous AI Vulnerability Scanners examined autonomous LLM-based vulnerability scanners.

The structural weakness is straightforward.

A scanner must consume the content of the system it scans.

But if that scanner uses an LLM to interpret the content, the target itself may be able to influence the scanner through prompt injection.

The research explored identifying autonomous scanners and using adversarial instructions to confuse, redirect, exhaust or neutralize them without exploiting a traditional software vulnerability. (⁠LinkedIn)

This produces a fascinating inversion.

Traditionally:

Scanner → examines → Target

Now potentially:

Target → influences → Scanner

The security tool becomes part of the attack interaction.

The scanner is no longer merely observing hostile infrastructure.

It is interpreting attacker-controlled content.

That distinction will become increasingly important as vulnerability management, penetration testing and security validation become agentic.

The Scanner Is Becoming an Actor

DEF CON 34’s Demo Labs showed another side of this evolution.

MCP X-Ray was presented as an open-source security scanner for MCP servers, Skills and the emerging AI plugin supply chain.

Its architecture combines static configuration analysis, repository auditing, semantic analysis and active penetration testing.

The interesting word is:

active.

The scanner can actually invoke tools using adversarial inputs and feed findings into environments such as GitHub, VS Code and CI gates. (⁠DEF CON 34)

This is useful security engineering.

But architecturally it demonstrates something larger.

The scanner itself is evolving.

Yesterday:

Scanner → Read → Report

Increasingly:

Scanner → Interpret → Interact → Invoke → Report

And eventually:

Scanner → Interpret → Decide → Invoke → Remediate

At that point, a scanner is no longer simply an observer.

It becomes an actor inside the system it protects.

That means its threat model must change accordingly.

Hostile Artifacts Need Hostile Threat Models

Another DEF CON 34 Demo Lab makes the point even more strongly.

Nur Gucu demonstrated MalSkill Lab: Hands-On Natural Language Malware in AI Agent Orchestration Systems.

One attack hid a malicious natural-language instruction inside an otherwise legitimate Skill and used it to exfiltrate .envdata.

Another distributed the malicious behavior across five individually benign Skills.

No individual Skill contained the complete malicious behavior.

Only their orchestration produced the exfiltration path.

The DEF CON description summarizes the lesson perfectly:

“No single skill is malicious. The composition is the weapon.” (⁠DEF CON 34)

That sentence could almost serve as the thesis of this entire series.

But it also creates a direct problem for security infrastructure.

How does a security scanner analyze something whose malicious property exists only through composition?

The scanner cannot simply ask:

Is this file malicious?

It has to understand:

What happens when this artifact interacts with another artifact?

What authority will the consuming agent possess?

Which tools become reachable?

Which identities are inherited?

Which information can leave?

This turns security scanning itself into graph analysis.

And potentially into execution.

The Artifact Can Attack the Analyzer

We therefore need to change one of the most basic assumptions in security tooling.

A security scanner processes suspicious objects.

But the suspicious object may itself be designed to attack the scanner.

That concept is not new.

Malware-analysis environments have understood it for years.

Parsers can contain vulnerabilities.

Sandboxes can be detected.

Analysis tools can be attacked.

What changes with AI is the mechanism.

The artifact may not require memory corruption.

It may not require a parser vulnerability.

It may not require remote code execution.

It may only need to influence the semantic interpretation performed by the analyzer.

That gives us another DEF CON 34 attack pattern:

Hostile Artifact
↓
Security Analyzer
↓
Semantic Interpretation
↓
Tool Invocation
↓
Security Identity
↓
Enterprise Resource

The analyzer supplied the execution capability itself.

CI/CD Shows Why the Relationships Matter

DEF CON 34’s Trajan: Cross-Platform CI/CD Security Scanner adds another important dimension.

Praetorian’s researchers describe CI/CD pipelines as among the fastest paths they have repeatedly found toward enterprise compromise.

A misconfigured workflow or overprivileged service connection can expose credentials, cloud access or code execution on internal infrastructure.

Trajan therefore models pipeline configurations as graphs — identifying triggers, gates and dangerous relationships and correlating them into multi-step attack chains across GitHub Actions, GitLab CI and Azure DevOps. (⁠DEF CON 34)

This matters beyond CI/CD.

Because it illustrates exactly what security infrastructure increasingly needs to understand:

relationships rather than components.

A repository may not be dangerous.

A workflow may not be dangerous.

A service identity may not be dangerous.

A cloud role may not be dangerous.

But:

Repository
↓
Workflow
↓
Service Connection
↓
Cloud Identity
↓
Production

may be extremely dangerous.

The vulnerability exists in the composition.

The Security Privilege Paradox

Now consider the enterprise security stack itself.

Security infrastructure often has extraordinary access.

Vulnerability scanners authenticate to servers.

CNAPP platforms enumerate cloud environments.

EDR platforms execute with deep endpoint privileges.

Identity security systems analyze directories and privileged accounts.

Code scanners inspect repositories.

Secrets scanners search for credentials.

SIEM platforms ingest telemetry from almost everywhere.

SOAR systems can perform actions across many of those environments.

Agentic SOC systems increasingly sit above them all.

This creates what I would call the:

Security Privilege Paradox

The better a security platform becomes at seeing and controlling the enterprise, the more strategically valuable compromising or manipulating that platform becomes.

That is not an argument against integration.

It is an argument for recognizing what security infrastructure has become.

Security platforms are increasingly authority infrastructure.

Visibility × Authority × Connectivity

A useful way for CISOs to evaluate these systems is across three dimensions.

Visibility

What can the system observe?

Endpoints?

Identities?

Cloud workloads?

Source code?

Credentials?

Network traffic?

Incident evidence?

Authority

What can it change?

Can it isolate?

Block?

Disable?

Delete?

Deploy?

Rotate?

Execute?

Connectivity

How many trust domains can it reach?

One environment?

Multiple clouds?

Production and development?

Subsidiaries?

CI/CD?

Identity infrastructure?

Thousands of endpoints?

The architectural risk rises dramatically when all three are high.

Conceptually:

Security Infrastructure Risk ∝ Visibility × Authority × Connectivity

This is not intended as a mathematical risk equation.

It is a way of recognizing concentration.

A platform with visibility but little authority may primarily expose information.

A platform with authority but limited connectivity may create localized damage.

A platform combining broad visibility, powerful authority and enterprise-wide connectivity can become something else entirely:

an enterprise control plane.

And AI Adds a Fourth Dimension

DEF CON 34 suggests that the model now needs another variable.

Interpretation.

The security system no longer simply observes and executes deterministic rules.

It interprets evidence.

Therefore:

Visibility
×
Interpretation
×
Authority
×
Connectivity

creates a qualitatively different security problem.

An attacker does not necessarily have to steal the platform’s authority.

They may attempt to manipulate the interpretation that causes that authority to be exercised.

That is what makes Poisoning the SOC and The Weight of Evidence so important.

They connect attacker-controlled information to trusted reasoning.

Once trusted reasoning connects to privileged tools, the attack chain is complete.

HOSTILE INPUT × TRUSTED INTERPRETATION × PRIVILEGED ACTION

That gives us perhaps the simplest model from DEF CON 34:

HOSTILE INPUT
×
TRUSTED INTERPRETATION
×
PRIVILEGED ACTION
=
SECURITY INFRASTRUCTURE AS ATTACK PATH

SOC agents,

vulnerability scanners,

code-security agents,

malware-analysis agents,

cloud-security platforms,

incident-response automation,

threat-intelligence agents,

CI/CD security tooling,

and autonomous penetration-testing systems.

The technologies differ.

The architectural weakness is the same.

Security Infrastructure Needs Tier-0 Thinking

Organizations normally reserve Tier-0 treatment for infrastructure such as:

identity systems,

privileged-access management,

certificate authorities,

key-management systems,

or core administrative environments.

The reason is simple.

Compromise of these systems can invalidate trust elsewhere.

Some security infrastructure now meets exactly the same criterion.

A useful test is:

If an attacker fully controlled or successfully manipulated this security system, could we still trust the systems it monitors or manages?

If the answer is no, that system deserves Tier-0 thinking.

Not necessarily the same technical implementation.

But the same architectural seriousness.

That can mean:

strong administrative isolation,

phishing-resistant privileged authentication,

dedicated administrative identities,

just-in-time access,

strict service-account scoping,

restricted egress,

sandboxed analysis workers,

independent audit logging,

separation between analysis and enforcement,

and independent monitoring of the security infrastructure itself.

Separate Observation From Enforcement

The most important architectural response may be to prevent one system from owning the entire decision chain.

Avoid:

Security Agent
↓
Reasoning
↓
Privileged Tool
↓
Production

Prefer:

Security Agent
↓
Proposed Action
↓
Independent Policy Decision
↓
Scoped Execution

The security agent may conclude:

Isolate endpoint X.

But an independent enforcement layer should determine:

Is endpoint X actually the affected asset?

Is autonomous isolation permitted for this asset class?

Does the evidence satisfy the required threshold?

Is the requested operation within policy?

What exact action will occur?

Can the agent modify the parameters after authorization?

Only then should execution occur.

This connects directly to Part 8 of this series.

Human approval alone is not enough.

And neither is agent reasoning.

Critical actions need independent transaction enforcement.

Security Tools Need Blast-Radius Budgets

CISOs should therefore introduce another concept:

Blast-Radius Budgeting

When integrating a security platform, do not ask only:

What permissions does the product require?

Ask:

What maximum blast radius are we willing to give this product if it becomes hostile?

Then design the integration backward.

Perhaps visibility can be enterprise-wide.

But write authority cannot.

Perhaps investigation can be autonomous.

But remediation cannot.

Perhaps the scanner can enumerate production.

But authenticated scanning credentials are temporary.

Perhaps a SOC agent can recommend identity suspension.

But another policy layer must authorize it.

This is least privilege applied not merely to identities, but to systems of delegated authority.

Assume the Security Vendor Is Compromised

There is one more scenario every CISO should model.

Tomorrow morning, one of your major security suppliers announces:

Assume our management infrastructure has been compromised and customer integrations may have been accessed.

Can you immediately identify:

every API token?

every OAuth grant?

every service principal?

every cloud role?

every agent?

every webhook?

every certificate?

every repository integration?

every remediation permission?

Can you revoke them?

Can you distinguish legitimate vendor activity from attacker activity performed through legitimate vendor infrastructure?

Can you continue security operations after disconnecting the supplier?

This is not ordinary vendor risk management.

It is trust-path recovery.

And it belongs in incident response.

Who Watches the Watchers?

There is an obvious final problem.

The SOC monitors the enterprise.

But who monitors the SOC?

Who detects:

a new security administrator,

a modified agent configuration,

an unexpected tool invocation,

a changed SOAR workflow,

an unusual scanner destination,

a new security-platform integration,

or an EDR console suddenly performing actions outside its normal behavioral pattern?

If the answer is:

the same security platform,

then the architecture contains circular trust.

Tier-0 security infrastructure requires independent observability.

The security platform itself must be treated as something that may eventually become the incident.

The CISO Takeaway

DEF CON 34 did not merely show that AI agents, security scanners or SOC platforms can contain vulnerabilities.

It revealed a deeper architectural problem.

Security infrastructure increasingly combines three properties that were historically separated:

It consumes hostile information.

It is trusted to interpret that information.

It possesses authority to act on the enterprise.

John Seymour showed how attacker-controlled telemetry can steer SOC agents.

Sophena Wilson showed how a single manipulated piece of evidence can change an autonomous SOC verdict while leaving the reasoning apparently coherent.

Research into autonomous vulnerability scanners showed that even the scanner itself can be influenced by the content it is inspecting.

MalSkill demonstrated that individually benign components can become malicious through orchestration.

MCP X-Ray showed why security testing increasingly requires active interaction with agent tools.

Trajan demonstrated why the real vulnerability may exist not inside one component but across the relationships connecting repositories, pipelines, identities and infrastructure. (⁠AI Village)

Together, they point toward a larger conclusion.

The security system itself is becoming part of the execution path.

That means CISOs must stop thinking about security infrastructure merely as controls surrounding the enterprise.

Some of these systems are becoming among the most privileged systems inside the enterprise.

We gave them visibility.

Then identities.

Then integrations.

Then automation.

Now we are giving them reasoning and agency.

That combination deserves the most hostile threat model we can give it.

Because the tools with the broadest visibility may increasingly possess the broadest blast radius.

And once a defensive system can interpret hostile input and exercise enterprise authority, compromising the defender may be more valuable than compromising the systems it was built to defend.

Core thesis:

Security infrastructure is becoming enterprise authority infrastructure. The moment a defensive system can turn attacker-controlled evidence into privileged action, the defender itself becomes part of the attack surface.

Next in the series: Part 10 — Below the EDR: The Security Layers We Forgot — why the next layer is even harder to see. What happens when the attacker moves below the operating system — into CPU behavior, memory controllers, firmware, SMM, PSP or BMC infrastructure?

And if compromise survives beneath the layer where EDR operates, does reimage and recover still mean recovery at all?

Publication Note & Disclaimer
This article provides security and governance analysis, not legal advice. Regulatory obligations must be assessed against the facts, jurisdictions, data types, and roles of the organizations involved.

This article reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.

For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.