The Linux Foundation rolled out DNS-AID this week, a protocol that lets AI agents publish, discover, and verify each other through plain old DNS records. NVIDIA dumped a batch of open-source “physical AI” toolkits the same morning. CrowdStrike scaled AI-native agents across Falcon Exposure Management. Three announcements, one Monday, and nowhere in any of them did anyone explain what happens when an attacker controls one of those DNS records.

This is the part of cybersecurity nobody wants to slow down for. Autonomous agents are getting their own identity layer, their own discovery mechanism, and their own deployment automation, and the security architecture for any of it remains an exercise left to the reader. The pattern is familiar. It was the same with cloud, with containers, with SaaS. The infrastructure ships, the policies arrive eighteen months later, and the breach reports show up six months after that.

The week the agents got their own internet

DNS-AID is genuinely clever. It uses DNS, the same address lookup system that has steered traffic for thirty-some years, as a vendor-neutral directory where AI agents and Model Context Protocol servers can announce themselves and verify each other. If you want a global way for an agent to say “I am the procurement agent for example.com, here is my public key, here is what I do,” DNS is a reasonable place to put it.

The problem is everything DNS already drags along with it. Cache poisoning. Patchy DNSSEC adoption. Registrar account takeovers. Subdomain takeover via abandoned cloud records. The new protocol inherits the weak parts of the old one, and the new things that depend on it are not browsers waiting on user clicks. They are autonomous processes acting at machine speed, often with credentials that touch production systems.

Pair that with CrowdStrike rolling agent-native components into Falcon and NVIDIA open-sourcing a batch of skills that let agents drive robots, vehicles, and digital twins. The trend is consistent. The infrastructure for autonomous, networked, multi-vendor agent activity is shipping fast. The defensive guidance, predictably, is not.

Wait, who signs the DNS records?

Ask yourself which team in your org owns DNS today. In a lot of shops, it’s a small ops group, sometimes a single person, sometimes a registrar account that hasn’t been audited since the company changed names. Now ask which team will own the TXT and SRV records that publish your AI agents’ identities, capabilities, and endpoints. The answer in most orgs is nobody, because the conversation hasn’t happened.

That gap is where things go wrong. Threat detection on DNS changes is rare outside of very mature SOCs. Brute-force protection on registrar logins is inconsistent. Multi-factor on DNS providers is uneven, even though a takeover of those records lets an attacker stand up a malicious agent that downstream agents will treat as authoritative. The blast radius on that is hard to overstate when the consumer of the record is a non-human actor that won’t pause to think “huh, that’s weird.”

The same week DNS-AID was announced, Palo Alto’s GlobalProtect bypass (CVE-2026-0257) was being actively exploited via forged cookies that the appliance accepted without a real session. Different protocol, same lesson. When the verifier shortcuts its job, you get authentication theater. AI agent identity that leans on DNS without strong cryptographic verification and registrar hardening will end up in the same place.

What to actually do this quarter

You don’t need to wait for vendor guidance to get started. Most of the controls here are things mature security programs already know how to do; they just need to be aimed at a new target. Treat agent-to-agent traffic, agent identity records, and the agent control plane as Tier 0 surface and work backwards from there.

A practical short list:

• Inventory the agents. Every AI agent your org runs, hosts, or consumes from a vendor. Who owns it, what data it touches, what credentials it holds, and what it’s allowed to call. If you can’t list them, you can’t protect them.
• Lock down DNS like it’s a domain controller. Registrar MFA with hardware keys. Alerting on every record change. DNSSEC where you can, monitored where you can’t. Quarterly review of who has write access. Pretend the records are root passwords, because functionally they will be.
• Baseline agent egress. Agents will talk to each other and to model APIs. Capture first-seen destinations, unusual frequency, and large outbound payloads. The signature that an agent has been hijacked is almost always going to be behavioral, not a known IOC.
• Apply brute-force controls everywhere an agent authenticates. Agent endpoints, MCP servers, model APIs with API keys, internal admin consoles. Failed-auth velocity alerts catch a lot of stupid attacks cheaply.
• Segment the agent control plane. Asimily’s news this week was about automated network policy from device risk, which is the same problem at a different layer. East-west segmentation between agents, the systems they call, and the rest of your network limits the damage when one is compromised.
• Tier and short-lifetime agent credentials. No static API keys with broad scope. Short-lived tokens, scoped per task, rotated automatically. Treat any long-lived agent credential as a finding.
• Rehearse a compromised-agent IR playbook. What do you do when the procurement agent starts sending unusual purchase orders at 3am? Who can kill it? Who restores the verification chain? Walk through it now while it’s hypothetical.

None of this requires a specific product. It’s defense in depth applied to a new tier of the stack. Firewall rules, identity hygiene, threat detection, incident response. Same disciplines, new target.

The boring part everyone will skip

Two other stories from Monday are worth pairing here because they show how this fails in practice. Avani Desai at Schellman talked about the gap between what organizations think their data discovery scans show and what’s actually sitting in abandoned cloud storage and post-merger duplicates. And EU teams talked about buckling under NIS2 and DORA compliance load while trying to figure out what AI even means for their risk register.

The thread is governance debt. The orgs that don’t know where their data lives, that can’t keep up with current frameworks, that don’t have headcount for the controls they have today, are about to add a layer of autonomous agents with their own identity protocol and their own external dependencies. That layer will sit on top of every governance gap already there. It will also call into every system that hasn’t been properly inventoried.

The honest answer for most security leaders is to slow the AI agent rollout in their environment until basic data discovery, identity hygiene, and segmentation are real. That is not the answer the AI product team wants. It is the one that prevents the breach report. Cyber security work in 2026 is going to involve a lot more “no, not yet” than people expect, and the leaders who can say it cleanly will avoid more incidents than the ones who buy the agent-native bolt-on.

The agents are getting an address book this year. Make sure yours has a phone number that doesn’t go to a hijacked DNS record.

Sources

• DNS-AID lets AI agents find and verify each other through DNS
• NVIDIA goes open source with a big batch of physical AI agent tools
• CrowdStrike Scales AI-Native Agents Across Falcon Exposure Management with NVIDIA
• Asimily turns device risk into automated network policy
• Data discovery gaps that catch enterprises off guard
• EU organizations buckle under rising compliance pressure
• Hackers are exploiting Palo Alto GlobalProtect VPN authentication bypass (CVE-2026-0257)