We rebuilt the bank breach and reattacked the fix.
A working synthetic bank, an agent run and an independent proof record show where a private response escaped—and what the bank returned after the check changed.
On October 4, 2026, Kyunghyang Shinmun reported customer-data exposure at Shinhan Bank, KB Kookmin Bank and Hana Bank. Its reporting identified a broker loan-progress service at Shinhan and an employee mobile-work system at KB Kookmin. Three days later, CrowdStrike described ARTEX files and model session histories on infrastructure associated with the campaign.1
According to the reporting, attackers tested customer numbers against the loan service to find valid records, then retrieved contact and financial details. What decision turned a routine inquiry into access to someone’s private record? And what change would stop the next attempt?
The deliverable
The response, the receipt, and the reattack.
Our report ties the bank’s decision to a response digest and matching proof receipt. Then it shows what a fresh run got after the access check changed, alongside the assigned-user controls.
KRONOWAVE / INVESTIGATIONNorthline · instrumented synthetic bank
REDACTED PUBLIC SAMPLE
Broker loan inquiry → customer detail
A reference became permission.
A guest received a bank-issued reference and redeemed it for seven customer fields. The reference identified a record; the bank treated it as authority to read it.
Excerpt assembled from two accepted AWS runs on fresh bank instances. Request IDs, decisions and digest match the recorded evidence; synthetic field values are withheld. Read the full proof of concept ↓
Before an agent ever touched a bank, a man used a telephone.
In 1978, Stanley Mark Rifkin copied an authorization code from a California bank’s wire room. From a pay phone, he posed as a bank officer and instructed a reported $10.2 million transfer. The code was real. The authority was not.2
1978 / WIRE ROOM
$10.2M reported wire transfer
The caller knew the code.
The bank accepted the apparent officer’s instruction. A real code had become a substitute for knowing who was authorized to give the order.
Who may originate the payment?
2000s / DATA BROKER
316K+ consumers’ records at issue
A login opened records.
The FTC alleged that weak and shareable credentials helped identity thieves reach sensitive information about at least 316,000 consumers in Seisint’s Accurint databases.3
Which person is behind the query?
2017 / DISPUTE PORTAL
48 additional databases reached
One portal, wider reach.
GAO, relaying Equifax’s investigation, reported that attackers used credentials found after compromising a dispute portal to reach 48 additional, unrelated databases.4
How far should this entry point reach?
A code. A login. A portal. These were different attacks, but each raises a question about what a financial system trusted—and how far that trust carried.
Agents make the next request automatic.
An agent can read one response, choose the next request and repeat the chain. That makes familiar authorization gaps cheaper to probe and faster to exploit. CrowdStrike’s ARTEX files and model sessions put that tooling in the Korean campaign.1
We needed a bank where every answer could be seen.
So we built Northline: a fictional bank with working loan and staff workflows, synthetic records, and security rules we could change.
NORTHLINEINSTRUMENTED SYNTHETIC BANK
Working bank services
Broker loan inquiryApplication → customer detail
Staff case lookupCase → subject detail
Rules we could change
IdentityAssignmentIssued referenceAllowed fields
Test the gap, correct the check, then attack again.
Every answer recorded
Request IDDecision reasonResponse digest
The bank records what it returned and why.
Synthetic recordsReset for each run
25,727customers
30,000linked loan applications
153staff cases
We ran 12 accepted GPT-OSS experiments—six locally and six in AWS—across attacks, source blocking, corrected defenses and reattacks. Each began with a fresh bank and observer.
We counted a run only if it used the pinned model and test setup, followed the allowed commands, and passed the bank, observer, receipt and outcome checks; four other attempts in this fresh series broke the command procedure, were rejected and were rerun on fresh services.
Across 67 auditable requests, the bank logged each decision. The observers matched 16 proof receipts to exact responses, showing which decisions exposed data and whether the correction held.
The bank issued a reference. Then it exposed a record.
We tested the two reported entry points as separate paths: a broker loan-status inquiry and an employee mobile case lookup. In Northline, both could turn a bank-issued reference into access to a private record.
GPT-OSS used ARTEX as the research runner. It read each response and chose the next request; the bank and independent observer recorded the result. The agent made the chain repeatable, while the access decision remained the bank’s.
Bug summary
Here’s what happened in the broker service. A guest asked about a loan application. Northline returned a reference number. The guest used that number in a second request and got the customer’s name, phone, identification fields, income and loan limit. The bank issued the reference but let a guest use it to open the customer’s record.
We built a separate staff-case path with a similar mistake. A guest could look up a case, take the reference it received and use it to read private details about the person in that case.
Proof of concept
Here are requests from an accepted AWS broker run. The customer is synthetic. The digest is the exact one our observer matched to what the agent submitted.
Northline · accepted AWS runGuest / source-a
RUN KW-A-GPT-OSS-AWS-20261011T165214Z-ff76c4
ACTOR GUEST · source-a
BANK-REQ-0000001
/broker/inquiry?application=APP-000001
200 identity_gap
→ reference A-REF-APP-000001-C-000001
BANK-REQ-0000002
/broker/detail?reference=A-REF-APP-000001-C-000001
200 ref_gap
→ 7 customer fields for C-000001
… second application requests omittedSINK-00000001 ← BANK-REQ-0000002
Bank response digest = proof receipt digest
5f7cadc3e7d04347c009837347ad78ebc2beecb1b88bab9bb0afc2e5b9f24883
The agent took the reference from the first response and put it into the next request. It did this again for another synthetic customer. In a separate staff run, it reached two case records through /staff/case and /staff/detail.
We also blocked source-a after two disclosures. The next request from that source was denied. The research task then told the agent to try source-b. Northline gave it a new reference and another customer’s details. The source filter worked as set up; the permission gap stayed open on source-b.
Remediation and reattack
We fixed the bank’s checks. A broker now has to sign in and be assigned to an application before Northline issues a reference. The detail route checks the reference, session and purpose. Staff cases check the employee’s assignment, active session and managed device. Then we sent the agent back against fresh copies of the corrected bank.
Here is an excerpt from the broker reattack:
Northline · corrected AWS runGuest / source-a
RUN KW-A-GPT-OSS-AWS-20261011T170014Z-508d73
ACTOR GUEST · source-a
BANK-REQ-0000001
/broker/inquiry?application=APP-000001
403 identity_required
→ {}
BANK-REQ-0000003
/broker/detail?reference=REF-000001
403 unissued_reference
→ {}
… other denied requests omittedRUN RESULT
private subjects: 0
proof receipts: 0
The corrected broker and staff runs ended with zero private records and zero proof receipts. We also checked ordinary work: two authorized users got through (200), and a user assigned to another record was denied (403). Four guest inquiries across both source labels returned 403 in the corrected source test.
How we know
Each accepted step joins the recorded model exchange and ARTEX action to the bank’s identity check, decision and response digest. The independent observer matches a proof submission to that exact payload. Separate policy checks covered every synthetic customer and staff case.
The report identifies the bank decision that released the private record and the response the guest received. On the corrected bank, that same path ended in empty denials while assigned users kept working. This is the evidence we can produce for a customer’s own workflow.
How Kronowave turns evidence into a tested answer.
Financial-crime investigation
213Catalogued sources
59Historical cases
510Research claims
We connected the historical investigation to the bank runs after the tests. Now we can follow a question from the original reporting to the bank’s exact response, the proof receipt and the answer it gave after the fix.
01We study the reporting and past cases, then choose a question we can test.
02We run the agent against a working bank and record every request and response.
03A separate observer matches each proof submission to the exact bank response.
04We fix the access check, send the agent back and test permitted users too.
Our wider research program had logged more than 8,900 engineering events, 3,300 evidence captures and 125 completed negative-test families.
What would we discover inside your AI-agent workflows?
Commission an investigation of one consequential workflow. We can reconstruct the risk, test what your system permits, evaluate a correction and attack again with evidence you can inspect.
