We pentested ClassKasa with Claude Code and an open-source toolkit: 8 fixes, 3 of them High

Before you connect a class bank account to anything, it is fair to ask whether anyone tried to break it first. For ClassKasa, the answer includes a pentest we ran ourselves in May 2026. This is what we used, what it led to, and what it does not prove.

What pentest-ai-agents is

pentest-ai-agents is an open-source toolkit by 0xSteph, released under the MIT license. Its README describes it as a collection of 50 Claude Code subagents for penetration testing. (The install section of the same README says 52; we quote the headline wording.) A listing of it is also on Skillselion.

A "subagent" here is a specialist role you hand to Claude Code: one that thinks like a web tester, one that reads scan output, one that plans an attack path.

Two tiers, and why that matters

According to the README the agents come in two kinds:

• Tier 1, advisory. You paste tool output or ask methodology questions and get analysis and recommendations. Nothing is run against anything.
• Tier 2, execution-capable. These require a declared scope. You state which targets you are authorized to test, the agent checks every target against that scope, and Claude Code shows you each command for approval before it runs.

The README is explicit that the toolkit is for authorized security testing only, with proper written authorization and a defined scope. This test was against ClassKasa, which we run.

What happened in May 2026

The owner ran an authorized pentest of ClassKasa with Claude Code and this toolkit. The results shipped in two releases, both dated 2026-05-29: v3.27.0 and v3.27.1. We do not name a model or a number of agents here, because our release notes do not, and this post only states what they say.

v3.27.0 led to 8 fixes, 3 of them rated High:

• The role gate now runs on the server (High). Some seats are Premium-only, and when a class went back to Free the downgrade of a co-treasurer's powers lived only in the screens. The server now decides, on every request.
• The AI chat output is sanitized (High). Text that came back in the chat could carry a hidden script. The chat now cleans what it shows, using an allow-list, and drops remote tracking images.
• A misread amount can no longer overstate the books (High). An amount read from a bank statement is now capped at the amount that was due before it reaches the ledger.
• A second yearly checkout on a class that already had one is now stopped (Medium).
• A spreadsheet-export field that could start with a formula character is now neutralized.
• The random part of collection links now comes from a cryptographically secure source.
• Test-only helper routes now refuse to run on the production deployment.
• Public collection pages that are served from cache no longer set cookies.

Then we attacked our own fixes

v3.27.1 re-ran every attack from that batch. The fixes held. The re-attack also found 3 more places where the same kind of bug lived on neighbouring endpoints, and all 3 were closed. Each one got an automated test that failed before the fix and passes after it.

What this does not prove

A pentest is a snapshot. It says these problems existed in May 2026 and were fixed; it does not say there are no others. It is also not a certificate, and this one is not an outside firm's audit. That is why the boring checks run on every change too: an OWASP ZAP baseline scan, Semgrep, npm audit, OSV-Scanner, Gitleaks and TruffleHog, which all block the build on new findings, and dozens of tests that try to read other classes' data. The current list is on the security page.

The next time someone tells you their app is secure, ask what they tried, when, and what changed afterwards.