September 8, 2026
Compliant Is Not Correct: The AI Gave Us the Wrong Hashcat Mode
Compliant Is Not Correct: The AI Gave Us the Wrong Hashcat Mode
Omair
New Update: Our new blog is updated.
Free download
Omair Manzoor is the Founder, CEO, and Chief Hacker of ioSENTRIX, a CREST-accredited cybersecurity firm. With 14+ years in offensive security, he has led penetration tests for Fortune 500 companies including engagements for Amazon, Bank of America, VISA, and the London Underground. His exploits are part of the Metasploit Framework and Immunity Canvas. Omair is a published researcher, conference keynote speaker (DOD, CISA, BSides), and technical reviewer for academic security textbooks.
Your largest deal of the quarter is six weeks in. Legal is clean. The security questionnaire comes back with a section that was not there last year.
It does not ask whether you have an AI policy. It asks what your agent is allowed to do without a human, what happens when someone tries to make it do more, and whether an independent party has attempted that and written down what happened.
Your team answers the first in an afternoon. The second and third take three weeks, four internal meetings, and a paragraph beginning "we believe." The deal does not die. It slows, and closes with a conditional term and a re-review in six months.
That is what integrity costs when you cannot show it. Not a breach. A calendar.
Enterprise trust has run on attestation for two decades. You held a certificate, filled in a questionnaire, and the buyer's risk team filed it. It worked because what you asserted was static: a control existed, a policy was signed, a scan was run.
Autonomous systems broke that arrangement. When software acts on its own — moves money, changes a record, grants access — the buyer stops asking whether you documented a control. They ask whether the action their vendor's agent takes on their data is genuine, authorized, untampered, and reconstructable. No checkbox establishes any of those four properties, because each is a claim about behavior under pressure rather than about configuration.
Three things happened at once, and only one of them is regulatory.
First, the mechanism for publishing AI assurance became real. The Cloud Security Alliance launched STAR for AI in October 2025, topping out at a Level 2 that pairs an ISO/IEC 42001 certificate with a scored assessment in a public registry. In June 2026 CSA added the AIUC-1 standard there, whose requirements include quarterly red-teaming. Read that last detail carefully: an AI assurance standard now assumes recurring adversarial testing rather than an annual document review.
Second, a very large buyer wrote evidence into its purchasing rules: US federal agencies now acquire AI under OMB M-25-22, which pushes them toward performance-based acquisition, ongoing performance monitoring, and enough vendor documentation to complete an impact assessment. Demands from a buyer that size propagate downstream as contract language.
Third, and least expected: the regulatory clock moved *out*. After the omnibus amendments, the European Commission's AI Act timeline puts most high-risk obligations at December 2027 and August 2028, with transparency rules landing in August 2026. The honest reading is not relief. It is that the deadline pressure on your roadmap for the next eighteen months comes from your customers, not a regulator — and customers do not publish an implementation timeline.
Here is the pattern, as a synthetic composite rather than any one client.
Two suppliers reach the shortlist for the same platform. Both have SOC 2, an AI policy, and an agent that touches customer records.
Supplier A answers the AI section with the policy, a vendor attestation from its model provider, and a control matrix marked "implemented." Every word of it is true, and none of it is testable by the reader. Supplier B answers with an independent test report — the attempt, the observed result, the artifact, and the conditions — naming two findings that were not fully fixed, with dates. It is the less flattering document.
Supplier B's review closes in eleven days. Supplier A's runs seven weeks, escalates to the buyer's risk committee, and ends in an exception with compensating controls and a re-review clause. Same product quality. Different cost of being believed.
That is the trust premium, and it is not a price line. It is sales cycle length, the terms you concede to reach signature, and which conversations you are invited into at all. Anyone who has run a vendor security assessment from the buyer's chair knows how early that filtering happens and how rarely it is explained — which is why the supplier cut at longlist stage never learns why.
This is the honest version of the existential framing. The risk is not that one bad day ends the company. It is two years of losing a category of deals for a reason that never appears in a loss report. It runs the other way too: if you are the buyer, your third-party risk process is where the premium is paid or ignored.
For a board, this is not a technical program. It is four decisions, and each one has a test you can run on your own organization this quarter.
Decide what you are claiming. Not "our AI is secure" — name the specific properties above and the actions they apply to. *The test:* ask for the list of agent actions the company would defend in front of a customer's risk committee. If nobody can produce it, the claim has no scope, and an unscoped claim turns a security review into a discovery exercise.
Decide which exercise you are buying. Governance review, control validation, and adversarial testing are three different things that all get sold as an AI security assessment, and the difference between them is the difference between a document and a result. *The test:* take the last assessment the company paid for and find one control that was attacked. If every line reads "reviewed" or "confirmed," you bought the first exercise. That may have been correct — but you cannot answer a buyer's evidence question with it.
Decide what the deliverable must contain. Four attributes separate evidence from assertion: the attempt, the observed result, the artifact, and the conditions. Insist on all four in the statement of work before the engagement, because you cannot retrofit them into a finished report. *The test:* open the last report and check whether a reader outside the company could tell what was tried. Check-the-box testing fails this quietly and passes the audit anyway.
Decide who produces it, and how often. Independence is not an ioSENTRIX marketing position; it is written into the frameworks. NIST's AI RMF playbook, at MEASURE 1.3, calls for internal experts who were not front-line developers, or independent assessors, in regular assessments. The reason is structural: the team that built the system and the platform vendor reading its own telemetry share a blind spot in the same place. *Two tests.* Ask who wrote the last report; if the author reports to the people who built the thing, that is a self-assessment however rigorous it was. Then ask what has changed since; if the answer is "a lot," you hold a point-in-time result describing a system you no longer run.
Note what none of this promises. ISO/IEC 42001 is genuinely certifiable and worth holding, but it certifies a management system — not that a specific control held under attack. Alignment with NIST's framework is a map. Neither substitutes for a test result, which is why a certificate alone increasingly draws a follow-up question rather than closing the section.
Do not take the premium on faith, and be skeptical of anyone quoting an industry-average figure for it, ourselves included. The numbers that would demonstrate it are your own, and your CRM mostly holds them already: median days from security questionnaire to signature, split by whether an evidence package existed; the share of closed deals carrying security-driven conditional terms; inbound RFPs containing an AI assurance section, quarter over quarter. Cut those three ways once and the business case either appears or it does not. That is the same discipline you would apply to any security spend — a real denominator, not a fear number.
Proving integrity does not eliminate risk, and no test makes an autonomous system safe. It converts an unmeasured claim into a measured one — a smaller promise, and a far more useful one in a room full of people deciding whether to trust you.
This series began with a question — how do you know it's real? — and worked through where policy quietly fails, from the paths data takes around an AI policy to the agent tool-chain underneath. This is the commercial answer to all of it. Integrity is the property your customers are starting to buy on, and evidence is the only form in which it travels.
Four questions for your next board meeting, one per decision above. Which agent actions would we defend in front of a customer's risk committee? Which exercise did we actually buy last time? Could an outside reader tell what was tried? How much has the system changed since? If the answers are uncomfortable, that is the finding — and it is a normal place to be in 2026.
We are a CREST-accredited, ISO/IEC 27001 certified offensive security firm, and we test agentic systems the way an attacker would rather than reviewing them the way an auditor does. Our AI and ML penetration testing and red teaming hand back the attempt, the observed result, the artifact, and the conditions — a document you can put in front of a customer's risk committee, including the parts that did not go well. We are services-first: we assure the stack you already chose. Independent adversarial testing is what produces this evidence, whoever you engage to perform it.
If your security reviews are getting longer and you want to know whether an evidence package would shorten them, get in touch.
