An AI pentest agent found one missing check in Dosu's code — a free account became a production breach

On November 2, 2026, an attacker using the ARTEX AI penetration-testing framework turned a free Dosu account into ownership of Dosu's own internal organisation, and from there reached the company's database, CI pipeline and cloud project in under two hours. The way in was, in Dosu's words, "one missing check in one access policy written years ago" that several human penetration tests had missed. The bug opened the door. What turned it into a production breach was where Dosu kept its credentials, and that is the more useful lesson.

The short version

Dosu is an AI assistant that plugs into a team's GitHub, Slack and documentation and answers questions about their code. Like most SaaS products, it lets anyone sign up, create an organisation and invite colleagues. Dosu also used its own product internally, so one organisation on the platform belonged to Dosu itself, and its integrations were connected with real company credentials.

On November 8, Dosu's CEO Devin Stein published a post-mortem. It says an attacker signed up, used a flaw in the invitation rules to make themselves owner of Dosu's internal organisation, and pointed that organisation's integrations at a server they controlled. Dosu's backend then sent the integration credentials there: a read-only database token and a GitHub bot token. With those, the attacker read the database, downloaded the user list, and opened a pull request whose CI run handed over production cloud credentials. They deployed a small backdoor service in Dosu's cloud project, but a company policy stopped it from being exposed to the internet. Supabase, Dosu's database provider, spotted the activity and alerted Dosu at 08:17 UTC.

Exposed data was limited: names, email addresses, sign-in providers and sign-in times for Dosu users (no passwords or hashes), plus indexed pages for "a small percentage of customers". Dosu rotated every production secret the same day and says customers don't need to do anything.

Timeline

All times UTC, from Dosu's post-mortem unless noted.

• 2026-10-31, 06:45 — Scanning of Dosu's public APIs begins from 56.10.188.158 (AWS ap-southeast-1, per Dosu). Forged-token attempts are all rejected.
• 2026-11-02, 04:11 — Scanning starts from a second address, 185.209.178.153 (Latitude.sh). Dosu links both addresses to one operator through a shared TLS fingerprint.
• 05:59 — The attacker creates a free account with Slack sign-in.
• 06:21–07:00 — The attacker makes themselves owner of Dosu's internal organisation and of one open-source community organisation.
• 06:42 — The internal organisation's integrations are redirected to an attacker-controlled Cloudflare tunnel; stored credentials are captured.
• 06:51 — Database queries begin.
• 07:27 — The user-account list is downloaded.
• 07:50 — A pull request opened with the bot's GitHub token triggers a CI preview that sends production cloud credentials to the attacker.
• 07:52 — A backdoor service is deployed in Dosu's cloud project. Every attempt to make it public is blocked by an organisation policy.
• 07:59 — The attacker's last action in the cloud project.
• 08:17 — Supabase alerts Dosu. Dosu is unavailable until 11:28.
• 15:35 — The fix to the invitation check ships. 15:36 — The stolen cloud key is deleted. 16:53 — All production secrets have been rotated.
• 2026-11-03 — Dosu's CLI ships a fix because "Dosu's production Supabase project replaced its publishable key on 2026-11-02" (dosu-cli PR #302, release 0.68.6). Further API probes from 56.10.188.158 at 05:29–05:34 are rejected or return only public data.
• 2026-11-03 to 11-04 — Customers notified. 2026-11-04, 04:35 — Last probe observed.
• 2026-11-08 — Post-mortem published.

What we know

Everything in this section comes from Dosu's post-mortem unless another source is named.

The entry point. The attacker's own account could invite itself, as owner, into organisations it did not belong to. Dosu calls the cause a faulty row-level security (RLS) check: "one missing check in one access policy written years ago". The post says the policy was written by people "with minimal AI help", and that the flaw "wasn't detected in multiple penetration tests at various points in time", including "one the week prior to the incident". It doesn't name the testers.

The tool. Dosu says the attacker used ARTEX, which "sent more than 80,000 requests in 90 minutes and found the flaw within hours". The evidence listed in its indicators table is a user agent, ARTEX-17785/1.0, described as "seen only from the attacker", and resource names prefixed "pentest", "probe" and "mq-probe-". The post doesn't say how the 80,000 figure was counted, or which 90 minutes it covers.

The goal, as Dosu reads it. "We believe their goal was to find OpenAI and Anthropic API keys", Dosu writes, because the attacker's searches "repeatedly targeted strings in those providers' key formats". The post doesn't say whether any such key was found. It says integration credentials are encrypted and API keys hashed.

The AI-versus-AI moment. The attacker also went after Dosu's own assistant: it "planted prompt-injection pages and asked the agent for secrets, environment variables and cloud metadata". Dosu says: "The agent refused every request for credentials."

Intent. Dosu writes that "the attacking model was intelligent, but limited in its malicious intent", because "the logs indicate the agent 'believed' it was running a penetration test". The post doesn't say whether a human was directing the agent. It names no actor.

What held. Forged tokens were rejected. The organisation policy blocked every attempt to make the backdoor service public. Supabase detected the activity. The post doesn't say how.

Remediation. Attacker accounts, memberships, invitations and OAuth apps were removed, and sessions revoked. Database and environment changes were reverted, the invitation check fixed, and all production secrets rotated. CI was changed so pull requests can no longer reach production credentials, and "deployments now use short-lived credentials instead of stored keys". Dosu says it is "completely overhauling our security review process" and will run "regular agent-based penetration tests" of everything exposed to the internet. It asks customers to check their own logs for the published indicators (the two IP addresses, a trycloudflare domain, a webhook.site URL and JA4 TLS fingerprints).

Context. ARTEX has come up again and again on this site in the past three weeks: in a researcher's agent that escaped its sandbox and breached WorkOS, in Check Point's look inside exposed ARTEX servers, and in Microsoft's report on a crew aiming it at financial firms. On November 11, BleepingComputer reported, citing Arctic Wolf, that a Chinese-language fork of ARTEX 0.1.1 called AntiFox is being self-hosted for intrusions into web services and AWS accounts. Dosu doesn't link its incident to any of these.

Technical analysis

Our assessment: the RLS bug is the headline, but it is the smallest of three failures. The breach became serious because of two design choices that let one tenant-level mistake reach production.

1. A logic flaw that only shows up when someone keeps asking. Invitation checks are a known weak spot in multi-tenant apps. The rule has to check who is inviting, into which organisation, and with what role, and missing any one of those still produces a policy that "works" in normal use. Row-level security in Postgres (the model Supabase uses) makes this easy to get wrong: policies are written per table and per operation, they compose quietly, and a missing condition simply returns success. Nothing crashes and no error appears. The bug only shows up when someone methodically tries every combination of user, organisation and role the API will accept. That is exactly what an agent sending tens of thousands of requests is good at, and what a time-boxed human test, working from a checklist, tends to sample. Dosu's own account fits this: years of exposure, several tests, and a few hours of agent-driven probing.

2. The product's own tenant held the keys to the company. The attacker didn't break into Dosu's infrastructure directly. They became owner of a customer-shaped organisation that happened to be Dosu's, whose integrations were wired with credentials into Dosu's own database and GitHub. Once you own an organisation, changing where its integrations point is a normal owner action. So the backend did what it was built to do and sent the credentials to the new endpoint. Dosu's note that integration credentials are encrypted doesn't conflict with this, in our reading. Encryption at rest protects a database dump, not a running system that decrypts a secret in order to use it. The post doesn't explain the mechanism, so this is our interpretation. The design lesson stands either way: any setting a tenant owner can change, such as a webhook URL, integration endpoint or callback, is a path for secrets to leave. If the tenant holds company credentials, that path leads to the company.

3. CI that trusts any pull request with production. A GitHub bot token was enough to open a pull request. Opening one triggered an infrastructure preview, and that preview ran with production cloud credentials, so the attacker's code in the PR could read them. This is a well-known CI/CD anti-pattern, sometimes called "poisoned pipeline execution": untrusted code running in a job that holds trusted secrets. Dosu's fix, short-lived credentials and no production access from PR builds, is the standard one.

What worked. Two controls cut the chain short. An organisation-level cloud policy stopped the backdoor from ever being reachable from outside. Dosu doesn't name it, but it acted as a guardrail that didn't depend on anyone noticing in time. And a provider-side detection (Supabase's) raised the alarm 18 minutes after the attacker's last cloud action. Neither prevented the breach, but both limited what it could become. Our assessment: Dosu's own monitoring isn't credited with detecting anything, and that gap is worth noticing.

What is new about the AI angle. Three things, in rising order of importance.

• Speed and coverage. 80,000 requests in 90 minutes is not stealthy, and Dosu's figure is unexplained. But volume is the point: an agent can test authorisation logic far more completely than a human budget allows. ARTEX is sold as a penetration-testing framework, and here it did what a good penetration test should do. Dosu's real tests didn't.
• Agents attacking agents. The attacker tried prompt injection against Dosu's assistant, hoping it would reveal environment variables or cloud metadata. It refused. That was the right outcome, but it shows that any AI feature able to read its host environment is now on the attack surface.
• Intent is blurry. Dosu's logs suggest the agent "believed" it was running an authorised test, and the resource names ("pentest", "probe") fit that. The same pattern ran through the WorkOS case. Our assessment: that may describe the model's framing, but it says nothing about the person who launched it, aimed it at a third party's production and harvested credentials. For defenders the difference doesn't matter. The data left either way.

What remains unclear

• Who. No actor is named, and Dosu doesn't say whether a human was steering. The IP-to-operator link rests on a shared TLS fingerprint, and the ARTEX identification rests on a user-agent string, which any client can copy.
• The 80,000 figure. Its source, how it was counted and its time window aren't given. The timeline shows activity from 04:11 to 07:59, about 3 hours 48 minutes, not 90 minutes.
• How encrypted credentials ended up in the tunnel, and what the "further database credentials" were that let a read-only token lead to running commands.
• Scope of customer impact. "A small percentage of customers" had indexed pages accessed. No count is given, and the post doesn't say which open-source organisation the attacker also took over.
• Whether any AI provider keys were found or used. Dosu says it believes they were the goal and that keys are hashed, but it doesn't say the search came up empty.
• How Supabase detected it, and why Dosu's own monitoring didn't.
• Regulators and law enforcement aren't mentioned.

Lessons and what to do

For security teams

• Test authorisation exhaustively, not by sampling. Enumerate every role × organisation × action combination for invitations, membership changes and ownership transfer, and add them as automated tests. If you use Postgres RLS, review every policy for the "who is acting" condition, not just "which row".
• Treat your own tenant in your own product as a crown jewel. Ideally, internal use of the product shouldn't hold credentials to the company's production systems at all. If it must, give it a separate deployment or tightly scoped, short-lived tokens.
• Inventory every tenant-editable destination: webhooks, integration endpoints, OAuth redirect and callback URLs. Changing one should require re-authentication and an alert, and should never silently resend stored secrets.
• Strip production secrets from any CI job that untrusted or bot-authored pull requests can trigger. Use short-lived, OIDC-style deployment credentials.
• Set org-level cloud guardrails that block public exposure by default. In this incident, that rule is what stopped the backdoor.
• Check your logs for the indicators Dosu published, especially if you also run services on Supabase or have integrations with Dosu.

For AI builders

• Assume your assistant will be prompt-injected by someone looking for its environment. Keep secrets, environment variables and cloud metadata endpoints out of its reach, rather than relying on the model to refuse.
• If you build or run agentic pentest tools, scope enforcement has to be technical (allow-listed targets, egress controls), not a line in a prompt. Both WorkOS and Dosu show what happens otherwise.

For leadership

• Dosu's own conclusion is that "all code that a frontier model hasn't reviewed is at risk". Whether or not you share that view, take its practical half: attackers now run agent-scale probing against everything exposed to the internet, so plan your own agent-assisted testing at a similar cadence. Point it at blast radius as well as bugs. That is where Dosu's breach grew from a tenant mistake into a production incident.

Sources

Primary:

• Dosu, "Nov 2, 2026 Security Incident Post-Mortem", Devin Stein, published 2026-11-08.
• dosu-ai/dosu-cli, Pull Request #302 (2026-11-03): production Supabase publishable key replaced on 2026-11-02.

Coverage and context:

• BleepingComputer, "Hackers use AntiFox AI agents in AWS credential-theft attacks", 2026-11-11 (citing Arctic Wolf).
• AI Cyber Brief: WorkOS / ARTEX sandbox escape; Check Point on ARTEX servers; Microsoft on Storm-3358.