August 10, 2026
0 mins readAutonomous AI attacks have definitively moved from the research demos everyone's been awed by to standard operating procedure. For anyone paying enough attention, this is not necessarily news: the Five Eyes Alliance warned everyone back in June that AI will bypass cybersecurity in months, not years, with adversary breakout times that can now be measured in seconds. Gartner itself predicted something similar, expecting the window to exploitation to be cut in half as early as next year.
Find what attackers can find, before they do.
This makes our announcement about the availability of Evo Continuous Offensive Security ever more relevant and timely. We are delivering autonomous offensive security that continuously attacks your applications and AI systems, the very same way a leading human red team would through three integrated capabilities: AI Pentesting, Agent Red Teaming, and Dynamic Testing (DAST).
COS is built to be the most accurate and trustworthy AI pentester on the market, with every finding being validated for real and reproducible exploitability by an "independent judge", so to speak, before it reaches you. This way, what ultimately lands in your report is only what an attacker could actually exploit.
But, rather than just telling you what it can do, we want to show you. Everything that follows is a real assessment of a customer application, and two of the very real vulnerabilities it found and proved.
A real customer assessment on a multi-tenant enterprise SaaS
One of our customers used COS to assess a multi-tenant enterprise SaaS application that consisted of a frontend single-page application (SPA) used as a web client, which, in turn, consumes a suite of hundreds of microservice endpoints that make up its business logic.
This application is particularly interesting in that it's challenging to evaluate, in different ways, for both human pentesters and deterministic tools, such as a DAST scanner:
For humans, it's very difficult to ensure full coverage of the authorization and business logic of hundreds of microservices. And for machines, the challenge is not access. Modern DAST scanners, such as Snyk API & Web (the Dynamic Testing capability within Evo COS), authenticate into SPAs and enumerate the endpoints behind them without much trouble. The difficulty is almost everything after that, because authorization and business logic flaws have no signature to match on: deciding whether a particular role should be able to invoke a particular endpoint, or whether a sequence of individually valid requests adds up to an outcome the application never intended, requires knowing what the application is for and what each actor is supposed to be able to do. Now picture that across hundreds of microservices, and you'll understand that it is much more of a reasoning problem than a coverage one. And that's the part dynamic testing has not automated.
The agentic solution within COS "picked" at the application in a methodic (guided) approach, while harnessing the power of LLMs:
Pre-flight checks: it tested the provided credentials using a headless browser and ensured that all of the required assets of the application were reachable and that the application was in a state that allowed it to be tested.
Initial reconnaissance: a dedicated sub-agent identified the application technology stack, the various endpoints that exist, and security-relevant information such as the use of a WAF, LLM agents exposed via chat interfaces, authentication flow, and so on. Crucially, this step also yielded insights into the business case of the application. In this instance, it correctly inferred what the product was for, who used it, and which of its workflows carried real commercial value, working only from a staging environment with little documentation and preloaded with nothing but test data. That inference was what allowed everything downstream to be judged in terms of business impact rather than technical severity.
Vulnerability testing and validation: specialized sub-agents were spawned to search for specific vulnerability classes, based on the results from reconnaissance. Individual findings were cross-validated by adversarial sub-agents to ensure they could be independently reproduced and to minimize the chance of false positives.
Vulnerability chaining and validation: individual vulnerabilities were associated together logically to verify whether they could be used together in a way that increased business impact. Vulnerability chains were also cross-validated and reproduced by adversarial sub-agents.
Report compilation: the findings were compiled into a document that mimicked the output produced by a human team, complete with an executive summary and a prioritized list of actions to reduce risk.
This particular assessment was performed in a pure black box approach, meaning that it was done without access to the source code. We are also capable of using a gray-box approach, using the access to source code to improve detection and efficiency, but we chose not to do so in this case. In any case, we are emphasizing the dynamic component of testing, attacking the application as a real attacker would, from the outside in.
So, what are the advantages that we've observed with this approach?
Being able to discern the business goals of the applications is a real advantage, especially when those are not absolutely obvious. This was a "messy" test environment with little real data, making the task difficult even for a human. Identifying the business goals helps the agent fleet better interpret the business impact of certain vulnerabilities.
Our agents drive a real browser and adapt to whatever authentication the application puts in front of them, without per-target scripting. In one particular assessment, the customer's login was protected by time-based 2FA, so we supplied the TOTP seed and the agent handled generating single-use codes itself, as part of working out how to log in, rather than because we had specifically configured it to. This matters less as a capability than as a reliability property: authentication is where automated testing most often fails silently, and an assessment that never gets past the login page is worthless, no matter how good the testing might be.
By following a guided, methodical multi-agent approach, we reap the benefits of humanlike creative agents while ensuring test coverage, systematically testing each microservice for authorization, authentication, and business-logic flaws.
The vulnerabilities it found
In this particular application, we found a total of 33 confirmed vulnerabilities, ranging from low-impact issues, such as the use of outdated or insecure jQuery libraries, to multiple critical vulnerabilities, including an insecure CORS policy that allows arbitrary malicious sites to steal authorization tokens and act on behalf of a user (with no user interaction), and authorization level flaws that allow any user to promote themselves to administrator of their tenant.
For the sake of brevity, we will highlight two findings that together show the two things that set this approach apart: finding what other tools structurally cannot, and communicating the true impact of what they can.
1. A tenant-wide compromise via mass assignment and broken function-level authorization
This is just the kind of finding that a DAST scanner structurally cannot produce, and one a human pentester would need deep familiarity with the application to reach. There's no reflected payload to detect, and no obvious error to chase there: the flaw lives entirely in the application's authorization logic, on a legacy administrative endpoint that manages the configuration of an entire tenant.
Our agent identified that a legacy JSON endpoint, used to save tenant-wide account settings, performed an unbounded key/value upsert with no server-side role or permission check, and did not enforce the HMAC-style signature
/ timestamp
parameters that its surface appeared to require. From there, it reasoned through the consequences and chained them: the lowest-privilege user role (the exact role every rank-and-file employee is issued at login, which can't even open the admin UI) could rewrite arbitrary security-critical configuration for the entire tenant, and several of those settings could be turned into full compromise.
The entire path from discovery to a validated, independently reproduced chain happened inside a single unattended run, without a human in the loop. A human team would typically need days of familiarity with the application to arrive at the same conclusion.
Here's a lightly redacted excerpt from the agent's report (all customer-specific and product-identifying details have been generalized):
A legacy administrative "save account settings" endpoint performs an unbounded key/value upsert into the tenant-wide settings store, with no server-side role or permission check and no validation of the accompanying HMAC-style signature
/ timestamp
query parameters. Any authenticated tenant user, including the lowest-privilege role (which cannot even navigate to the administration UI), can invoke the endpoint with a standard Bearer access token and rewrite arbitrary tenant-wide, security-critical configuration.
[...]
The impacted key set includes:
Password policy: complexity, minimum length, history count, and maximum age.
Authentication lockout policy: failed-attempt threshold and lockout duration.
Upload denylist for executable file types.
Additional Content-Security-Policy sources.
Sender domain for outbound tenant email.
OAuth integration parameters for a third-party enterprise integration (client ID, client secret, login URL, resource, and enabled flag).
Arbitrary attacker-defined new keys.
Root causes:
1. Missing role/permission check on the write method. 2. No allowlist of settable keys; the endpoint accepts any key string. 3. Failure to enforce the signature
/ timestamp
HMAC-style query parameters that the surface appears to require. Testing with a deliberately invalid signature still succeeded.
The report continues on to detail the steps required to replicate this vulnerability, with a section dedicated to business impact, quoted here (again, generalized):
Impact:
Because a lowest-privilege user has full read/write control over tenant-wide security settings, a single compromised or malicious tenant account (or any insider with legitimate low-privilege access) can:
1. Achieve full account takeover of every tenant user by weakening the password policy (e.g. minimum length of 1, no complexity requirements) and disabling the lockout policy, then performing online password guessing against the tenant login endpoint.
2. Distribute malware inside the tenant by clearing the executable-file denylist and uploading native executables through the content upload surface that low-privilege users can already reach. Uploaded files propagate to every user who browses the tenant's shared content.
3. Enable cross-site scripting by adding attacker origins to the Content-Security-Policy allowlist, widening script-src
and connect-src
for the tenant.
4. Weaponize outbound email by rewriting the sender domain, causing tenant notifications to appear to originate from an attacker-controlled domain (yielding highly convincing internal phishing that is signed and passes SPF/DKIM via tenant infrastructure).
5. Hijack the third-party OAuth integration by rewriting its login URL, client ID, and resource parameters, redirecting the OAuth code/token exchange to attacker infrastructure, and harvesting the OAuth credentials the tenant issues to what it believes is its identity provider.
6. Persist across sessions. Writes survive the attacker's ~30-minute OIDC token lifetime, so the tenant remains in the weakened configuration until an administrator manually detects and reverts each key.
7. Deny service against admin pages by writing a malformed configuration that crashes the administrative UI on subsequent parse.
The prerequisite is a single lowest-privilege OIDC access token, the exact token every real tenant user (including all rank-and-file employees) is issued at login. There is no additional gate, no admin scope, and no signature required.
This is the reasoning layer that traditional scanners cannot reach: recognizing an ungated write, understanding what each setting means for the business, and chaining a handful of them into tenant-wide compromise.
2. CORS origin reflection: a "trivial" finding, made undeniable
Cross-origin resource sharing (CORS) misconfigurations are about as routine as web vulnerabilities get. Practically any scanner, and any competent tester, will flag an endpoint that reflects the request Origin
into Access-Control-Allow-Origin
while returning Access-Control-Allow-Credentials: true
. Detection is not the hard part.
The hard part is one of the industry's most persistent yet least discussed problems: a vulnerability is reported, and nobody downstream can translate it into what it actually means for the business. That happens because severity levels travel well, conveying a sense of urgency, but the actual consequences usually don’t.
A finding arrives as a class name and a CVSS score, and the team receiving it has to decide how much it matters using information that never explains the potential outcome. So, they fall back to the easier analysis and just go by the number.
Anything labeled medium waits behind everything labeled high, and the result is not just a delay but a genuine misallocation of effort: real risk will sit untouched in a backlog while teams remediate findings that are easier to understand. Risk assessment is only as good as the impact analysis that feeds it, and for most tools, that analysis is left to the reader's interpretation.
This finding is a case in point. In a typical scanner report, it appears as a single medium-severity line regarding a permissive header. What it actually meant here was that any website a logged-in user happened to visit could silently read their session and steal the tokens used to act as them, with no interaction and no phishing.
The misconfiguration sat on the identity provider, applied to every endpoint of the application, and access tokens were returned in the body of the cross-origin responses. So this goes way beyond mere header hygiene, because it becomes a full account takeover of any user who happens to browse the "wrong" page. All the while, the vulnerability was sitting in the "medium" bucket.
What most impressed our customer and design partner was not just the fact that it managed to find it, but what the agent did next. Beyond just describing the issue and its business impact, it built a fully-working proof of concept, in a matter of minutes, that reproduced the entire attack in a stock Chrome browser: open the page, and watch your own access token be exfiltrated to an attacker-controlled origin.
A developer on the customer's team could reply with no proxy, no security background, no specialized tooling, and immediately see, rather than be told, that the finding means actual account compromise. At the end of the day, that will be the difference between a finding that gets triaged and a finding that gets fixed.
Findings like this can also be interrogated directly in the Evo platform, where a user can ask a finding to explain itself in plain language or suggest remediation, so the demonstration and the fix live in the same place.
That is the difference we care about: not detecting CORS, which is trivial, but collapsing the distance between a low-effort finding and an undeniable demonstration of its real-world impact.
Two findings, two different strengths
What this shows about how COS is different is both the ability to go deeper and to communicate impact properly.
On depth, it’s about recognizing an authorization flaw that a scanner cannot reach and a human would take days to find. And on communication, it’s all about taking a finding that any tool can detect, but making its real-world impact undeniable.
For a capable model, finding vulnerabilities is the easy part. The hard part is communicating them well, without noise, in a way that the intended audience can act on. That is where much of our engineering effort goes.
See it in action
Everything above came out of a single unattended run against a real application, and more than taking our word for it, you'd better see for yourself.
For the full picture on how AI Pentesting, Agent Red Teaming, and Dynamic Testing work as one system, and why continuous coverage beats a once-or-twice-a-year pentest, start with our launch announcement and sign up for our upcoming webinar, Pentesting-Grade Coverage at the Speed of AI, on September 2.
LIVE WEBINAR
Pentesting-Grade Coverage at the Speed of AI
Join Snyk on September 2 to see how Evo Continuous Offensive Security brings pentesting-grade, AI-speed security testing to every release you ship.