This is not a panic blog.
Security has always been a cat-and-mouse game between attacker and defender. Reaper answered Creeper in 1972. VirusScan arrived in 1987. EDR, SIEM, CTI, and vulnerability management all emerged because defenders and attackers forever adapted to one another.
Mythos is the latest turn of that wheel. The wrinkle this time is speed. Ease of automation.
As of May 22, 2026, Mythos Preview has found what it estimates are 6,202 high- or critical-severity vulnerabilities across 1,000+ open-source projects. Less than 1% have been patched or have public disclosures.
An example: this FreeBSD NFS remote code execution flaw.
As for adversary usage of frontier models, Anthropic has also reported a large-scale espionage campaign where attackers used agentic AI to carry out major portions of the operation across dozens of targets.
AI is automating away repetitive work everywhere. Cybercrime is no different. Agents can handle reconnaissance, testing, reproduction, exploit development, infrastructure recycling, and operational follow-through.
Censys has always hung our hat on our superior speed, going back to our ASM announcement in 2019. The AI breakthroughs have been staggering since then – we never anticipated how prescient our desire was to build a real-time map of the entire public Internet.
Censys Attack Surface Management helps security teams understand what they expose. Censys Platform helps SOC, CTI, and detection engineering teams understand what adversaries expose.
In the Mythos era, both matter. Let’s talk about why, starting with exposures.
Exposure Management in the Mythos Era
Exposure management is the practice of continuously finding, validating, prioritizing, and reducing Internet-facing risk when AI can accelerate vulnerability discovery, exploit development, and attacker reconnaissance.
Same as it always was, just under a faster clock.
Why ASM Becomes the First Control Plane
Censys cannot protect against every path to compromise.
Social engineering exists. Identity attacks exist. Insider risk exists. Supply chain compromise exists. A user can still approve a bad OAuth grant, enter credentials into a fake login page, or run something they should not run.
But if an attacker, or an army of agents working for an attacker, wants to operate at scale, the public Internet is the lowest-lift place to start.
It is remote. It is parallelizable. It is measurable. It is full of services, ports, certificates, software, DNS records, cloud resources, admin panels, developer tools, forgotten test environments, and vulnerable systems waiting to be found.
That makes ASM the first control plane for Mythos-era exposure management.
Traditional disciplines (vulnerability management, cloud security, NDR alerts, etc.) still matter. But when the vulnerability is Internet-reachable, outside-in visibility becomes the first line of prioritization.
Censys ASM helps answer the questions that matter in that moment:
- What assets do we expose?
- Which services are reachable?
- Which ports are open?
- Which software, certificates, protocols, and web properties are present?
- Which vulnerabilities are associated with those services?
- Which exposures changed recently?
- Which risks should remediation teams handle first?
In an AI-speed vulnerability cycle, that context is not a luxury. It is how teams decide what to fix first.
The Exposure Problem AI Makes Impossible to Ignore
Most organizations do not have one clean, static attack surface.
There are mergers, subsidiaries, regional teams, contractor-managed infrastructure!
Such a complex and layered infrastructure is bound to have abandoned projects and experiments. Forgotten load balancers. Old DNS records. SaaS configuration buried in portals, each with a different solitary admin. Temporary GPU instances. Jupyter notebooks. AI demos.
A traditional inventory might know the approved assets. A cloud console might know what exists in one provider. A vulnerability scanner might know what it can reach on expected ports. A CMDB might know what someone remembered to register.
Attackers do not care about those boundaries. They care about what is reachable.
That is why Censys ASM continuously maps the public-facing attack surface. Teams need to see what the Internet sees, not just what their internal systems believe should exist.
If AI helps attackers test more hosts, more ports, more paths, more headers, more version combinations, more default panels, and more obscure service fingerprints, then the defender’s data has to keep up.
“AI will magically exploit every vuln” – no. It’s dumber than that: more automation creates more attempts. Brute force by intelligent, subject-authoritative bots.
Censys ASM: Comprehensive Coverage for AI-Speed
Censys ASM is built for the problem Mythos amplifies: discovering and prioritizing Internet-facing exposure before it becomes an incident.
If your ASM program only looks where you expect services to live, it will miss the places where real risk accumulates. AI tools and developer infrastructure often do not show up on a tidy list of standard ports. They show up wherever someone got a demo working, opened a port, pushed a test environment, or forgot to clean up.
Censys ASM helps teams discover assets and services across the public Internet, including non-standard ports and unexpected service locations. That matters when the riskiest exposure is not the corporate website. It might be an AI service, Jupyter notebook, model dashboard, admin panel, debug server, or forgotten development tool listening somewhere your normal controls do not inspect.
Playbook 1: Find What Others Miss Across All 65,535 Ports
A lot of exposure management failures begin with a vendor assumption:
“Nobody runs that there.”
Except – someone does!
AI and ML tools are a good example. Ollama, Jupyter, TensorBoard, MLflow, Spark, Ray, Xinference, local LLM UIs, GPU dashboards, and experimental model services can appear on non-standard ports. Some are intended for local development. Some are spun up for a week. Some are created by data science teams that move faster than security review. Some are forgotten after the demo.
That is exactly the kind of asset an attacker would rather find before you do.
A Mythos-era exposure management program should start with full-port visibility and searches for AI-adjacent services.
Example ASM QL patterns:
host.services.http.response.body: {Ollama, Xinference}
or web_entity.instances.http.response.body: {Ollama, Xinference}
or host.services.port: {11434, 8080, 7860}
or web_entity.instances.port: {11434, 8080, 7860}For broader AI and ML workflow detection:
host.services.port: {8888, 6006, 5000, 7077, 8080, 8265}
or host.services.software.product: {Jupyter, TensorBoard, MLflow, Spark, Ray}
or host.services.service_name: {Jupyter, TensorBoard, MLflow, Spark, Ray}
or web_entity.instances.port: {8888, 6006, 5000, 7077, 8080, 8265}
or web_entity.instances.software.product: {Jupyter, TensorBoard, MLflow, Spark, Ray}
or web_entity.instances.service_name: {Jupyter, TensorBoard, MLflow, Spark, Ray}The goal is not to declare every AI tool malicious.
The goal is to find Internet-facing AI infrastructure that security did not approve, does not monitor, or cannot explain.
That is the difference between “we have a policy” and “we know what is exposed.”
Playbook 2: Triage New Vulnerabilities During Resolution Hour
When a critical CVE is disclosed, most organizations enter some version of the same scramble.
In the Mythos era, that first hour matters more. Call it Resolution Hour.
The objective is not to fix everything in 60 minutes (wouldn’t that be nice). The objective is to resolve the most important uncertainties quickly.
A strong Resolution Hour workflow looks like this:
- Search ASM for affected software, products, services, ports, banners, web fingerprints, and vulnerability identifiers (using the Censys ARC rapid response queries).
- Prioritize assets exposed to the public Internet.
- Check whether Censys indicates active exploitation or other high-risk context.
- Segment findings by ownership, business unit, cloud provider, geography, or asset tag.
- Route the most urgent assets into remediation workflows.
- Set alerts so newly discovered exposure is not missed after the first search.
This is where Censys ASM and vulnerability management meet.
Vulnerability management teams have massive lists of theoretical risk. Censys ASM helps identify reachable risk. The intersection helps set priorities for the entire program.
Playbook 3: Hunt for Shadow AI and Exposed AI Services
Again, let’s use AI tools as an example. Businesses are urging their use faster than methodologies can be vetted.
Data scientists, engineers, analysts, and product teams are experimenting with AI tools recklessly to fulfil these mandates. Security doesn’t need to block all of that (arguably), but does need to know when it becomes an exposure.
Censys ASM helps teams identify AI-related cloud assets using provider metadata, tags, service fingerprints, and exposed ports.
Example ASM QL pattern for cloud-tagged AI experiments:
(
host.cloud: {aws, google, azure, "Amazon Aws", "Google Cloud", "Microsoft Azure", "Microsoft Corporation"}
or cloud.aws.tags.value: *
or cloud.gcp.tags: *
or cloud.azure.tags: *
)
and
(
cloud.aws.tags.value: {"ai-test", "gpu-instance", "jupyter"}
or cloud.gcp.tags.value: {"ai-test", "gpu-instance", "jupyter"}
or cloud.azure.tags.value: {"ai-test", "gpu-instance", "jupyter"}
or tags: {"ai-test", "gpu-instance", "jupyter"}
or host.tags: {"ai-test", "gpu-instance", "jupyter"}
)That query is not the end state. It is a starting point.
Every organization will have its own naming conventions. Search for your internal project names, GPU naming patterns, model names, business unit tags, sandbox labels, and cloud account conventions.
Then operationalize it:
- Save the query.
- Alert on new matches.
- Send notifications to Slack, Teams, Jira, ServiceNow, or the workflow your teams already use.
- Review whether the exposure is approved, temporary, misconfigured, or dangerous.
- Track recurrence.
The important shift is that ASM is not just a dashboard. It’s a control loop.
Playbook 4: Close Dangling DNS Before Agents Follow It
Dangling DNS is exactly the kind of boring exposure that survives because everyone assumes someone else owns it.
A team shuts down a bucket, app, page, or third-party service. The DNS record stays behind. Now a trusted subdomain may still point at a resource your organization no longer controls.
Boom: subdomain takeover.
In the Mythos era, this matters even more. Dangling DNS is easy to automate. Attackers do not need a brilliant exploit chain to abuse a forgotten CNAME. They need to find it, claim the abandoned resource, and put content behind a domain your users and systems already trust.
Censys ASM helps close that gap by detecting dangling DNS risks across CNAMEs, NS records, and third-party services like S3, GitHub, Heroku, and others. These detections are powered by Censys Internet Map data, and ASM shows the impacted name, the DNS record, and the evidence behind the finding.
From there, the fix is usually straightforward: update or remove the stale DNS record, or reclaim the decommissioned resource before someone else does.
Playbook 5: Give AI Agents Safe Access to Real Attack Surface Data
Security teams are going to use AI agents too. They should; make it a fair fight.
But if an AI workflow is going to reason about your attack surface, it needs real data. Not a stale export or an old spreadsheet.
Censys ASM MCP Server gives AI-assisted workflows structured access to verified attack surface data, so teams can ask practical questions:
- What Internet-facing assets are affected by this CVE?
- What exposed services appeared this week?
- Which AI-related assets are not approved?
- Which dangling DNS findings need review?
- Which high-risk exposures should become tickets?
Give your own agents bounded access to current, external visibility so it can help triage, summarize, and route work without hallucinating assets or working from stale data.
If attackers are using AI to move faster, defenders should too. The pattern is, AI needs current and correct context.
Now, Where Does Censys Platform Fit?
ASM answers one half of the Mythos problem:
“What do we expose?”
Censys Platform answers the other:
“What are adversaries exposing?”
That matters because attackers are not static. Their infrastructure changes. Their domains rotate. Their kits mutate. Their hosting shifts. Their certs change. Their command-and-control servers churn. Their phishing pages move between compromised sites and disposable infrastructure.
An attacker can use agents to test lure variants, generate infrastructure, rotate domains, mutate templates, search for exposed services, and evade simple blocklists. The result is an unlocked scale.
That is where CTI, threat hunting, and detection engineering teams need better Internet intelligence.
A single IOC is rarely enough. An IP, a domain, a hash – these are not the detection. These are seeds!
The Domain Is Not the Detection. The Domain Is the Seed.
Let’s say a CTI team receives a suspicious domain from a phishing report.
The fastest possible detection is obvious:
Alert when url_domain = "example-bad-domain.com"
That might catch one thing. It misses the campaign.
The better workflow starts by opening the domain in Censys and asking: “What are the real indicators here?”
Maybe the answer is a certificate pattern. Maybe a redirect path. Maybe a hosting provider and port combination. Maybe a web title. A JavaScript artifact. An HTTP header. A favicon hash. An exposed admin panel. Or even – the same lure template deployed across dozens of hosts.
That is the move from IOC matching to detection engineering.
Censys Platform helps teams make that move. Instead of asking “should we block this one domain?” teams can ask:
- What else looks like this?
- What did it expose yesterday?
- What domains resolve here?
- What certs are reused?
- Does this infrastructure match known offensive tooling?
- Is this a one-off indicator or a repeatable pattern that can become a detection?
- Can that detection become enrichment, a watchlist, or a blocklist?
That is how Censys Platform helps CTI and detection engineering teams keep up with adversary infrastructure that changes faster than static feeds.
Imagine a security researcher identifies a suspicious infrastructure pattern tied to a fast-moving phishing or malware delivery campaign.
The first version of the finding is just a domain. Censys Platform then facilitates investigation:
- Search the domain.
- Review the live host and service profile.
- Look at the TLS certificate.
- Check DNS relationships.
- Inspect web titles, headers, paths, and body artifacts.
- Pivot to similar services.
- Review historical changes.
- Use Live Rescan to confirm what is still active.
- Save the pattern as a Collection.
- Monitor new matches.
Then the detection engineer turns the finding into logic:
Alert when internal telemetry touches infrastructure matching this campaign pattern:
- matching web title or page artifact
- matching redirect structure
- matching certificate reuse
- matching suspicious service exposure
- matching DNS relationship
- matching hosting or port pattern
- currently live according to CensysThe Best Mythos-Era Defense Is Not Another Static Feed
Security teams already buy threat intelligence as a finished product. They pay someone else to collect infrastructure, enrich it, score it, package it, and hand it back as a feed.
In the Mythos era, the real question is: what can your team produce from the rawest, freshest intelligence data available?
Censys already gives you dynamic intelligence out of the box. ASM continuously tracks your own Internet-facing assets, exposures, dangling DNS, vulnerable services, and risky changes. Censys Platform gives CTI teams live infrastructure intelligence like “Bulletproof hosting”, C2, or hacktool labels.
But you can also use Censys to build your own feeds.
A Censys Collection can become a living feed of infrastructure that matches your logic. Not someone else’s generic IOC list. Your pattern. Your confidence tiers. Your use case. Your decision on whether the output should become enrichment, triage context, a detection input, a blocklist, or an investigation queue.
That matters because Mythos-speed attackers will not be defeated by static indicators alone. Domains rotate. Hosts disappear. Certificates change. Services move. Infrastructure gets reused in ways that are obvious only when you can see the broader Internet pattern.
Crunch your own threat and vuln intelligence!
Feed Censys context into your own AI models and you can start doing the kind of threat intelligence work teams often outsource to vendors like Recorded Future: clustering infrastructure, identifying related services, prioritizing suspicious changes, generating analyst-ready context, and turning raw observations into operational intelligence.
The difference is that you are not limited to a finished report or a static feed. You are working directly from current Internet evidence.
See What Mythos Exposure Management Looks Like With Censys
Censys gives you best-in-class Internet data, ready-made dynamic intelligence, and the building blocks to create your own living feeds for exposure management and SecOps.
To see how Censys provides you with the intelligence and speed required to protect your attack surface against today’s AI-powered threats, request a demo.
Or, create a free Censys account to start using features like:
- Collections: create a real-time feed based on your own tailored logic.
- Lookup APIs: integrate Censys data into your existing workflows
- AI Assistant: ask questions in natural language to get quick insights and context.
For more on how to write detections that contend with a Mythos-caliber security landscape, read the Ultimate Detection Engineering Guide.
