By Sean Mahoney, CISM, VP and Information Security Director, Netswitch, Inc.
A few years ago, one of our clients, an insurance firm, took a call from a customer asking why their $40,000 premium payment had not been applied. It’d been paid.
It just wasn’t paid to our client.
The customer received an email that read exactly like our client. Same phrasing, same signature block, sent in the conversational rhythm the two of them had settled into over years of working together. It gave new bank details for the premium payment. The attackers had been sitting inside the customer’s mailbox for weeks, reading emails, learning how our client and their customer spoke to each other, waiting for the next premium to come due.
The money went out the door. Then the customer threatened to sue our client, who had done nothing wrong and had never seen the email.
Here is what made the attack work. The customer was an early entrant in the cannabis industry, which at that point meant federal restrictions kept most banks at arm’s length and banking relationships changed often. An email saying the money needed to go to a new account wasn't strange at the time.
We resolved the incident by proving authorship. Headers, transport records, DMARC configurations, authentication results, infrastructure logs, all of them pulled from our client’s own environment, where controls put in place years earlier had been keeping records nobody had asked for. None of that was built to answer a legal question, but all of it did. The message carried its own provenance, and those records held up when nothing else would have convinced anyone.
The control that should have stopped the payment was a person finding the request odd enough to verbally verify it. That control still existed. Context had quietly stripped the oddness out of it, and nobody had gone back to ask whether it was still doing the work everyone assumed it was doing.
I think about that case every time AI-assisted development comes up in a board conversation, because the question that saved our client is one I have stopped expecting a codebase to answer.
A Change in How the Asset Gets Made
Most organizations I talk to adopted AI coding assistants the way they adopt any other productivity tool. Someone ran a demonstration, the developers liked it, a manager approved seats inside their own spend authority, and within two quarters a meaningful share of production code was machine-generated and human-accepted.
That was not a tooling decision. It was a change to how the company manufactures its primary asset, and it was evaluated on throughput alone. Nobody asked what it did to the risk profile because the request never arrived in a form that would prompt the question. Risk committees see initiatives, not seat licenses.
The Acceptance Nobody Recorded
Risk acceptance is a formal act. Someone with delegated authority over an asset reviews the residual risk, decides the organization will carry it, and creates a record of that decision. The record is the point.
A developer who reviews a generated code suggestion, finds it plausible, and merges it has made a decision about risk entering production. Hundreds, maybe thousands, of those decisions a week, across a team, at a pace that makes deliberation impossible. I am not saying those developers acted without authority. They were working inside a development lifecycle the organization designed and approved. The problem is quieter, and harder to answer for. That delegation structure was written for a world where a human authored every line and another human read it. It does not describe this decision point at all. The decision gets made where the risk framework does not reach, and nothing is written down.
If someone decides without authority, you at least have a name. Undocumented is worse, and it is worse in a way that does not feel like anything at the time. No rule got broken. There’s just nothing there later when someone asks.
The Control Did Not Change, the Volume Did
Peer review by an experienced developer has carried this weight for decades. When a reviewer reads a colleague’s work, they are reading code produced at roughly the rate they can read it.
The process didn’t disappear, but the relationship it relied on did. Output increased. Review capacity didn’t, because reviewers are the same people, doing the same job, inside the same working day. No one restated the control, because from outside nothing looks different. Code review still happens. It still appears on the process map. It is still named, accurately, on every security questionnaire the company answers.
What changed is operating effectiveness. In most board reporting, a control like this shows up as present, and present is where it stops. Nobody is testing it against the volume it’s expected to absorb, because nothing in the reporting process was designed to ask that question.
What the Organization Has Already Put in Writing
This is where it stops being an engineering concern.
Somewhere in your files are signed statements about how your software gets built. Customer security questionnaires. Secure development representations inside commercial contracts. Cyber insurance applications answered by an executive relying on a summary from someone else. If you sell to federal agencies, attestation language derived from the Secure Software Development Framework, signed by a chief executive or an equivalent officer. In January 2026 the Office of Management and Budget rescinded the memoranda that made that form mandatory, leaving each agency to set its own assurance requirements. Neither the form nor the language went anywhere. Agencies may still ask for it, and it had already migrated into commercial contracts, where nobody rescinded anything.
OMB Memorandum M-26-05, Adopting a Risk-based Approach to Software and Hardware Security, January 23, 2026, rescinding M-22-18 and M-23-16. https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf
Every one of those statements describes a development lifecycle. Each was accurate on the day it was signed. But they were never revisited when the development process changed, because the change arrived as a purchase order, and purchase orders don’t trigger a review of standing representations.
The organization now carries a set of signed descriptions of itself that quietly stopped matching. Not through anyone’s bad faith. Through a routing failure, which is the most common way governance fails and the hardest kind to see from inside.
What to Ask for
Commissioning a policy is a normal reflex. But a policy describes intent; it doesn’t tell you whether the control is working. Ask for one number and one name.
The number is the percentage of code that reached production last quarter after substantive human review. Substantive has to be defined first: what the reviewer verifies, how changes touching authentication, payments, customer data, or production infrastructure are separated from routine ones, and what evidence of the review is retained. Expect discomfort, because most organizations can’t produce that figure today, and the inability to produce it is itself the finding.
The name is the individual who holds documented authority to accept code into production without that review. Exceptions are legitimate. Emergency fixes, automated remediation, low-risk changes on a different track. What makes an exception governance rather than drift is that someone owns it, the criteria are written down, and the use of it leaves a record. If nobody can name that person, everyone with commit access effectively holds that authority, and nobody will want to defend it when the incident arrives.
We were able to prove that the email was fraudulent because the systems kept a record nobody built for the purpose. Ask your organization the same question about the code running your business, and see whether anything answers.
Latest News
