AI security testing · Early access
An attacker looks for a way in, tests what works, and follows it to valuable data or control. We’re building EverBreach to use AI in the same way—with your permission, agreed limits, and findings you can act on.
For organisations with or without a dedicated security team. Scope, access, price and timing are agreed before testing.
Request a pilot assessmentExplore the scanner demonstrationApplications, APIs, accounts, cloud services and infrastructure can form one attack path. An AI-assisted attack team adapts its next move to what it finds. That is the approach behind our simulations.
Explore the agreed environment from an outsider’s position or a normal user account. Identify exposed services, reachable data and places where permissions may fail.
Check whether a suspected flaw actually opens access: another applicant’s records, a paid file before purchase, or a function reserved for administrators.
Investigate whether one weakness leads further: from a record to its documents, from an exposed credential to another service, or from one account to greater permissions. Stay within the agreed boundaries.
Explain the demonstrated access, business impact and exact correction. After the fix, repeat the relevant steps to check that the path is closed.
Controlled scanner demonstration
Explore a recorded check against a local demo server using synthetic data. It uses the same exposed-file detection as the current EverBreach scanner.
# Synthetic demo values; no account or database exists.
DB_HOST=database.example.invalid
DB_USER=demo_only
DB_PASSWORD=NOT_A_REAL_PASSWORD
Critical · Configuration file publicly accessible
A configuration file can reveal database addresses and credentials. If the values were real and valid, an attacker could try to use them to reach another service. This check establishes that the file is readable; it does not establish access to a database.
Keep configuration files outside the public deployment and block direct access. If real secrets were exposed, revoke or rotate them and review access logs. In this demonstration, we changed the server to deny the request.
Forbidden
The same request now returns 403. The exposure rule produces no finding for this path. This verifies the demonstrated correction only; it does not establish that the whole system is secure.
This is one deterministic scanner check. No AI model was invoked, no real credentials were used and no access to another service was attempted. The hostname is replaced for display; the responses were recorded from a loopback-only server.
The evidence behind the threat
Attackers are using AI to investigate systems, test weaknesses and pursue access. Defenders are also finding previously unknown flaws with it. These published reports show what that looks like in practice.
Reported attack
Anthropic estimated this share in an espionage campaign targeting roughly 30 organisations. It reported successful intrusions in a small number of cases. Humans chose the targets and directed key decisions; the AI also made mistakes.
Anthropic · November 2025 ↗Vulnerabilities found and fixed
Mozilla reported finding these flaws during an initial evaluation of Claude Mythos Preview. This was research on Firefox, followed by fixes shipped to users—a concrete example of defenders putting AI to work.
Mozilla · April 2026 ↗Controlled attack simulation
The UK AI Security Institute reported that GPT-5.5 completed the full chain in 2 of 10 attempts, from an initial network foothold to a protected database. Each attempt had a 100-million-token budget. The environment had no active defenders.
UK AI Security Institute · GPT-5.5 · 2026 ↗Our takeaway: use these capabilities to test your own defences, and revisit them as systems and models change. These are external findings in different settings, not EverBreach results or a prediction of your likelihood of being breached.
High · Contain immediately
Start with one agreed system or business workflow. Choose it around the data, access or process you need to protect.
What was tested, what was demonstrated, the possible impact and how to fix it. Coverage and limits are documented even when no issue is confirmed.
Review the evidence and priorities with us. Bring whoever will make the fixes: your developers, security team or external IT provider.
Repeat the agreed checks to verify the corrections. The proposal defines what the retest covers and when it can take place.
Before you commit, the proposal sets the testing scope, fixed price, delivery date and retest window. Your enquiry is free and does not start testing.
Before granting access, you will know who is responsible for the assessment, which model provider is involved and how the evidence will be handled.
Access decisions happen across applications, APIs, storage and infrastructure. A page can look perfectly normal while the systems behind it expose data or bypass a business rule.
An attacker simulation needs permission, a defined scope and a clear stopping point. These are agreed before any testing.
Identify the systems, accounts and actions permitted in the engagement. Third-party services need their own authorization where applicable.
Agree test accounts, synthetic records and stop conditions. A limited proof should establish the weakness without turning a test into bulk access to personal data.
Before testing, we explain the model provider, information sent to it, storage and retention. Sensitive evidence needs an agreed handling process.
Separate demonstrated access from possible wider impact. The report should show the reasoning and give your team enough detail to reproduce the result within the agreed scope.
No. The project is aimed at security across applications, APIs and connected systems, for organisations of different sizes. The scanner currently implemented here is narrower: it checks public website configuration. We distinguish that starting point from the broader attacker simulations we are developing.
An AI-assisted test follows a possible attack path within agreed boundaries: what an account can access, which information it exposes and what that enables next. The sample scenarios show the intended depth of evidence. They are illustrative, not results produced by the current scanner.
A software change may introduce a weakness. A better model may find a weakness that earlier testing missed. These are different reasons to retest, and neither makes every new finding a zero-day or proves that AI alone caused the discovery.
Yes. The report is written for the people deciding what to fix and the people implementing it. That may be an internal security team, developers or an external provider. Each finding should identify an owner and a way to verify the change.
Scope, availability, price and delivery are agreed before you commit. Sending an enquiry is free and does not start a scan, reserve a slot or create an obligation to purchase.
Continuous testing and automatic retests after model releases are still in development. Current assessments and any follow-up checks are agreed individually.