When you look around security, it is clear that AI has left the pilot phase in a lot of modernization efforts.
This is great news, especially for me, as I’ve spent a good portion of the past 18 months advocating for security to be an early adopter and innovator with AI if we want to have any chance to keep pace with the attackers use of the technology and its impacts from the industrialization of vulnerability discovery to autonomous exploitation.
It shows up in the data as well, with IBM’s 2026 Cost of a Data Breach report finding more than 50% of organizations reported using agents for threat detection and containment and 25% of breaches being AI-enabled.
Initial access in breaches continue to be tied to what is reachable from the Internet, with exploitation being a top initial access vector, and despite that only 25% of KEV’s that are critical get fully remediated.
While teams such as SOC’s are undergoing major modernization efforts to combat these trends, they’re often doing it just looking internally, while flying blind to broader context regarding what is happening outside the organization.
The truth is AI-driven SecOps are only as good as the external data and context powering them and without the right data, we run the risk of AI reaching the wrong or incomplete conclusions, just faster.
That’s why I wanted to take sometime to walk through the importance of that broader external data, what it tells us and how teams such as Resilient Cyber’s partner Censys provides.
So, let’s take a look.
A lot of the insights and metrics I discuss below are from Censys’s recent 2026 State of the Internet Report, so be sure to grab a copy to check out the full report!
A Decade of Looking Inward
We’ve seen ten years of SecOps investments going to areas such as endpoints, logs, cloud posture and identity, all of it aimed at better describing what is going on within an organization.
This is critical of course, as SecOps is responding to activities going on within the enterprise, especially those that seem anomalous or malicious. However, the outside-in view is the one the adversary already has, and organizations often cannot see their own external network footprint as well as an outsider can, and their ability to act on that external exposure is only getting accelerated as attackers adopt AI and agents into their activities from enumeration through exploitation.
I often write a lot about CVE’s and vulnerability management, and organizations tend to look across their estate similarly. This is an important activity, given those vulnerabilities are what adversaries exploit. That said, from sources such as the 2026 DBIR we know there are exploited vulnerabilities with no CVE assigned, especially as institutional sources we rely on such as NVD and KEV stumble from the load of AI-driven vulnerability discovery.
CVE-centric vulnerability management isn’t the same as knowing your organizational exposure and the outside-in view is the one the adversary already has and will be acting on.
Many organizations have made efforts to get external data sources such as threat intel feeds, or even building their own OSINT, or even buying aggregators but many of these sources are either stale by the time they arrive or require significant internal efforts to operationalize, taking from the teams bandwidth to do work directly tied to reducing organizational risks.
We’re also seeing another trend, which is teams that do adopt AI and automation in SecOps have reduced breach costs by almost $2M on average per IBM, which is a great sign, but those efforts ultimately need to be powered by high fidelity context that is sourced both internally and externally.
In my experience building large security programs both at Federal agencies as well as in the commercial sector, there is almost always an emphasis on the internal context and data sources, while external telemetry is treated as optional and it is hard to truly respond to adversarial behavior where were largely flying blind to what that looks like at Internal-scale.
What Good External Data Looks Like
But what does “good” external data actually look like?
This is where I was truly impressed with the scale and vast amount of high quality data the team at Censys possesses. I’ll admit I wasn’t deeply familiar with them prior to meeting with the team and digging in, but once I did and saw not only the data, but also the long list of highly critical private and public sector organizations that rely on them including 50% of the Fortune 500 and 40 national defense and intelligence agencies, I was truly impressed. To put their data in perspective, let’s explain what some of it is.
The first is the scale, where they have indexed 220 million hosts, 17 billion certifications and 2.9 billion web properties/endpoints. They scan the entire public IPv4 address space across all 65,000+ ports and have 17 billion TLS certificates as of 2 September 2026.
This includes a daily refresh of 3.3B services, over 254M IPv4 hosts, 1.2B virtual hosts and a daily comprehensive scan of all ports that is updated daily in their Internet Map.
Next after scale is the coverage, which includes a growing list of IPv4 services which grew from 275M in 2015 to nearly 794M currently, a 188% increase. Their coverage also includes up to 96% of services on the top 10 ports and 92% across the top 100 ports, with new services detected in less than 13 hours on average.
Four key properties of their data includes:
First party - Censys originates the raw scan data rather than being an aggregator third party. This means several of the largest security vendors and threat intel shops actually depend on Censys as a data source for their own research.
Continuous - It is refreshed every 8 hours on average and everything being researched within 16 hours and users can trigger live rescans and DNS resolutions as well.
Longitudal - They posses over 4 years of history in their application, and their ARC research team works from raw data going back 8 years.
Contextual - Including multi-year X.509 history, web property snapshots, open directory identification and mapping from infrastructure back to domain names.
A Censys agentic investigation from a single provided IOC
This first party data buys defenders source data they can trust, that is already trusted by critical organizations and security vendors alike, at a scale few, if any organizations can claim. The source and fidelity of this data is absolutely critical for AI systems empowering SecOps and internal defensive efforts as well, to understand the ecosystem malicious activities are originating from.
Where Does Context Change The Answer?
We’ve talked about what good data looks like but where does it truly change the conclusions and actions AI-driven defensive systems take?
Censys’ key claim is that AI on the wrong data gets to the wrong answer, just faster. The way to test this out is to look at the workflows the AI SOC is being pointed at and ask where the same question might of yielded a different answer with external context involved.
Censys published their 2026 “State of the Internet Report” today, the latest edition of their annual research built on the same Internet-wide scan data discussed above, and this year it takes measurements across five areas, ports and protocols, vulnerability response, industrial control systems, threat infrastructure, and exposed AI infrastructure, with the stated goal of establishing a baseline they can revisit year over year. I will draw on it throughout the rest of this piece, and it is worth reading in full for the sections I don’t get to.
For our purposes, let’s start with triage, including the asset inventory queues get built on, because the report’s data suggests it is wrong in ways most teams haven’t accounted for.
For example, they found that 34% of SSH instances run on a port other than 22, 68% of HTTP(S) services run on ports other than 80 and 442 and 96% of SOCKS proxies run somewhere other than 1080. For example, a rule checking only port 1080 for SOCKS exposure would be operating on just 4% of the actual population.
This problem gets even worse when assets aren’t in your IP space at all, such as where roughly 70% of the 134,000 exposed ICS hosts Censys observes sit on consume and mobile carrier networks via cellular models, where WHOIS points to the telco rather than the operator, so an operator searching against their registered netblocks will miss their own endpoint.
Now if you consider triage with an emphasis on reachability, which is a topic I often stress, things look different as well. In a demo I got from Alex of Censys, their attack surface management product took a customer’s domains and CIDR ranges and using a vulnerability disclosed a week prior, returned 264 instances visibile on the public Internet, each mapped to its specific CVE, KEV and EPSS score. Reachable of course gets the emphasis from attackers, and should get a prioritization from defenders for that very reason, especially against a 43 day median and 26% KEV remediation rate we see currently in the ecosystem.
Then we have investigation, where context does the most work. Investigators are often handed artifacts, such as IP addresses in logs, a hostname, or a tool fingerprint that rarely explains itself. Two findings in the reports threat infrastructure section make the point.
The first is about geography, with a lot of threat intel reporting treating “traffic from China” or “hosted in the U.S.” as a signal of who the actor is, but Censys data suggests actors don’t pick a country, they pick a provider, based on cost, and how easily infrastructure can be spun up through an API, as well as how tolerant the hosting provider is of abuse. The country is basically a byproduct of that choice, and it tells you less about intent than many assume.
The second and hard problem is the dual use nature involved. The three largest items in Censys’s tracked threat infrastructure are FRP, a reverse proxy for exposing internal services through a firewall, NPS, a similar tunneling proxy with central management and Nezha Monitoring, a server monitoring agent.
Together they make up 85.2% of everything Censys tracks as threat infrastructure and all three are ordinary sysadmin tools that attackers also happen to leverage. “FRP detected” is a true finding that carries almost no binary verdict on its own, since a given instance is as likely to be a developer exposing a test box as an attackers tunnel.
You could have two identical FPR instances, with one sitting on a bulletproof hosting environment that ignores compute complains and another on a mainstream cloud provider with a working abuse reporting function that is responsive. In both cases the fingerprint is the same, what separates them is the surrounding context, such as the providers reputation, what else may be running on the same host, its certificate and DNS history and how long it has been there.
This is the type of context external Internet data supplies and most SOC teams lack, and an agent working without it could potentially flag the developers test system and miss the tunnel, as one example.
When it comes to threat hunting, this is the workflow that benefits the most from historical depth, since the point is to pivot from one node to the cluster. In the demo I had from the Censys team, they fingerprinted C2 frameworks and AsyncRAT forks, labeled hosts on bullet proof providers and walked through open directories where staging scripts and data dumps sat in plain view.
Where a given SOC has a threat hunting function that can use this is a far question given many organizations lack this capability. That said, this is also where AI SOC has a real opportunity because an agent can take an IOC, expand it into surrounding infrastructure using years of DNS and certificate history, and hand an analyst a written-up cluster, which is work most teams never have the headcount for.
A live open directory of threat actor and “EDR Killer” tools in Censys
There’s a couple of other points beyond the perimeter that are interesting here as well. For example, Verizon found third-party involvement in 48% of breaches this year, and Censys told me they are building out supplier monitoring as part of their upcoming Supplier Risk module, which I thought has promise given there’s value related to procurement, M&A diligence, and enforcing vendor SLA’s.
On the Federal front, reachability is functioning as a compliance trigger. CISA’s BOD 23-2 gives agencies 14 days to remove networked management interfaces from the Internet once scans find it, and given the threat activity we’ve seen in recent years, identifying and removing those externally exposed attack paths is critical.
The AI Stack Is Part of the Surface Too
Much of what we discussed above is about defending the environment you know you have. That said, there is plenty of shadow AI already becoming pervasive and the outside in assessment is a great way to identify what the organization has stood up without telling you.
To highlight just how pervasive AI has become, as of July 2026, Censys observed 267,915 hosts exposing AI or LLM-related tooling to the public Internet, up 63% in nine months, across 44 products spanning more than 20 functional categories.
The exposed stack is overwhelmingly tied to plumbing, meaning inference servers, LLM gateways, orchestration platforms, vector databases, and agent control planels, most of which were only ever meant to talk to the app in front of them. Their report attributes much of it to “vibe coding” and shadow AI, but either way these systems land outside of security’s visibility.
n8n is a good example, since it began as a workflow automation platform and has repositioned itself as an AI orchestration layer with native support for agents, model providers and MCP, which means it sites between external inputs, stored credentials and every downstream service it connects to.
Censys found roughly 114,000 exposed instances, 67% of which had the native port directly reachable, a median deployment 103 releases behind the current and 76.1% of versioned hosts in range of at least one CVSS 9.0 or higher vulnerability disclosed in the previous six months. That is the orchestration layer holding the keys to everything behind it, and badly out of date and vulnerable. I would call it the Jenkins of the agent era, and I say that with some affection for having lived through the Jenkins era of DevOps.
OpenClaw on the other hand is a tempo warning. Censys saw two exposed control panels on January 11th, and a peak of 85,478 on April 7th, before a token-leaking CVE and a Chinese government restriction on state-sector use brought the count back down. As the report put it, a new AI product can go from obscurity to 85,000 exposed hosts in weeks, faster than security practices or governance can catch up, and the next one may sit closer to enterprise data as we see Personal AI (PAI) take off such as Meta’s Muse or xAI’s Grok Bot.
Censys is careful to say that exposre does not by itself prove an asset is insecure, with ICS as the exception where exposure itself is the vulnerability. I would extend that exception to agent control panels as well. A console that gives operator-level access to an agent and every account wired into it has no business being reachable from the public Internet, and the OWASP Agentic Top 10 I’m involved in treats that orchestration and credential-holding layer as exactly the kind of asset that deserves its own hardening posture.
IBM’s data points in the same direction, with more than 20% of organizations reporting a breach targeting AI models or applications and the leading causes being compromised API’s plug-ins', and cloud misconfigurations, which is to say the system around the model, rather than the model itself.
Turning Intelligence Into Action
During my discussion with Censys, they explained how they deliberately avoided marketing themselves as an AI security company. Despite extensive use of AI within the product, they see their value as feeding into the AI automations customers already run, which Censys describes as being the intelligence and context layer for AI-powered security workflows, or in Oliver’s framing, AI plus context, both internally and externally.
What they have built on the AI side is early and worth describing as a direction rather than an endorsement. This includes Persona-based summaries tailored to the same host data for a SOC analyst, researcher, or a vulnerability analyst, an MCP server lets an organization’s own agents query the dataset directly, and an agentic investigation feature that takes a set of IOC’s, expands the cluster, and produces a detailed summary.
The more durable idea underneath it all is delivery, with webhooks pushing asset changes in real time into firewalls, SIEM and SOAR, because another console nobody logs into is not security value.
For a security leader evaluating any vendor’s “AI-powered” SecOps claim, that suggests the things worth asking about, such as what data the AI actually sees and whether any of it is external, whether the agent is given a bounded and provenanced source over MCP or is browsing the open web and ingesting whatever it finds, and whether a human is in on the action.
Handing an agent a love map of the Internet changes its risk profile in ways the OWASP Agentic Top 10 catalogs fairly well, from the scope of what it can query, to the permissions on what it can act on, to prompt injection through fetched web content. Teams would be well served to treat the data sources as a privileged integration rather than a search box.
Censys’s forecast in the report is that AI is becoming an infrastructure layer on the Internet rather than a product category, with its attack surface taking shape in real-time. That’s a take I agree with, and add that the AI SOC two years from now is going to be judged less on how clever the agents are and more on what they are allowed to see and the security implications that comes with that.
Censys also has an AI SOC eBook coming that goes deeper on the operational side and their 2026 “State of the Internet Report” (SOTIR) went live recently, for anyone who wants the full dataset behind the figures above.
Closing Thoughts
While this is isn’t an all encompassing discussion, Censys’s dataset os one of the most comprehensive I’ve come across and it is impressive and easy to see the value for various security use cases, including other security tools and capabilities.
It’s clear to me that external Internet intelligence is a major security primitive security programs are often missing and that AI has raised the cost of missing it on both sides, for attackers who now move faster than our patch cycles across industrialized AI-discovered vulnerabilities, and also for defenders who are automating decisions on half of the picture.
If we hand agents the same inside-out data we have always had, we should not be surprised when they got the wrong answer sooner than we did.
This reality should cause teams to step back and ask what their AI SOC can actually see, and what is it missing.