The record · five incidents · 2026

Makeyoursystems Mythos Safe.

In 2026, software started breaking into software. This is the public record, and what to do about it.

Scroll to read
Mattersec Labs · Security Brief 2026 Days since Mythos preview160

Trusted by Apple, Meta and Microsoft to find what matters.

Hall of Fame researchers, Black Hat speakers and OWASP chapter leads. The same team now reads your product first.

What changed in 2026

The attacker used to need a team. Now they need a prompt.

Vercel, OpenAI, Hugging Face, Anthropic, Meta. All of them were well defended.
$0

was the cost of the model run that found a 27-year-old OpenBSD bug.

0

Firefox vulnerabilities Mozilla fixed in two weeks with one model.

Every company on the record had a security team, scanners and a pentest on file. The missing piece was a loop that knew what had become exploitable since.

Software now changes faster than humans can review it, and AI has changed the economics of finding weaknesses in it. Security is still split across tools, teams and point-in-time processes. MATT sits across that loop: it observes what changes, proves what is exploitable, helps your team fix it, and remembers the fix as a control on every release.

A $50 model run found a bug that 27 years of review had missed.
OpenBSD · April 2026
What the industry is saying

The industry agrees.

Yahoo Finance

$1 trillion of cybersecurity infrastructure isn’t ready for AI

“Nothing that was deployed seven or 10 years ago is prepared to handle AI at machine speed.”

Nikesh Arora, CEO, Palo Alto NetworksRead article ↗
IT Pro

‘The threat landscape is moving so quickly’

“Most companies have some level of gaps. Even if they are sophisticated and spending a lot.”

George Kurtz, CEO, CrowdStrikeRead article ↗
Fortune

“Cyber is our biggest risk. It’s been our biggest risk for years.”

On patching: “In the old days you had a week or two. Now it’s got to be like minutes.”

Jamie Dimon, CEO, JPMorganChaseRead article ↗
24/7 Wall St.

“Something has gone completely wrong” in AI

Enterprises buying token-based access to frontier models are paying to expose their intellectual property.

Alex Karp, CEO, PalantirRead article ↗
IT Pro

‘We can assume that all threat actors are using AI in some capacity’

Attackers used AI agents to plan, build and run a mass credential-harvesting campaign in under six hours.

John Hultquist, Google Threat Intelligence GroupRead article ↗
Axios

AI agents are poised to be the next hacking victims

“We’ve given AI agents the crown jewels to everything. It’s going to become the No. 1 attack vector.”

Dave Gerry, CEO, BugcrowdRead article ↗
PYMNTS

Expect routine AI-driven cyberattacks

“People are going to be able to have ongoing, persistent attacks on you.”

Chris Lehane, Chief Global Affairs Officer, OpenAIRead article ↗
IT Pro

Five Eyes agencies sound alarm over risky agentic AI deployments

“Organisations should assume that agentic AI systems may behave unexpectedly and plan deployments accordingly.”

Five Eyes intelligence agenciesRead article ↗
01Where we come in

Every incident on the record is missing the same thing: a written rule.

A public surface, a capable model, and a check nobody had specified. MATT writes the checks, in plain English, and tests your product against them.

A rule gets written. The tiles turn green.
In this chapter
Turn each pattern on the record into a rule

Every public incident this year reduces to a check nobody had written down. We write it as a one-line rule in plain English, such as "no user can read another user's order", and test your product against it.

Rank exposure by bill, headline, outage

Findings are ordered by what they cost the business, not by CVSS score. Each one states whether the outcome is an invoice, a disclosure, or downtime, so leadership can decide in one read.

Cover the surface a free signup reaches

Anyone can create an account, so we start there: every endpoint, token and workflow a new user can touch, mapped before the first test runs.

Catch what AI-written code skips

Generated code passes review and still omits the ownership check or the rate limit. Rules run against the behaviour of the deployed product, so it does not matter who or what wrote the code.

02How we work

Know what's exploitable before someone else does.

MATT is the AI Security Supervisor for your software lifecycle. It observes what changes, proves what is actually exploitable, helps your team fix it, and remembers the fix as a control. Observe, prove, fix, remember: this is ExploitOps.

Observe the change, prove the path, fix it together.
In this chapter
Observe what changes, read-only

We work from a read-only view of your deployment, repository and the tools you already run: scanners, pentest reports, evals, observability. No agents to install. The first findings arrive within the first week.

Prove it, then fix it with your team

Adversarial reasoning and 1,200+ attack patterns separate theoretical findings from working attack paths. Each proven path becomes a change your engineers review and merge, with root cause and priority attached.

Rules your product is tested against on every release

Every fix is locked as a rule. On each release the rule is re-tested against the live product, so a regression is caught before it ships rather than found by someone else.

No customer data leaves your environment

Tests run against your deployment; results and evidence stay in your systems. We see behaviour, not records.

03What you get

Secure on audit day, and every day after.

One audit tells you where you stand. The assurance system re-tests every rule on every release, including code your AI wrote, and gives the board one page on demand.

Every release, every rule, every time.
In this chapter
One audit: where you stand today

A fixed-scope assessment across 1,200+ patterns, ranked by business impact, with fixes written alongside your team. You know where you stand within three weeks.

Always-on: still true after every release

The assurance system keeps every rule under test as the product changes. The answer to "are we still secure?" is current on any given day, not on the day of the last audit.

Evidence your board and auditors accept

One page, generated on demand: which rules hold, what changed, what was fixed and when. Maps directly to SOC 2 controls and customer security questionnaires.

What the first hour covers

A researcher looks at your public deployment live, names the two or three exposures that matter most, and tells you what an audit would scope. You leave with a straight answer.

01Software changes faster than humans can review it.
02AI has changed the economics of finding and exploiting weaknesses.
03Security runs as separate tools, teams and point-in-time checks.
04The advantage goes to whoever knows what became exploitable first.
05That calls for a new operating model.
The operating model

ExploitOps.

Continuously discover, validate, fix and prevent what is exploitable in your software.

Run by MATT, the AI Security Supervisor
ObserveProveFixRemember

Your scanners, pentests and evals become one loop that runs on every change. Every discovery becomes a permanent control.

What is ExploitOps?
Prove what's actually exploitable

1,200+ attack patterns. Six categories.

MATT combines application context, adversarial reasoning and 1,200+ attack patterns to separate theoretical findings from meaningful attack paths. One capability inside Prove.

01 · 260+ patterns Open ↑

Ownership checks, session handling, privilege boundaries. Seen at Hugging Face.

02 · 140+ patterns Open ↑

Metering, quotas, and the compute your product gives away for free.

03 · 310+ patterns Open ↑

Responses, logs, environment variables, third-party calls. Seen at Vercel.

04 · 120+ patterns Open ↑

Signups, resets, and transactions at a scale humans never operate at.

05 · 90+ patterns Open ↑

What it takes to slow or stop the product. Seen at OpenBSD: two packets.

06 · 280+ patterns Open ↑

Generated handlers, agent permissions, prompt-injected tooling. Seen at Black Hat.

How it runs

One hour to a first answer. Twenty-one days to always-on.

No agents to install. No data leaves your walls. Your team approves every change.

60min
Day 0

The call

A researcher looks at your public deployment live and gives you a first read.

Out: scope and a straight answer

7days
Week 1

Observe and prove

Read-only access. We map what changes, then prove what is exploitable across 1,200+ patterns.

Out: proven paths ranked by business impact

21days
Weeks 2–3

Fix and remember

Each proven path becomes a fix your team approves, then a control that runs on every release.

Out: fixes merged, controls written

Every change

Supervise

Every meaningful change observed and re-proven against every control, including AI-written code.

Out: one page for the board, on demand

NDA in 24 hoursRead-only accessMapped to SOC 2 and ISO 27001How procurement works →

Pentesting answers a question at a point in time. ExploitOps makes the answer permanent.

Annual pentestBug bountyExploitOps · MATT
When it runsOnce a yearWhen a stranger bothersEvery release
Who proves itOne consultant, one weekWhoever shows upYour stack's signals, adversarial reasoning, researchers
What you getA PDFA queue of ticketsProven paths, fixes merged, controls that keep them fixed
AI-written codeNot coveredNot coveredChecked before it lands
What the board hearsA dateA bounty totalOne page: where we stand today

Book an ExploitOps Review.

Sixty minutes with a security researcher to understand how your organisation currently discovers, validates, fixes and prevents exploitable risk, and where the loop breaks. You leave with an ExploitOps map of your workflow and the gaps that matter. Paid; settled when you book.

Length60 minutes
FormatVideo call
WhoA security researcher
You leave withAn ExploitOps map, ranked gaps
Book an ExploitOps Review What the review covers · read →
01Where we come in

Every incident on the record is missing the same thing: a written rule.

Every incident on the record reduces to a check nobody had written down. We write those checks as one-line rules in plain English, then test your product against them on every release.

Book an ExploitOps Review
01

Turn each pattern on the record into a rule

Every public incident this year reduces to a check nobody had written down. We write it as a one-line rule in plain English, such as "no user can read another user's order", and test your product against it.

02

Rank exposure by bill, headline, outage

Findings are ordered by what they cost the business, not by CVSS score. Each one states whether the outcome is an invoice, a disclosure, or downtime, so leadership can decide in one read.

03

Cover the surface a free signup reaches

Anyone can create an account, so we start there: every endpoint, token and workflow a new user can touch, mapped before the first test runs.

04

Catch what AI-written code skips

Generated code passes review and still omits the ownership check or the rate limit. Rules run against the behaviour of the deployed product, so it does not matter who or what wrote the code.

From the recordTwo of the three companies Anthropic's models reached did not know until Anthropic called.
02How we work

Know what's exploitable before someone else does.

Read-only access, fixes your engineers approve, and rules that run against the live product. Three weeks from the first call to always-on.

Book an ExploitOps Review
01

Observe what changes, read-only

We work from a read-only view of your deployment, repository and the tools you already run: scanners, pentest reports, evals, observability. No agents to install. The first findings arrive within the first week.

02

Prove it, then fix it with your team

Adversarial reasoning and 1,200+ attack patterns separate theoretical findings from working attack paths. Each proven path becomes a change your engineers review and merge, with root cause and priority attached.

03

Rules your product is tested against on every release

Every fix is locked as a rule. On each release the rule is re-tested against the live product, so a regression is caught before it ships rather than found by someone else.

04

No customer data leaves your environment

Tests run against your deployment; results and evidence stay in your systems. We see behaviour, not records.

From the recordAn AI note-taking tool with OAuth access was the way into Vercel.
03What you get

Secure on audit day, and every day after.

One audit tells you where you stand. The assurance system keeps every rule under test as the product changes, and gives the board one page on demand.

Book an ExploitOps Review
01

One audit: where you stand today

A fixed-scope assessment across 1,200+ patterns, ranked by business impact, with fixes written alongside your team. You know where you stand within three weeks.

02

Always-on: still true after every release

The assurance system keeps every rule under test as the product changes. The answer to "are we still secure?" is current on any given day, not on the day of the last audit.

03

Evidence your board and auditors accept

One page, generated on demand: which rules hold, what changed, what was fixed and when. Maps directly to SOC 2 controls and customer security questionnaires.

04

What the first hour covers

A researcher looks at your public deployment live, names the two or three exposures that matter most, and tells you what an audit would scope. You leave with a straight answer.

From the recordOpenBSD was reviewed for 27 years. A $50 model run found what the reviews missed.
01260+ patterns

Identity & access

Who can act as whom. The largest share of real-world impact sits here, and it is where models excel: they enumerate every object, role and session path a human tester would sample.

Book an ExploitOps Review
01

Object ownership on every endpoint

Each ID a user can supply is tested as another user. Orders, invoices, files, messages, exports.

02

Session and token lifecycle

Expiry, rotation, revocation on logout and password change, reuse across devices.

03

Privilege boundaries

Admin, support and billing paths reached from an ordinary account; role changes through indirect routes.

04

Third-party sign-in and OAuth

Token scope, refresh handling, and what a connected app can reach once trusted.

Example rules, in plain English
A user must never be able to act on another user's account.
A revoked session must stop working everywhere within one minute.
No connected app may read more than the scope it was granted.
Seen on the record · Hugging Face, July 2026Stolen credentials chained to root on a production server, with no human steering.
02140+ patterns

Spend & resource abuse

Your product spends money on behalf of each user: model calls, compute, messages, storage. We test how much of that a stranger can spend without paying.

Book an ExploitOps Review
01

Metering and quotas

Limits per user, per key and per organisation, and the paths that bypass them.

02

AI feature exposure

Prompt endpoints callable without the intended product flow; model choice, context size and output length under attacker control.

03

Free-tier economics

What a script can extract from a trial account, and how many trial accounts it can hold.

04

Cost alerting

Whether an anomaly in spend is noticed in minutes or in the monthly invoice.

Example rules, in plain English
No account may spend more than its plan allows, by any route.
A prompt endpoint must be reachable only through the product that owns it.
A spend anomaly must page a human within fifteen minutes.
Seen on the record · Every agent incident, 2026Every agent incident this year ran on someone else's compute, uninvited.
03310+ patterns

Data exposure

Where data appears that nobody intended: responses, logs, headers, error pages, environment variables, third-party calls. The most common category and the one most often missed by review.

Book an ExploitOps Review
01

Over-broad API responses

Fields returned that the interface never shows: emails, internal IDs, tokens, other users' records.

02

Logs, errors and debug paths

What a stack trace, a verbose 500, or a leftover debug flag reveals.

03

Secrets in configuration

Environment variables, build artefacts and client bundles checked for keys and credentials.

04

Third-party data flow

What each integration receives, and whether it needs it.

Example rules, in plain English
A response must contain only the fields the screen displays.
No secret may exist in a client bundle, log line or error page.
An integration must receive only the data its function requires.
Seen on the record · Vercel, April 2026Plaintext environment variables read through a trusted third-party integration.
04120+ patterns

Automation & fraud

Signups, resets, checkouts and referrals at a scale no human operates at. Models make the scripting trivial; we test whether the product notices.

Book an ExploitOps Review
01

Signup and verification loops

Disposable identities, verification bypass, referral and promo abuse.

02

Password and account recovery

Reset flows, OTP handling, enumeration of valid accounts.

03

Transaction integrity

Price, quantity and currency tampering; replayed or reordered requests.

04

Rate and behaviour limits

Whether limits exist, whether they hold under distribution, and whether they alert.

Example rules, in plain English
A single actor must not be able to create more than N accounts an hour.
A price must be computed server-side, never accepted from the client.
A recovery flow must not reveal whether an account exists.
Seen on the record · Anthropic evaluation runs, 2026Agents coordinating thousands of actions across production systems before anyone was called.
0590+ patterns

Availability

What it takes to slow or stop the product. Often far less than expected: one expensive query, one unbounded upload, two crafted packets.

Book an ExploitOps Review
01

Expensive operations

Searches, exports, reports and AI calls that cost far more to serve than to request.

02

Unbounded inputs

Upload size, pagination limits, recursion depth, regular-expression behaviour.

03

Dependency and platform faults

How the product behaves when a provider, queue or database degrades.

04

Recovery

Time to detect, time to restore, and whether either is measured.

Example rules, in plain English
No single request may consume more than a fixed budget of compute.
Every input must have a documented upper bound, enforced server-side.
Loss of any one provider must degrade the product, not stop it.
Seen on the record · OpenBSD, April 2026A 27-year-old flaw in a TCP stack, exploitable with two packets, found for under $50.
06280+ patterns

AI-written & agentic code

Generated code passes review and still skips the check. Agents act with the permissions they were given, plus whatever a prompt can talk them into. We test the behaviour of what shipped, whoever wrote it.

Book an ExploitOps Review
01

Generated handlers

Endpoints written by assistants checked for the ownership, validation and rate limits that were assumed rather than written.

02

Agent permissions

What each agent, tool and MCP server can reach, and whether that is more than its task needs.

03

Prompt injection paths

Content the agent reads that an outsider controls: issues, documents, web pages, emails.

04

Change velocity

Whether the rules run on every release, because the release cadence is now measured in hours.

Example rules, in plain English
Every handler must enforce ownership regardless of who or what wrote it.
An agent must hold only the permissions its current task requires.
Content an outsider controls must never become an instruction.
Seen on the record · Black Hat, August 2026Coding agents from three major labs hijacked through a single crafted GitHub issue.