Furusato Choice Breach: 4,454,097 Donor Records and What to Segment

On 17 October 2026 an attacker got into Furusato Choice, the hometown tax donation portal run by Trustbank. Trustbank says 4,454,097 member records were taken: name, email, address, phone, hashed password and each donor's tax deduction estimate. Donors should change any reused password now. Platform teams should review bulk read limits and step up checks.

This post sets out what Trustbank has said in its official notices, what municipalities and the press added, and what the disclosures do and do not tell defenders. It also keeps two events apart that are easy to blur together: the 17 October intrusion, and a separate Amazon Pay display bug that Trustbank disclosed on 5 October. They have different causes, different data, different numbers of people and different time windows. Neither Trustbank nor anyone else has said they are connected, and we do not suggest they are.

Trustbank has not published the vulnerable component, the attack path, any CVE, or any indicators of compromise. We do not guess at any of them. Where the notices leave a question open, we say so.

What happened

Trustbank Inc. (株式会社トラストバンク), based in Minato, Tokyo, operates Furusato Choice (ふるさとチョイス), a portal through which people make furusato nozei (ふるさと納税) donations to Japanese municipalities and receive thank you gifts. Trustbank is a consolidated subsidiary of Change Holdings, which is trades under securities code 3962, according to a market news report.

According to Trustbank's first report, published on 20 October:

1. On Monday 19 October 2026, Trustbank noticed an access pattern that differed from normal and began checking it.
2. That check confirmed unauthorized access had taken place two days earlier, on Saturday 17 October, and that members' personal information had been taken out of its systems.
3. At 15:50 on 19 October, Trustbank stopped Furusato Choice related services to prevent further damage and keep users safe.
4. On 20 October it reported the leak to the Personal Information Protection Commission (PPC), and it said it planned to file a damage report with the local police on 21 October.

The first report gives the scope as 4,454,097 Furusato Choice member records, with six fields: name, email address, postal address, phone number, hashed password and the donor's tax deduction estimate (寄附控除試算額). Trustbank says the count and fields are what it had confirmed at that point and could change as the investigation continues.

On 23 October a second report added detail for five donors. For those five, more fields were taken than the six listed for everyone else, including two people's saved card details as displayed on a My Page screen. We cover the second report in detail below, because it says more about how the attacker operated than the headline number does.

From 21 October, Trustbank began emailing every registered member, one by one, to say whether their data was taken and which fields. As of the second report, Furusato Choice remains suspended and Trustbank has given no restart date.

Timeline

Times are Japan Standard Time and appear only where a source gives one.

What is still unknown

• The vulnerability. Trustbank refers to "a vulnerability detected through this unauthorized access" and says it is investigating it with outside experts. It has not named the component, the product or the class of flaw.
• How long the attacker had access. The notices name one day, 17 October. They do not say when access began or ended within that day, or whether there were earlier attempts.
• The password hash algorithm. Trustbank says passwords were hashed. It has not said which algorithm, whether a per user salt was used, or what work factor applied.
• How the extra data for five donors was reached. The second report describes a My Page screen being accessed for two members. It does not say how the attacker got into those accounts.
• What the "partial address deletion" entry means. The second report lists, among the extra items for one donor, "partial deletion of address (prefecture name)". It does not explain it.
• Whether any data has appeared anywhere. None of the official sources mention a leak site, a ransom demand or a sale listing.

Two separate events: the 5 October bug and the 17 October intrusion

Because both notices concern Furusato Choice and both came out in October, some readers have run them together. Trustbank presents them as separate events, and the facts in its notices are different on every axis.

Trustbank's 5 October notice says the Amazon Pay bug came from its own processing, not from the Amazon Pay payment function. It is a different kind of failure from an intrusion. We describe it below because it carries its own lessons, not because it explains what happened on 17 October.

Who is affected

Chiba City lists six suspended services: the Furusato Choice site, the Furusato Choice GCF (government crowdfunding) site, the Furusato Choice disaster support site, the corporate Furusato Choice site, the Furusato Choice app and the Choice Pay app. Gunma Prefecture says its prefecture totals are not broken out; the 4,454,097 figure is national.

If you are a member, the most important thing to know is that Trustbank is emailing every member individually from 21 October to say whether their data was taken and which fields. Treat that email as the authoritative answer for your account, and read the warning about fake emails below before you click anything.

Technical details

This section collects every concrete, defender useful value the primary sources publish. It is short on the usual incident indicators because Trustbank has not released any. There is no CVE, no affected product or version, no file hash, no IP address, domain or user agent in any official notice as of 24 October. If you see indicators attributed to this incident elsewhere, check where they came from.

Scope and data fields, as published

The second report: five donors, extra fields

The 23 October report lists the extra items found for five donors. People overlap across rows, so the rows add up to more than five.

The card note is the most informative line in any of the notices. Trustbank says the card details are not kept in its own system. Each time a member opens the saved card page on My Page, Furusato Choice requests them from its payment agency (決済代行会社) and displays them. Trustbank says it confirmed that a third party accessed that page for the two members. It adds that the displayed details alone cannot be used to make a card payment.

That tells defenders three things, read strictly from the notice:

1. For at least two accounts, the attacker reached a page that only renders inside a member's session. Data that is fetched live from a payment agency at page load cannot be in a database dump of Trustbank's own tables. Something requested that page as, or on behalf of, those members.
2. Point history, donation history and date of birth for a handful of people were also reached. These are typical My Page views. The pattern fits a small number of account level views on top of a much larger bulk extraction, though Trustbank has not said so in those words.
3. One entry describes deletion, not exposure. "Partial deletion of address (prefecture name)" for one donor is listed among items that leaked. One plain reading is that the prefecture part of one member's stored address was removed during the incident, which would mean at least one write, not only reads. Trustbank has not explained the entry, so treat this as an open question, not a finding.

What the notices do not tell us is how the attacker got a member session or acted as a member. Possible routes include reused passwords tried against the login, a session token taken from somewhere, or a flaw that lets one request act on another member's records. Trustbank has said none of these. We list them only so that platform teams can check each route on their own systems; we are not suggesting which one applies here.

Why the tax deduction estimate matters

Furusato nozei lets a donor deduct most of a donation from income tax and resident tax. The Ministry of Internal Affairs and Communications (MIC) explains the calculation: the deduction is based on the donation minus 2,000 yen, and the special resident tax portion is capped at 20 percent of the donor's income based resident tax. Because the most a donor can usefully give rises with income, portals offer calculators that estimate a donor's ceiling from income and family details.

A stored "tax deduction estimate" therefore works as a rough proxy for a donor's income bracket. Paired with a name, postal address, phone and email, it lets a fraudster sort 4.4 million people by likely income and write messages that look like they come from a tax office or a municipality. That is why the targeted phishing warnings from Trustbank and from municipalities are not boilerplate in this case.

The Amazon Pay bug, technically (separate event)

The 5 October notice gives a clear root cause for the separate bug, and it is a common one:

• Where: the step that restores a donor's in progress application after they come back from Amazon Pay authentication.
• Defect: when the user identifying information could not be obtained, the code did not check for that case properly. It should have stopped. Instead it could fetch another user's application data.
• Effect: application data containing personal information became viewable in a different user's browser in 254 cases between 13 Nov 2025 and 7 Sep 2026. Fields that may have been exposed: name, address, phone number, email, gift delivery details and similar.
• Spread: of the 254, 19 progressed to the application screen and 6 to payment. Trustbank says all 6 payments were made with the operating user's own Amazon account and no fraudulent payment was found.
• Fix: the system now stops processing when the user identifier is missing or inaccurate. Amazon Pay donations were paused from 7 Sep 18:22 to 8 Sep 14:03 JST.

This is a fail open bug in state restoration across a redirect. It is not an attack, and Trustbank says the payment function itself was not at fault.

How a donation platform gets to 4.4 million records

Trustbank has not described its architecture, so this section is about the general shape of large consumer platforms, not about Furusato Choice in particular.

A portal like this usually has three kinds of read paths into member data:

1. Member self service. A logged in member sees their own profile, history and saved cards. Each request touches one member's rows.
2. Operator and support tools. Staff look members up, fix addresses and handle complaints. Each request touches a few rows, but the tool can reach any member.
3. Batch and integration jobs. Exports to partners, mailing list builds, tax receipt runs and analytics. These touch every row, often on a schedule.

A bulk extraction of millions of rows usually comes through the second or third path, or through a flaw that turns the first path into a loop over every member ID. Whatever the route, the useful defensive questions are the same:

• Which identities, human or machine, can read every member's row?
• Is there a limit on how many distinct members one identity can read per hour, and does anything alert when it is exceeded?
• Are the most sensitive views (saved cards, tax estimates, date of birth) behind a second check, or does an ordinary session reach them?
• Can an operator or batch identity also write member data, and is every write logged with who made it?

Trustbank caught this on day two from an access pattern that looked wrong. That is a detection that worked. The rest of this post is about shrinking what such a pattern can reach before it is noticed.

What to do now

If you are a Furusato Choice member

1. Read the email from Trustbank about your account, but do not click links in any message about this incident. Go to the Trustbank newsroom by typing the address yourself.
2. Change the password on every other service where you used the same email and password. This is Trustbank's main request. Hashing slows an attacker down, but weak or common passwords can still be recovered from many hash schemes.
3. Turn on two step login for your email account first, then for banks, card issuers and shopping sites.
4. Expect convincing messages. The attacker has your name, address, phone and an estimate tied to your income. Be wary of calls, texts, letters or emails about tax refunds, donation receipts or gift deliveries, even if they quote your real details.
5. If you were one of the five donors contacted individually, review your card statements. Trustbank says the card details shown on the page cannot be used to pay on their own, but watch for phishing that quotes your last four digits to seem genuine.
6. For your donation tax filings, keep your own records of donations made this year. Trustbank has not said when My Page will return.

If you run a consumer platform with member accounts

These checks are generic. Adapt the commands to your stack.

1. Find who can read every member. List service accounts and database roles with read access to the members table. In PostgreSQL:

SELECT grantee, privilege_type
FROM information_schema.role_table_grants
WHERE table_name = 'members'
ORDER BY grantee;

Any role here that a web request can reach should be questioned. A web tier should not be able to run an unbounded select over all members.

2. Measure distinct members per identity. Count how many different member IDs each session or API key touched in an hour. With JSON access logs:

jq -r 'select(.path | test("^/api/members/")) | [.session_id, .member_id, (.ts[0:13])] | @tsv' access.log \
  | sort -u \
  | awk -F'\t' '{c[$1"\t"$3]++} END {for (k in c) if (c[k] > 50) print c[k], k}' \
  | sort -rn | head

A member session that touches more than a handful of member IDs in an hour is either a bug or an attack. Set the threshold from your own baseline.

3. Cap result sizes at the database. For the web tier's role:

ALTER ROLE web_app SET statement_timeout = '5s';

Pair it with pagination limits in code so that no single request returns more than one page of members.

4. Rate limit member data endpoints at the edge. In nginx:

limit_req_zone $binary_remote_addr zone=member_api:10m rate=10r/s;

location /api/members/ {
    limit_req zone=member_api burst=20 nodelay;
    proxy_pass http://app;
}

IP limits alone do not stop distributed reads. Add a per session or per API key limit in the application as well.

5. Check your password hash inventory. Find out how many members still have legacy hashes. If hashes carry a prefix:

SELECT substring(password_hash from 1 for 4) AS scheme, count(*)
FROM members
GROUP BY 1
ORDER BY 2 DESC;

Current OWASP guidance prefers Argon2id with at least 19 MiB of memory, two iterations and parallelism of one; scrypt where Argon2id is unavailable; and bcrypt with a work factor of 10 or more for legacy systems. Rehash on next login and plan a forced reset for accounts that never log in.

6. Put sensitive views behind step up. Saved cards, tax estimates and date of birth should ask for a fresh second factor or a recent password entry, not only a valid session cookie. Log every view with session ID and source.

7. Block breached passwords at reset. NIST SP 800-63B requires verifiers to compare new passwords against a blocklist that includes passwords from previous breaches, and to force a change when there is evidence an authenticator is compromised. After a breach, a forced reset with a blocklist check is the strongest single step for your own members.

8. Test state restore after redirects. If you hand users off to a payment or identity provider and restore their session on return, write a test that returns with no user identifier, a wrong one and an expired one. Every case should stop and ask the user to start again. This is the lesson of the separate Amazon Pay bug.

9. Log writes as carefully as reads. If one entry in an incident report says data was deleted, you need to know which identity made the change and when. Make sure member data writes carry an actor ID and are kept long enough to support an investigation.

10. Rehearse partner suspension. Chiba and Gunma both describe donations stopping across multiple sites and partner portals at once. If you supply a backend to partner brands, decide in advance how you will tell each partner, what their users will see and who can restart which piece.

If you are a municipality or a partner portal

• Keep a list of every portal and partner through which you receive donations, and the contract contact for each.
• Publish your own notice quickly, as Chiba, Gunma and Shiga did, and point donors to other portals that are still open.
• Ask your operator for the incident timeline, fields affected and the number of donors to your municipality, in writing. Gunma notes the breakdown by prefecture has not been published.
• Review what personal data you receive back from the portal, where it is stored and who can read it.

What changed since the first reports

• 19 Oct: the only public fact was a suspected intrusion and a service stop. No count, no fields.
• 20 Oct: Trustbank confirmed a leak, gave the 4,454,097 count, listed six fields, and reported to the PPC. It also asked members to change passwords reused elsewhere.
• 21 Oct onward: individual member emails started. Municipalities posted notices, and Gunma listed 12 partner portals through which its donations are also paused.
• 23 Oct: the second report showed that for five donors the attacker reached more than the bulk fields, including the live fetched saved card page for two. This moved the picture from a pure data extraction to one that also included account level access for a few members.

What has not changed: no vulnerability has been named, no restart date has been set, and the password hash scheme remains undisclosed.

Open questions

1. What was the vulnerability Trustbank says it detected through the intrusion, and has it been fixed?
2. Was the bulk extraction and the account level access the same route, or two?
3. What does "partial deletion of address (prefecture name)" mean for the one donor listed? Were any other records changed?
4. Which hash algorithm and settings protected the passwords?
5. Will Trustbank force a password reset for all members when services return, beyond asking people to change reused passwords elsewhere?
6. Were partner portals' own member databases involved, or only Furusato Choice member information?
7. Will the count of 4,454,097 change as the investigation continues, as Trustbank has said it might?
8. Under the PPC rules, a confirmed report for a leak that may involve an unauthorized purpose is due within 60 days of discovery. Will Trustbank publish the root cause when it files that report?

What would have helped

None of what follows is a judgement on Trustbank. It detected an unusual pattern within two days, stopped every related service, reported to the regulator within a day and began notifying every member individually. The question for everyone else is what makes the same class of event smaller on their own platforms.

Practices any team can use

• Segment member data by sensitivity. Keep contact details, credentials, payment views and tax related estimates in separate stores or at least separate tables with separate roles. A flaw in one path should not return all four.
• Limit who can read everyone. Very few identities should be able to read all members at once. Batch jobs that need full access should run on a separate network path with their own credentials, never from the web tier.
• Cap and alert on bulk reads. Set per identity limits on distinct members read per hour and alert when they are crossed. Trustbank's detection came from an unusual access pattern; earlier, tighter thresholds give earlier alerts.
• Use a modern password hash and plan the reset. Argon2id at OWASP's settings or better. Have a ready made forced reset flow, with a breached password blocklist, so that it can run the day you need it.
• Step up for sensitive views. Saved cards, tax estimates and birth dates should require a fresh second factor. This limits what a hijacked session can see.
• Fail closed on missing identity. Any code that restores state after a redirect, or looks a user up from a token, must stop when the identifier is missing or wrong. This is the direct lesson of the 5 October bug, and the OWASP Authorization Cheat Sheet makes the same point: validate permissions on every request.
• Log reads and writes with an actor ID. You cannot scope an incident from aggregate logs. Record which member records each session or job touched and every change it made.
• Know your partners. Keep a current list of partner sites that sit on your backend, what data they can reach, and how to suspend each one.
• Keep the dependency layer patched. Many breaches start at a known flaw in a web framework, library or base image. Shortening the time between an advisory and a rebuild removes one class of entry.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists, in two modes: an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases, and it covers seven package ecosystems. Gold Open Source (gold.safeguard.sh, free, no login) is searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, with a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) supplies hardened drop in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages; an artifact loses its badge if it regresses.

To be plain about the limits: Trustbank has not said what the vulnerability was, so nobody can say whether it sat in an open source package, in custom application code, in configuration or in a vendor product. Safeguard has no advisory for it and no patched build of anything related to it. Where these capabilities help is in the layer every consumer platform shares: the frameworks, libraries and base images its web tier is built from. Pulling patched, signed components from a curated source and rebuilding fast when an advisory lands removes one way in, so that the review of access control, session handling and bulk read limits can focus on the rest.

Where Safeguard fits

Honest scope first: Safeguard would not have prevented this incident. Nothing in Safeguard's scanning would detect a bulk extraction in progress, decide which identities can read every member, or check a password hash scheme. Those are application design and runtime monitoring questions.

What Safeguard does cover, at GA:

• Dependency and image scanning of the repositories and container images that make up a web platform: safeguard scan --dir . for a repository, safeguard scan --image <name> for an image and safeguard scan --sbom <file> for an SBOM, with JSON results under ./output. For a platform that serves partner brands, scanning every service that touches member data gives one list of components to watch.
• Component search across projects: the platform shows which projects contain a given component and version, so when an advisory lands for a framework your member API uses, you can see every place it ships.
• Vulnerability matching and reachability analysis, to rank the vulnerable code paths your application actually calls first.
• Policies and gates evaluated in the platform, so a build of an internet facing service with a known exploited vulnerability can be blocked or held for approval.
• Autonomous remediation with tested fix pull requests, which ships off by default.
• The Safeguard CLI assistant, which can edit code and configuration and run commands only with your approval, under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. You could ask it to add a per session rate limit to a member API, write the fail closed test for a redirect handler, or add an actor ID to member write logs, and approve each change as it is made.

Where Safeguard does not help: it does not monitor production traffic, does not replace a web application firewall or anomaly detection, does not manage password hashing or session tokens, and does not see inside a payment agency's systems.

Common mistakes and troubleshooting

• Treating the two October events as one. The 5 October Amazon Pay bug affected 254 cases over ten months and has been fixed. The 17 October intrusion affected 4,454,097 records on one day and is still under investigation. Mixing them leads to wrong conclusions about both.
• Assuming hashed means safe. Hashing protects strong passwords well and weak ones less, depending on the algorithm. Reused or common passwords should be changed everywhere.
• Only rate limiting by IP. A distributed bulk read can stay under every per IP limit. Limit per session, per API key and per identity as well.
• Putting sensitive views behind a session cookie only. A session can be stolen or borrowed. Ask for a fresh factor before showing saved cards or tax data.
• Ignoring writes in the logs. If your logs show reads but not writes, you cannot answer whether data was altered.
• Restoring state on the return trip without checks. A missing user ID on return from a payment or login provider should stop the flow, not pick a default.
• Forgetting the partner portals. If partners build on your backend, their users may see your outage and your phishing wave even if their own data was not touched.
• Waiting for a CVE before acting. Trustbank has not published one, and may never. Your own access control and logging reviews do not need it.

FAQ

What happened at Furusato Choice?

On 17 October 2026, according to Trustbank, a third party accessed Furusato Choice member information without authorization. Trustbank noticed an unusual access pattern on 19 October, stopped related services at 15:50 that day, and on 20 October said 4,454,097 member records had been taken.

What data was taken?

For all affected records: name, email, postal address, phone, hashed password and tax deduction estimate. For five donors, more items were taken, including point history, donation history, date of birth, a delivery address, and for two of them card last four digits, cardholder name and expiry as displayed on My Page.

Were full card numbers taken?

Trustbank says card numbers are not stored in its system. For two members, a third party accessed the page that fetches card details live from the payment agency. Those details are the last four digits, name and expiry, which Trustbank says cannot be used to pay on their own.

Is this the same as the Amazon Pay problem?

No. On 5 October Trustbank disclosed a separate bug: from 13 Nov 2025 to 7 Sep 2026, 254 cases where one user's application data could appear in another user's browser after Amazon Pay authentication. That was a code defect, fixed in September. The 17 October event is an intrusion by a third party.

What was the vulnerability?

Trustbank has not said. It refers to a vulnerability detected through the unauthorized access and says it is investigating with outside experts. No CVE, product or version has been published.

Should I change my Furusato Choice password?

Services are suspended, so you cannot right now. Change the password on any other service where you used the same email and password, as Trustbank asks, and turn on two step login there.

Why is the tax deduction estimate sensitive?

The amount a donor can usefully give depends on income, so a stored estimate hints at income level. Combined with name, address and phone, it can make fraud more targeted and more convincing.

Are partner portals affected?

Gunma Prefecture lists 12 partner portals through which its donations are suspended alongside Furusato Choice. No official source says those portals' own member data was taken. Check each portal's notices for your account.

When will Furusato Choice come back?

Trustbank has not given a date. It says it will decide after confirming safety and will announce the restart.

Would Safeguard have prevented this?

No. The cause has not been disclosed, and the defences that matter most here are access control, bulk read limits, step up checks and logging. Safeguard helps keep the open source components and images of a platform patched and tracked, which removes one class of entry.

Fix it without waiting for upstream

Trustbank has not said whether an open source component played any part in this intrusion. For any platform holding millions of member records, though, the open source layer underneath the web tier is one of the few parts a team can keep current on its own schedule.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows Furusato Choice, Trustbank or their systems. Each is a real Safeguard session, and each intro says how the same flow would apply to a consumer platform that holds member data.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For a member API, you would run /scan . in its repository, then ask the assistant to add a per session limit on distinct members read and a test that a redirect handler stops when the user ID is missing, approving each edit and command as it runs.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. A platform team could pick the folder holding its member service, ask for the password hashing settings and the saved card endpoint to be reviewed against current guidance, and approve or deny each proposed change itself.

Click through it at your own pace, or open it full screen.

This real Android session sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. If an advisory lands at night for a framework your member API uses, the on call engineer could approve the dependency bump and test run from a phone, and deny anything that touches production configuration until a second person has looked.

Click through it at your own pace, or open it full screen.

To try it on your own services, download Safeguard and follow the CLI docs. For other breaches in Japan this month, see the Japan breach wave involving Yamato, Nikkei and FANCL. For partner and supplier exposure, read our post on the IDCF Cloud ransomware incident and third party risk, and for the wider month, October 2026 security incidents and what would have helped.

Quick check

Sources

• Trustbank: Notice of temporary service suspension due to suspected unauthorized access (19 Oct 2026, Japanese)
• Trustbank: Apology and notice regarding external leak of donor information due to unauthorized access (20 Oct 2026, Japanese)
• Trustbank: Apology and notice regarding external leak of donor information, 2nd report (23 Oct 2026, Japanese)
• Trustbank: Apology and notice regarding personal information leak in Furusato Choice, Amazon Pay issue (5 Oct 2026, Japanese)
• Furusato Choice: Important notice shown on the suspended site (Japanese)
• Chiba City: Detection of unauthorized access at Furusato Choice (updated 21 Oct 2026, Japanese)
• Gunma Prefecture: Service suspension and warning after unauthorized access at Furusato Choice (updated 22 Oct 2026, Japanese)
• Shiga Prefecture: Suspected unauthorized access at Furusato Choice (20 Oct 2026, Japanese)
• Personal Information Protection Commission: Reporting leaks of personal data (Japanese)
• Ministry of Internal Affairs and Communications: Furusato nozei tax deductions (Japanese)
• Impress Watch: Furusato Choice leaks 4.45 million records including tax deduction estimates (Japanese)
• Money Post (Fisco): Change HD shares fall sharply after disclosure of personal data leak (21 Oct 2026, Japanese)
• OANDA Lab market news: Personal information leaked at Furusato Choice (20 Oct 2026, Japanese)
• KonBriefing: Cyber attacks list, October 2026 entries
• OWASP Password Storage Cheat Sheet
• OWASP Authorization Cheat Sheet
• OWASP Credential Stuffing Prevention Cheat Sheet
• NIST SP 800-63B: Digital Identity Guidelines, Authentication and Authenticator Management

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.