The Engineer

The Core Problem: Backdoors That Survive Remediation

Palo Alto's Unit 42 confirmed that attackers exploiting Ivanti EPMM (Endpoint Manager Mobile) zero-days are deploying persistent backdoors that remain functional after patching. This is not the standard 'patch and move on' scenario. Your incident response playbook of 'apply patch → verify patch → close ticket' leaves you compromised with this one.

If you can't terraform destroy && terraform apply your MDM infrastructure, you're going to have a very bad week when the next zero-day hits.

Why This Is Architecturally Different

MDM servers occupy a uniquely privileged position in your infrastructure — they push configurations, certificates, and policies to every managed device in your fleet. A compromised MDM server isn't 'one server got popped.' It's an attacker with the ability to push malicious profiles to every phone, tablet, and laptop you manage. The persistence mechanism survives patching because it's not exploiting the vulnerability itself — it's using the initial access to install independent backdoor infrastructure that lives outside the patched code path.

The Broader Pattern: Mutable Management Planes Are a Liability

This joins a pattern visible across multiple intelligence streams today. MDM servers, SD-WAN controllers, CI/CD systems — anything that has privileged access to your fleet and runs as a mutable, long-lived server is a high-value target where traditional patching is insufficient. The architectural response is to make these systems immutable and rebuildable from infrastructure-as-code. If your MDM infrastructure can't be torn down and rebuilt from a known-good state in hours, you have an implicit assumption that it will never be deeply compromised — and that assumption is now empirically false.

Immediate Response If You Run Ivanti EPMM

1. Assume compromise — don't wait for IOC confirmation
2. Engage forensic analysis of MDM servers, focusing on persistence mechanisms outside the patched vulnerability's code path
3. Hunt for unauthorized profiles, certificates, or configuration changes pushed to managed devices
4. Plan a full rebuild from known-good images, not an in-place remediation

The Shift: From Encryption Events to Parasitic Residency

Three independent intelligence streams converge on the same conclusion: ransomware operators are abandoning loud encryption for quiet, long-term data exfiltration. The CrowdStrike 2026 Global Threat Report data — 82% malware-free detections and 29-minute average breakout time (down from 98 minutes in 2021) — isn't just a speed improvement. It reflects a fundamental change in attacker methodology. They're logging in with stolen credentials, using built-in OS tools (PowerShell, WMI, RDP, SSH), and establishing persistence through identity systems rather than dropping binaries.

The emergence of Steaelite RAT — a SaaS offering that bundles data exfiltration and ransomware management into a single platform — commoditizes this approach. The barrier to running a 'parasitic' campaign is dropping fast.

Your Detection Architecture Is Optimized for the Wrong Threat

If your detection pipeline relies on signature-based tools (AV, YARA rules, behavioral EDR focused on process trees), you're covering less than 20% of current attacks. The 27-second fastest breakout time means automated exploitation is real, and your incident response playbook that assumes human analyst triage within an hour is fundamentally broken.

Attackers are using your own admin tools against you. Your EDR is optimized for a world where attackers drop binaries — but the modern attacker logs in with stolen creds and uses PowerShell.

What Identity-Layer Detection Actually Requires

The detection shift isn't incremental — it's architectural. You need to correlate authentication events across your IdP, cloud providers, and internal services in near-real-time. Specifically:

• OAuth app grants — audit all grants created in the last 90 days; flag any that don't map to known workflows
• Service account creation — every service account needs a documented owner and purpose
• Scheduled task/cron registrations — these are persistence mechanisms, treat them as security telemetry
• API key rotation — enforce rotation schedules; stale keys are attacker persistence
• Impossible travel and anomalous access patterns — if your SIEM ingests auth logs on a 15-minute batch cycle, you're past the breakout window before you see the first alert

The SaaS C2 Dimension

The GRIDTIDE campaign (covered previously) demonstrated that C2 traffic hiding inside legitimate SaaS API calls can evade detection for years. Combined with the identity-layer persistence shift, the picture is clear: attackers establish persistence via identity systems and communicate via your trusted SaaS traffic. Your firewall sees traffic to sheets.googleapis.com and waves it through. The only detection path is behavioral analysis at the application layer — monitoring API audit logs for anomalous patterns, correlating service account behavior with expected baselines.

The Bottleneck Has Shifted

Five independent sources this cycle converge on the same message: the hard problem with AI agents is no longer building them — it's deploying, securing, and measuring them in production. CB Insights identifies three specific infrastructure gaps: performance visibility, context management, and cost attribution. Notion is shipping 'governed AI agents' with governance as a first-class product feature. And multiple security-focused sources flag that agents introduce attack surfaces that traditional AppSec tooling doesn't cover.

Gap 1: Security — Agents Are Untrusted Processes

The evidence is mounting that AI agents must be treated as untrusted processes, not extensions of the developer who launched them. Multiple sources confirm that prompt injection can cause agents to exfiltrate SSH keys, leak OAuth tokens (OpenClaw exposed 21,000 instances in two weeks, covered previously), and execute attacker-controlled tool calls. The architectural response:

• Sandboxed execution — agents run in containers with no access to credential stores, SSH keys, or production secrets
• Action-level audit logging — every tool call, every parameter, every side effect, traceable to the triggering invocation
• Runtime policy enforcement — 'this agent can read from these tables but never write' enforced at the execution layer, not the prompt layer
• Human-in-the-loop gates for high-risk actions (database writes, external API calls, file system modifications)

Gap 2: Observability — Can You Trace a Single Invocation?

The diagnostic question: can you trace a single agent invocation from trigger through every tool call, LLM request, and side effect to final outcome, with cost attribution at each step? If not, you're in the 'we shipped microservices but don't have distributed tracing yet' phase. Perplexity's 19-model agentic orchestration system — which they canceled their own press demo for because they found flaws — illustrates the debugging challenge. When Agent A spawns Agent B which calls Model 7, how do you diagnose failures? The patterns from event sourcing and saga orchestration apply here, but the abstractions are different: token budgets instead of memory limits, summarization instead of compression, retrieval instead of cache lookup.

Gap 3: Cost Attribution — Your CFO Will Ask

If you can't show concrete numbers on what your agents cost to run and what value they produce, you're one budget cycle away from defunding. Start with per-invocation cost tracking (LLM API costs + compute + external API costs), task completion rates, error/fallback rates, and estimated human-equivalent time. Instrument this from day one on new agent projects — retrofitting is painful because you need to reconstruct cost models for behaviors you didn't log.

Notion's Signal: Governance as Product Feature

Notion framing agents as 'governed AI teammates' is a market signal worth internalizing. Governance primitives — permission scoping, audit trails, human approval gates — are becoming table stakes, not differentiators. If you're building agent orchestration, design these into the execution model itself, not as a logging wrapper bolted on later. Think RBAC for agent capabilities, not just user permissions.

The Benchmark Legitimacy Crisis

Three signals from different corners of the AI ecosystem point to the same conclusion: public benchmarks are no longer reliable for production model selection. OpenAI is pushing to retire SWE-bench, the primary coding benchmark the industry uses to compare models. Formal benchmarks like MMLU, HumanEval, and GPQA are saturating. And AI enthusiasts are turning to personally devised tests — otters, Minesweeper, Will Smith eating spaghetti — because formal evals don't capture real capability differences. As Terence Tao noted: 'AI tools are like taking a helicopter to drop you off. You miss all the benefits of the journey itself.'

ARQ: A Structured Alternative to Chain-of-Thought

The most technically interesting evaluation-adjacent signal is Attentive Reasoning Queries (ARQ) from the Parlant framework (18k GitHub stars). ARQ replaces free-form Chain-of-Thought with domain-specific questions encoded as JSON schema, injected at three pipeline stages: guideline selection, tool calling, and message generation. Results: 90.2% instruction adherence vs. CoT's 86.1% on multi-turn conversations.

Important caveat: this was evaluated on only 87 test scenarios — far too small for production confidence. But the pattern itself — structured reasoning injection at multiple pipeline stages — is worth stealing even if you never touch Parlant. If you're fighting prompt drift in production agents, prototype this approach.

What To Do Instead of Trusting Leaderboards

The practical response is straightforward but requires investment:

1. Take 50 real PRs, 50 real bugs, 50 real code review comments from your actual codebase
2. Build a reproducible eval harness that tests candidate models against these real-world scenarios
3. Measure what matters for your use case: instruction adherence, hallucination rate, false positive rate on security findings, cost per task
4. Re-run the eval every time you consider switching models or providers

The leaderboard winner may not be your winner. A week of building internal benchmarks pays for itself every time you need to evaluate a new model.

Cotool Research's benchmarking of LLMs on defensive security tasks found 'large reliability gaps across models on multi-step investigations' with 'failure modes not appearing in generic benchmarks.' The most expensive model isn't necessarily the best for your specific workload — another reason domain-specific evaluation is non-negotiable.