Technical Report: From an AI "Code Execution" Tool to the Theft of Nearly All of Our Production Secrets

Enabler Inc. (operator of teai) / Published November 9, 2026 / All times are JST (UTC+9)

To Our Customers (Please Read First)

This report is written for engineers. What we ask of customers, and a detailed explanation of the information that may have been read, are in our notice. The key points are below.

Information that may have been read

• For everyone registered with teai (up to 2,536 people): names and email addresses, usage records, and passwords. (Passwords are not stored as-is. Of the 69 people who log in with a password, the passwords of the 47 people stored under our old scheme are easier to guess when combined with the leaked key. The remaining 22 people's passwords are now stored under a stronger scheme, but because we are still confirming when they were switched, we are treating them as equally easy to guess. We will also notify all 69 people individually.) For some people, conversations and AI memories; and the contents of inquiries sent to our support. We are treating the copy of our database as having been taken.
• Information we hold with our payment processor (Stripe): names, email addresses, billing and shipping addresses, phone numbers (only for people who entered one), card brand and last four digits, expiration dates, and payment history. This includes customers of our services other than teai. We do not store full card numbers.
• The recipients, subject lines, and bodies of emails sent from our services.
• Data we stored in the cloud (Cloudflare) was also read. We are checking whether it included customer information.

We are investigating how much was actually read.

What we ask you to do

1. If you log in with an email address and password, open teai.io yourself and reset your password. If you use the same password anywhere else, change it there too.
2. If you have ever registered another company's API key with teai, regenerate it with that provider. (As of our count on November 9, customers had registered 0 such keys.)
3. If you use Sente, te, or the teai API, create a new API key at teai.io/keys and delete your old keys. On November 21, we will disable all keys that existed before 17:10 on November 9.
4. Do not open links in emails that claim to be from us.

What we have confirmed so far

• API keys issued by teai are stored in an irreversible form. However, because the attacker could write to the database, we cannot rule out that fake keys were added. For that reason, as described in item 3 above, we will disable them all at once on November 21.
• Within the scope we have examined, we have found no tampering with our GitHub repositories or CI (some configuration changes are still being checked). The te installer matched the contents of the repository (verified by SHA-256). We are still verifying the Sente application itself.
• There have been no suspicious refunds of customer payments, and our receiving bank account has not been changed (the attacker's 23 payments were refunded by us).
• For safety, we have ended everyone's web login sessions. Please log in again.

Inquiries: teai.io/contact

Summary

• The AI in teai's chat had a tool that could run shell commands (code_execute). This tool ran as root on the same machine as the service itself. By asking the AI, a user could read the environment variables of the main service process. Those environment variables contained nearly all of our production secrets (about 100).
• Period: 2026-09-08 to 2026-11-09 (when we discovered it). About two months.
• With the secrets that were read, the following happened:
  • The attacker gained direct read/write access to the database
  • Our CEO's account was taken over
  • Data was written to our backup storage (we are treating it as if data was also taken)
  • About 76,000 phishing emails were sent from our domains
  • Usage credits were granted without authorization
• Root causes
  1. An execution environment with no isolation
  2. Keeping all secrets in one place and sharing powerful keys
  3. Relying on the AI's judgment for defense, and not monitoring for anomalies on the side of external services

1. Architecture (at the Time)

• A single Rust (axum) binary ran on a group of Fly.io VMs, with data stored in Turso (libSQL). Backups were replicated to S3 with Litestream.
• Secrets were stored as Fly secrets and loaded into the environment variables of the main process. They included keys for the database, email sending, payments, AI providers, cloud services, the admin API, the master key for data encryption, and even the key used for password verification.
• The chat AI could use more than 50 tools, one of which was code_execute.

How code_execute was built (at the time)

• Where it ran: on the same VM as the main service. The user was the same root as the main service.
• Protections in place: clearing the child process's environment variables, a separate working directory per user, and a time limit.
• Protections missing
  • Process namespace isolation
  • Restricting /proc (hidepid)
  • Running as a separate user
  • A read-only file system
  • Restricting outbound network traffic
• Result: the child process's environment variables were empty, but the main process's environment variables could be read from /proc. The persistent volume (/data) was also readable and writable.
• Output was streamed straight to the screen. Up to about 6,000 characters of tool output were passed to the AI, and the first 500 characters were also shown as-is on the user's screen. Even when the AI refused to summarize, the user still received the raw output.
• In practice, the only thing responsible for refusing dangerous requests was the AI's judgment. The attacker disguised the requests as legitimate work and encoded the output, getting past the AI's judgment.

2. How the Attack Unfolded (Confirmed Facts)

Accounts are identified by letters (A–F).

What the attacker wrote directly to the database: one forged login session and one working table (empty when discovered). (Creating API keys and granting credits were done through the app's own features.) Within the scope we have examined, we have found no sign that customer data was altered. We have not yet finished checking all records.

Money

• E made 23 purchases totaling ¥392,350 with a single Amex card. Because we suspect it is a stolen card, on 11/9 we refunded the full amount to the card and cancelled the attacker's subscription.
• D made purchases totaling ¥7,850 with two Visa cards authenticated with 3-D Secure.
• AI usage fees: of about $6,900 used since 10/29 (compared with the balance we recorded that day), we cannot account for about $4,925. It may have been used with the key leaked on 9/25, and we are investigating.
• There have been no suspicious refunds of customer payments, and our receiving bank account has not been changed (the attacker's 23 payments were refunded by us).

3. Why We Failed to Prevent It

1. We drew the isolation boundary in the wrong place: we thought clearing the child process's environment variables was isolation. As long as it is the same machine and the same user, the main process is visible from /proc.
2. We showed raw output to users: separately from the AI's judgment, tool output flowed straight to the screen.
3. We counted the AI as a defense: AI can be fooled. Defenses should have been placed in permissions, the network, and the file system.
4. We kept all secrets in one place and shared powerful keys
   • All secrets sat in plaintext in the main process's environment variables.
   • A full-permission email-sending key was shared across multiple services, and the payment key was shared across 25 of our apps and 5 Workers (our distribution list covered only 14 of those apps).
5. Admin privileges were also available in chat: in a regular user's chat, only the first 500 characters of tool output appear on screen. We believe the attacker took over our CEO's account because, in our CEO's chat, admin-only tools were also available and the full contents of the environment variables could be received. We had not separated the permissions of the human admin console from the permissions given to the AI.
6. Login sessions were stored in plaintext: anyone with the database key could write an arbitrary login session. This was the direct cause of the account takeover.
7. Old passwords were left in place: in August we switched to a slow hash (argon2), but migration happened only "at the next login." Of the 69 people with passwords, the passwords of the 47 who had not logged in remained in a fast hash with a secret key added (the old scheme), and that key leaked.
8. We did not notice abuse of sign-up and credit grants: accounts could be registered with nonexistent domains or disposable addresses. There were no alerts for grants of 200,000 or 500,000 credits.
9. We were not watching the outside: there was no monitoring for the following anomalies, and we did not notice for about a month.
   • Phishing email sending volume and complaint rate
   • AI usage fees
   • Spikes in cloud permission errors
   • Outbound network traffic (tmate is a tool that connects outward)

4. What We Ask You to Check in Your Own Environment

For those building services that give tools to an AI. Please check these in a test environment (do not try them in production).

• When you run id inside the AI's tool, are you root?
• From inside the tool, can you see processes other than your own? (If ps shows the main service process, isolation is insufficient.)
• From inside the tool, can you communicate with the outside?
• Is even one production secret present in the tool's execution environment?
• Are you returning tool output to users without inspecting it (detection of secret-like strings)?
• Are login sessions and API keys stored as hashes?
• When you changed your password storage scheme, did you force migration for people still on the old scheme?
• Is your database key a single read/write key (have you separated it from a read-only key)?
• When rotating keys, do you confirm that you can actually connect with the new key, and that nothing is still using the old key, before disabling the old key? (We took our own services down by missing these two points.)
• Are your keys for external services separated per service and per purpose, with only the permissions they need?
• Are you monitoring for anomalies on the side of external services (sending volume, complaint rate, usage fees, permission errors)?

Isolation options include microVMs (such as Firecracker), gVisor, and at a minimum process namespace isolation with hidepid=2, plus running as a separate user.

5. Response and Prevention

Our own operational mistakes: from 11/9 16:49 to 17:10, while rotating the database key, we trusted a tool's "success" message at face value, put an invalid value into production, and took the service down for 21 minutes. We changed our procedure to confirm that we can actually connect with the new key before putting it in place.

On the same day, from about 19:00 to 19:31, while cleaning up payment keys, we also disabled a key that was still in use, which stopped payments on 25 of our apps and 5 Workers. Our monitoring detected this at 19:03, and we restored service with new keys at 19:24 and 19:31. Zero payments were completed during this window, and there were no double charges or payments that failed to be applied after being made. (Calls made with an invalid key do not reach the payment processor, so we cannot count how many failed.) We changed our procedure so that, before disabling a key, we now automatically find every server that uses it from our configuration, track non-server destinations in a list, and disable the old key only after confirming the new key works everywhere (this applies from the next rotation; we will test it without touching production by 11/14).

6. Reporting and Notifications

• Personal Information Protection Commission (Japan): we submitted a preliminary report on 11/9. We will submit the final report by 2027-01-07.
• Phishing emails: at 17:50 on 11/9, we reported them to CERT-AgID (Italy), Safeonweb (CCB, Belgium), pagoPA, Orange, and our email-sending provider.
• Payment processor: we made the notification required under our contract on 11/9.

7. As the Makers of Mamori

We build a security watchdog called "Mamori" (守). Even so, we could not prevent this. What Mamori watched was the configuration of devices and servers, and publicly known attack information. It did not watch how applications are built, how secrets are held, or anomalies in external services.

We are publishing this level of detail because we do not want the same thing to happen to others running services built the same way. Traces useful for defense (such as the source addresses that tried the misused keys) will be shared privately with public authorities (CERTs and the police).

Yuki Hamada (CEO, Enabler Inc.)

Related: Notice (what to do) / Technical report / Phishing emails / Contact: teai.io/contact