🤓 Latest Submissions
Kovrell: calls the vendor before you pay
Vendor bank-detail fraud starts with one email: "We changed banks, please pay the new account." 74% of US organizations were hit by business email compromise in 2025. 94% say they call the vendor back on a number from official records, but only 63% rate that control as very effective (AFP 2026). Callbacks get skipped under deadline pressure, get placed to the number in the fraudulent email, and accept "yes, that's us" as proof. Kovrell makes that callback automatic and hard to fool. When a bank-change request arrives, the payment is held. Kovrell checks the vendor's number of record and refuses to call if it changed in the last 30 days. Then a voice agent built on the AssemblyAI Voice Agent API calls the contact of record, confirms identity and the request, asks three questions drawn at random from the vendor's recent paid invoices, and reads back the new account. The model asks, and code decides. The agent never receives the answers, can't say whether one was right, and can't choose the verdict. Server code checks what it heard against the ledger and releases the payment, blocks it, or keeps it held. Every call is sealed into an evidence pack with the AssemblyAI recording and timeline, expected versus heard answers, and a sha256 hash, downloadable as JSON or PDF. The server holds the AssemblyAI socket, because the caller may be the fraudster: the vendor's browser is only an audio pipe. Kovrell uses per-run session.update, JSON-Schema tool calling, hold execution mode, max-accuracy transcription with keyterms, barge-in, and session artifacts. Try it live: set up your own vendor on /setup, take the call with your microphone, and watch a signed webhook deliver the verdict. 102 automated tests cover the attacks we tried.
30 Sep 2026
Whylode: keep the why behind legacy code
The problem Thousands of companies still run orders, invoicing, and payroll on IBM i systems written in RPG decades ago. The code works. The reasons behind it live in the heads of people who are retiring. In Fortra's 2026 IBM i Marketplace Survey, 69% of IBM i shops named skills as a top concern, ahead of cybersecurity for the first time in nine years. Nothing breaks until a rule changes. A state raises its sales tax, a trading partner changes its EDI format, and someone has to edit code nobody explained. Existing tools, including code maps and AI documentation, can show where a rule lives and what the code does. They can't say why a line was written that way, and that is exactly what decides whether an edit is safe. The solution Whylode is an add-on for IBM Bob 2.0: a custom mode, three skills, and an MCP server with eight tools, plus a web app. 1. A developer gives Bob the change notice PDF. Bob reads it, splits it into clauses, and traces every line that implements each clause, with a confidence score per line. 2. Where the code can't explain itself, Bob doesn't guess. It sends one short question to the system owner, who answers on their phone through a link. No account needed. 3. Each answer is pinned to the exact lines it explains, in a memoir that the next developer and Bob both read. 4. Bob checks the answers against the code, flags any contradiction, and drafts the diff. Every changed line and every deliberately kept line carries its reason. A person approves it on the web. What it looks like in practice Our sample RPG order-to-invoice system has two hardcoded tax rates in the same program, and nothing in the code says which one is the state rate. In the recorded run, Bob asked what customer type C2 and its 0.0525 rate were. The owner answered that it is a contract rate fixed until 2029. The approved change edits only the state rate and keeps the contract rate, with the owner's answer quoted as the reason. The second change, a new EDI tax detail requirement, touched the same code. Bob found 3 lines already explained in the memoir, asked nothing it had asked before, and only asked about the new wiring. Nobody gets asked the same thing twice. Who it is for IT directors at IBM i shops facing retirements, the developers inheriting those systems, and the retiring experts, who only ever see one plain question at a time. What makes it different Whylode doesn't translate or document whole systems. It works only on the lines a real change touches, turns what nobody wrote down into kept knowledge, and makes every edit auditable. Answers are treated as claims to verify, never as instructions, and approval stays with a person. The RPG system is a sample written for this project and is disclosed as such.
27 Sep 2026
Airlock: AI Agent Governance Membrane
AI agents can wire money, leak data, and deploy code. In a multi-agent swarm, there is nothing between what an agent wants to do and what it actually does. No checkpoint. No trail. No oversight. One rogue agent causes irreversible damage before anyone knows. Airlock fixes this. Airlock sits as a governance membrane between agents and tools. Every action request passes through the Warden, which evaluates it against a declarative YAML policy before any tool is called. Safe actions are auto-cleared in milliseconds. High-stakes actions are escalated to a human via Band @mention. Dangerous actions are hard denied and never executed. We demonstrated this with a real rogue vendor agent built on the A2A protocol with a proper agent card and declared skills. It attempted to export all customer PII and wire $75,000 to an attacker account. Airlock intercepted both before any tool fired. The compliance ledger writes itself. Every request, verdict, and human decision is captured in Band history with no second database. The trail is a byproduct of the system working, not an afterthought. Built on Band AI for the Band Hackathon 2026. Policy engine in Python with 15 unit tests. Dashboard in Next.js with real-time ledger, human gate UI, and a DiffPanel showing exactly what raw A2A would have executed without Airlock. Five agents. Nine rules. Seven millisecond verdict latency. Nothing crosses ungoverned.
19 Jun 2026
