Products Lemma APIProof issuance & verification platformTrust402Delegate to agents, and transactSealSign-in for the agent era — no keys handed over
Use cases Manufacturing & Critical InfraInspection Record AssuranceFinance & FinTechCounterparty Record VerificationPublic SectorCertificate-less ProceduresHealthcareQualified Worker AssuranceProcurement & Supply ChainSupplier Credential MonitoringMedia & ContentContent AuthenticityService & RetailCross-group IdentityAI Adoption (cross-industry)AI Run GovernanceDevelopers & Agent OpsAgent Authority Control ▸ Browse the use-case index
Pricing
Resources Critical BriefThe frontier of AI × trustBlogThinking and implementation notesDocumentationAPI & specsVerification CenterReal verification & issuance countsAbout usFRAME00, Inc.ContactSales & press inquiriesGlossaryDefinitionsFAQFrequently asked questions
Dashboard ↗ JA
Home / Critical Brief / No. 142
No. 142 Critical Brief · Verifiable Origin

Awa Bank: a test environment kept in use for AI work and other tasks after its purpose ended, and 27,745 customer and shareholder records left in it leaked through outside access (bank disclosure)

No layer re-checks the data and the way in when an environment's use changes

27,745records
Customer and shareholder records leaked; 5,271 include the bank account for dividend payments
03-24→03-25
From an outside security firm's alert to the bank confirming the data was its own and cutting off access
3failings
Admitted by the bank: the environment was not retired, data was not deleted, and protection against unauthorised access did not work well enough
CountryJapan
Incident date2026-03-24
Published2026-09-08
Revised v2.0 · 2026-10-21
AuthorsLemma Critical Team
Contents
  1. 01TL;DR
  2. 02What happened
  3. 03Timeline — disclosure and response
  4. 04Why it wasn’t stopped
  5. 05How to counter this
  6. 06Sources

TL;DR

  1. 01What happened

    On April 3, 2026, Awa Bank (Tokushima, Japan) disclosed that a test environment for its internal information-sharing system (the OA system) had been accessed without authorisation, leaking 27,745 customer and shareholder records. It learned of the leak on March 24 from an outside security firm. A follow-up on June 3 gave the direct cause as someone misusing an ID, password and the like to get in from outside, and admitted failings in the bank’s own controls.

  2. 02Why it was hard to tell

    The environment had not been retired after its development and testing purpose ended; it stayed in use for work such as upgrading systems with AI. Customer data that should have been deleted was still there. It was separated from the systems that handle transactions, but anyone with the ID and password could get in from outside.

  3. 03The missing layer

    It was not the bank but the outside firm that noticed, and only after the leak. What failed was the layer that re-checks the customer data left in an environment, and the way in from outside, when its use changes.

What happened

Who
Awa Bank, based in Tokushima, Japan.
Environment breached
A test environment set up to develop and test the OA system, the bank’s internal information-sharing system. It was separated from the systems handling customer transactions.
Leak
27,745 records in total. 10,872 corporate internet-banking clients as of October 2024 (name or company name, registered email). 11,122 shareholders as of March 31, 2021 (name or company name, address, shareholder number, shares held; 5,271 include the account for dividend payments). 5,751 other customers and contacts (mainly names or company names as of April 2021; 127 include addresses and deposit or loan transaction details). No PINs or passwords.
Cause
Someone misused an ID, password and the like to get into the test environment from outside. How the credentials were obtained, and when the intrusion happened, have not been disclosed.
Failings the bank admitted
(1) The environment should have been retired when its purpose ended but stayed in use for work such as upgrading systems with AI. (2) Customer data should have been deleted promptly after development ended but was not. (3) Protection against unauthorised access did not work well enough.
Discovery
An alert from an outside security firm.
Secondary harm
None confirmed as of June 3.

Glossary
Test environment — An environment kept apart from production for developing and testing systems. Production data is sometimes copied in for testing.
OA system — The bank's internal information-sharing system. The breached environment was set up to develop and test it.

Exhibit 1The chain of events, as far as disclosed

The point to stop it was ②. Re-checking the customer data left in it and the way in from outside when its use changed would have been the chance to delete the data and close the door.

Awa Bank
1
Builds an environment to develop and test the OA system, and puts customer data in it

Separated from transaction systems.

Awa Bank
2
Keeps using it for AI work and more after its purpose ends

Customer data is not deleted.

Unknown party
3
Misuses an ID and password to get in from outside

When, and how the credentials were obtained, not disclosed.

Outside security firm
4
Tells Awa Bank its data may have leaked

2026-03-24.

Timeline — disclosure and response

  • An outside security firm tells the bank its information may have leaked.
  • That night, the bank confirms the leaked data is its own and cuts off access to the environment.
  • First notice: 27,745 records leaked. The bank says it has reported to supervisors and consulted the police.
  • Follow-up: the direct cause, three failings in its controls, measures against recurrence and disciplinary action against executives.

Facts rest on Awa Bank’s first notice and follow-up (primary). When the intrusion happened and how the credentials were obtained have not been disclosed. The bank says it is still investigating with the police; as of October 2026 there has been no third notice.

After disclosure

  • Awa Bank: Will retire the test environment once the police investigation ends, and review all of its information systems.
  • Discipline: The president and senior managing director voluntarily returned 30% of one month’s pay, a managing director’s pay was cut by the same, and staff involved were disciplined under internal rules.

Why it wasn’t stopped

This case was not about a sophisticated intrusion. A test environment past its purpose stayed in use for other work, still holding customer data it should have deleted, open from outside to anyone with an ID and password.

The core of this case
A test environment past its purpose stayed in use for other work, still holding customer data it should have deleted, open from outside to anyone with an ID and password.
Exhibit 2The detection–proof gap

Proof works when an environment's use changes; detection works after a leak surfaces. In between, the environment keeps the name "test environment" while holding customer data and a way in from outside.

Proof layer · absentRe-check the data and the way in when an environment's use changes
The gapCustomer data stayed,
the door stayed open
Detection layer · noticed by outsidersLearn of the leak from outside and cut access
STEP 1
The environment's use changes
STEP 2
Someone gets in from outside
STEP 3
An outside alert arrives
STEP 4
Access cut off

Detection worked, but it was an outside security firm, not the bank, that noticed, and only after the leak. “It is a test environment” and “it holds no customer data and has no way in from outside” are separate facts, yet while the name stayed the same, the second was never re-checked. That distance is the detection–proof gap, and it is a structural one.

The same structure appears in Sumsub (users’ contact details left in a support environment outside the verification core).

How to counter this

When an environment’s use changes, re-check the data in it and the way in from outside. As a rule, don’t put production customer data in development or test environments; if you must, set a date to delete it. Retire environments whose purpose has ended, and if one stays in use, decide afresh, as a new use, which data may be there and who may get in.

Industries and operations to watch

IndustryFinance & FinTech
Banks and other financial institutions holding large amounts of customer information. They increasingly build trial environments to improve efficiency and use AI.
OperationLookup & data access
Copying customer data out of production for development, testing or analysis. Copied data tends to sit somewhere less protected than production.

Do today’s controls close it?

ControlThis caseWhy
ID and password loginIneffectiveSomeone got in by misusing an ID, password and the like.
Separation from transaction systemsPartialTransactions were protected, but copied customer data stayed in the test environment.
Deleting data after development endsIneffectiveData that should have been deleted was not (per the bank).
Intrusion monitoringPartialAn outside security firm noticed, and only after the leak.
ControlsWhat is needed
  1. For each environment, decide and record what it is for and which data may be in it. If production customer data is used, set a date to delete it too.
  2. When the use changes, don’t allow use until data and access are re-checked. Retire environments whose purpose has ended. To use one for other work, decide its permissions and data afresh as a new use.
  3. Record what was checked. Keep each environment’s purpose, the data placed in it, when it was deleted and who can get in from outside, in a form that can later be shown to a third party: in other words, as proof.
CheckChecklist

Three things to confirm in your organisation about development, test and trial environments

  • Can you list the development and test environments that hold production customer data?
  • Who confirms that environments whose purpose has ended have actually been retired?
  • Who can get into them from outside, and what besides an ID and password is checked?

Note: even with use and data re-checked, a stolen ID and password for the decided use can still expose the data within that scope. Re-checking also slows fast-moving work such as AI trials.

Sources

  1. Primary, company disclosure, first noticeAwa Bank “Leak of customer information due to unauthorised access”2026-04-03, Japanese · awabank.co.jp/kojin/news/2026/news20260403a
  2. Primary, company disclosure, follow-upAwa Bank “Leak of customer information due to unauthorised access (follow-up)”2026-06-03, Japanese · awabank.co.jp/kojin/news/2026/news20260603a

References: “The last layer left for cyber defense in the age of AI”

The same method elsewhereSee all 12 "Account takeover" cases Get new cases and checks like these by email

This material is a structured analysis of public information; it is not an audit, diagnosis, or recommendation for any specific organization.

Cite this Brief

Lemma Critical Team. (2026).
"Awa Bank: a test environment kept in use for AI work and other tasks after its purpose ended, and 27,745 customer and shareholder records left in it leaked through outside access (bank disclosure) — No layer re-checks the data and the way in when an environment's use changes".
Lemma Critical Brief No.142. Lemma / FRAME00, Inc.
https://lemma.frame00.com/critical/briefs/142-awa-bank-test-environment-repurposed-leak/
Revision History

Current version: 2.0

Lemma

If it can't be verified,
it doesn't enter your operation.

Lemma attaches cryptographic proofs to data and AI execution, so the receiving side can confirm authenticity without asking the issuer. Detection stays; a proof layer is added in front of it.

Talk to enterprise See the verification center