Your attack surface management tool can tell you what's exposed. But can it tell you what an attacker will actually exploit? With AI attackers compressing days or weeks of reconnaissance and exploitation into minutes, knowing what's exploitable is more urgent than ever.
Today, A Security is introducing Continuous External Infrastructure Testing, powered by autonomous offensive agents that go beyond discovering vulnerabilities to actively exploiting them. Instead of another list of potential risks, security teams get proof of which weaknesses and attack chains an adversary could use to find a way in, along with autonomous remediation capabilities and automatic revalidation of fixes.
Why Attack Surface Management Isn't Enough
Traditional external attack surface management (ASM) tools were built to answer a simple question: what's exposed? They discover internet-facing assets, flag known vulnerabilities, and assign risk scores. That's valuable, but it doesn't tell you whether an attacker can actually exploit what they've found.
Some vulnerabilities aren't exploitable in your environment. Others provide a direct path in, or can be chained together to create serious risk. A score alone can't reliably distinguish between them. And weaknesses without a known CVE may never appear on the list at all.
But attackers don't care about risk scores. AI agents can now continuously scan for new targets, probe exposed services, and test potential ways in. A system that goes live on Tuesday can be under attack by Wednesday.
Yet most organizations still test their external infrastructure periodically. A penetration test once a year. An inventory review once a quarter. Even continuous security testing often focuses on applications rather than the infrastructure around them. Meanwhile, new systems, exposed services, and exploitable weaknesses can emerge between assessments.
A Security solves this by continuously discovering external infrastructure and putting potential weaknesses to the test, proving which ones an attacker could actually exploit.
How A Security’s Continuous External Infrastructure Testing Works
Give A Security as little as one main domain, and our agents find everything else tied to the company, including subsidiaries and internet-facing systems you may not know exist. Hosts, subdomains, services, and applications are organized into an inventory, giving security teams a complete picture of their external infrastructure.
From there, A Security develops an attack plan tailored to your environment. Autonomous offensive agents attack anything that answers from the internet: web applications and APIs, mail servers, file transfer and remote access services, VPN gateways, management consoles, other exposed services, and underlying infrastructure, exploiting vulnerabilities and chaining weaknesses together to determine what an attacker could actually accomplish.
Only validated findings reach your dashboard, complete with evidence of exploitation and guidance for remediation. As your perimeter changes, new exposures are discovered and tested automatically.
Putting External Infrastructure to the Test
Exploiting the Whole Perimeter, Not a Shortlist
A software company gave us a few of its domains. Discovery turned them into more than 2,500 internet-facing systems, and the agents put each one to the test.
Out of the many findings the agents proved, there were two critical ones. The administrative console of a critical system still accepted its factory-default administrator password. Our agents logged in as a user administrator, with no MFA in the way.
A separate tool meant to preview snippets of code would run any code it was sent. The agents escaped its sandbox and ran system commands on the server. Because the tool answered requests from any website, a malicious web page could have triggered the same thing from a visitor's browser.
Neither needed a sophisticated exploit. Both were reachable from the internet. And both would have gone under the radar of traditional ASM tools.
From Exposed to Exploited, An Attack Chain with Proof
A healthcare company running patient portals had each portal shipping a portal ID in its public JavaScript, the kind of value everyone assumes is safe to expose. Our agents handed it to the company's API gateway and got back a token for a production service account.
The token was meant for anonymous visitors. It could also search patient records by name, returning dates of birth, home addresses, phone numbers, and member IDs. On another portal, the same kind of token listed hundreds of portal users, admin flags included. Then the agents used it on a PDF generator, tricking the company's production servers into calling out to a server the agents controlled. That's server-side request forgery: the company's own production servers fetched whatever the agents pointed them at, a first step toward systems that were never meant to face the internet.
Each element seemed harmless on its own: a public ID, a guest login, a PDF export. Together, they gave anyone on the internet a production identity. No version number would have flagged these issues. AI adversaries will find attack chains like this in the wild. We found it first.
Zero-Days Are Side Effects Now
Scanners match versions to known CVEs. A flaw nobody has reported yet has nothing to match.
The agents were testing a financial platform’s perimeter when they encountered Intel’s open-source service for issuing SGX and TDX attestation certificates. Its admin endpoints required a token. Adding a second slash to the URL bypassed that check. Every admin endpoint answered.
There was no CVE. There still isn’t.
The agents hadn’t set out to find a zero-day. They found one while doing the work: testing what systems actually do, rather than relying on what their version numbers say they should do.
That discovery, and what it means when vulnerability research becomes a byproduct of an ordinary campaign, is the subject of an upcoming article.
Checking an Acquisition Before It Becomes Yours
When you buy a company, you buy its perimeter. One security leader discovered this firsthand. As we reviewed A Security’s findings together, they noticed an unfamiliar domain, looked it up, and realized it belonged to a company their organization had already acquired. The problem: it was never brought into its security program.
Another organization, which frequently acquires companies, now has us test a target's perimeter before the deal closes. All we need is its domains and its authorization. Results come back in hours, while there's still time to fix what's found or price it into the deal.
From Finding and Fixing to Ongoing Validation
Proving a vulnerability is exploitable is only half the job. Every validated finding comes with evidence of exploitation and remediation guidance tailored to the affected system, so security teams know exactly what needs to change.
For vulnerabilities that require code changes, A Security can pass the finding and its supporting evidence to coding agents such as Cursor, GitHub Copilot, or Claude Code, giving them the context to develop a fix. Configuration weaknesses, such as default credentials or spoofable email domains, come with specific remediation instructions.
But remediation doesn't stop at recommendations. A Security also supports autonomous remediation to shorten the time between discovering an exploitable weakness and closing it. Once a fix is applied, the agents can automatically retest the affected system to verify that the vulnerability is no longer exploitable.
Layered Guardrails on Every Campaign
Testing an internet-facing perimeter means testing production systems, so safety can't depend on the attacking agent policing itself. Every campaign runs with A Security's Layered Guardrails, a set of independent controls designed to enforce safety at every stage of testing.
Before a campaign begins, you can review and approve the attack plan and define which systems are in scope. During execution, high-risk actions are evaluated before they run. Agents are restricted from modifying data they didn't create, contacting real users, making purchases, or taking actions that could disrupt production services.
These boundaries are enforced independently of the agents themselves. A separate judge evaluates actions without access to the agent's reasoning, shared memory distinguishes test data from real customer data, and a network-level safety proxy prevents agents from reaching prohibited targets. Every blocked action is logged for review, and a kill switch allows the campaign to be stopped at any time.
Know What an Attacker Can Actually Exploit
Your external infrastructure never stops changing, and attackers never stop looking for a way in. Security testing shouldn't stop either. A Security's Continuous External Infrastructure Testing gives security teams a continuous view of their exposed systems, proof of exploitable weaknesses, and a path to remediation before attackers find them first.
Request a demo to see what our autonomous offensive agents can uncover across your external infrastructure.
