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.
A customer emails your service desk. Change the shipping address on the account, and rush a small reorder to the new one. Every field is valid. The requester authenticated. The order sits under the approval threshold, so no manager sees it.
Six months ago a rep would have handled that. She might have processed it in thirty seconds. Or she might have picked up the phone, because that account orders in pallets on the first of the month to one of three warehouses.
Which of those happened was never recorded. There is no control ID for "the rep thought it looked off." No log line, no artifact, no test plan. It was never in your control inventory. And now an agent handles the request in four hundred milliseconds.
That is the part of the automation case nobody costed.
Almost every workflow now going to an agent had a person in the middle doing two jobs. The documented one — enter the data, click approve, move the ticket — had a cycle time, which is precisely why it showed up in the business case.
The second job had no cycle time. It was the silent comparison of the request against everything that person knew about the vendor, the customer, the season. Nobody wrote it down as a control because nobody experienced it as one. It looked like competence.
Closing the loop deletes both. The first deletion is on the slide. The second is free, invisible, and absent from the risk register, because the register only ever held controls someone had named.
This applies to security's own workflows. Teams buying AI security agents for alert triage are removing an analyst doing that same second job: knowing this host is noisy every Tuesday, that this alert has never once been real. If you would not accept "the analyst had a feeling" as a detection control, you cannot book its removal as zero risk.
This is not nostalgia, and not an argument for putting people back.
The human checkpoint was inconsistent — the same rep on a busy December Tuesday waves it through. It was unavailable at 2 a.m. and during the two months the role sat vacant. It was directly attackable: business email compromise and targeted phishing are the industry of defeating one person's sense that something looks normal. And it produced no evidence either way — no artifact when the rep caught a bad request, and none when she missed one.
So you cannot claim that control was good, and you cannot claim it was bad. It was unmeasured — the last control in the enterprise permitted to be. The coverage rate you implicitly assume when you automate has never been calculated, because the data was never captured.
Here is a composite of the pattern we see. It is synthetic and illustrative, not any one client.
A distributor puts an agent in front of account changes and reorders. Requesters authenticate. Address changes trigger a confirmation email to the address of record. Orders above a dollar threshold route to a human approver. Everything is logged.
An attacker compromises a customer's mailbox. Authentication succeeds, because the attacker is the customer as far as the system can tell. The confirmation email lands in the mailbox the attacker controls. The orders are deliberately small — several, weeks apart, each under the threshold.
Every control held as designed. Nothing was bypassed.
What changed is the meaning of the threshold. It was set when a rep read every request on the way to deciding whether it needed a manager. Below the line meant "no formal approval required." It never meant "seen by nobody." Closing the loop turned an informally reviewed band into an unreviewed one, and nobody re-derived the number. A rep would also have read four small orders as one story; the agent judges each alone.
The replacement is not a person. At agent speed, approving hundreds of actions becomes a click, and a checkpoint that is always satisfied is one in name only. Human oversight belongs on decisions where judgment applies, not on throughput.
What replaces it has to be deterministic: it evaluates the same way every time, cannot be satisfied by the system it governs, and emits a record whether or not it fires. Take the four jobs the person was doing, and ask what stands in for each.
Noticing becomes an explicit predicate. "That is not how this account behaves" has to become conditions a machine can evaluate: a destination never used by this account, a request outside its ordering window, a change to delivery details within N days of an order. Discovering those rules is the hard part; they only existed in someone's head. *Test it by exception replay:* take thirty requests a person stopped or escalated last year, run them against the automated path, and count how many the checks catch. That is your real coverage.
Refusing becomes a preventive control, not a detective one. A rule that only raises an alert rebuilds the weakness you just removed: it needs someone available, attentive, and willing to argue with an urgent request. The distinction between control types stops being academic here. *Test it by attempting the action the rule should stop* and recording whether it completed. If a ticket was raised instead, that is a notification, and the gap until someone opened it is how long the action was live.
Being unbypassable becomes an approval a machine cannot satisfy. The human checkpoint had one accidental property: the system could not be the human. Digital approvals lose it — a button in a chat channel can be clicked by the bot that posted it. OWASP's Top 10 for Agentic Applications names a related risk, Human-Agent Trust Exploitation: agent output shaped to persuade a person into approving what they should not. An approver reading the agent's own account of what it did is already inside that. *Test it by trying to satisfy every approval step using only automated identities.* Anything satisfiable without a human principal is decorative — the "authorized" property from our post on AI integrity, applied to the approval itself.
Accountability becomes an artifact, on the allow as well as the block. The human control's worst feature was producing nothing; do not rebuild it. Most implementations log the denial and stay silent on the approval, so you cannot distinguish a check that ran and passed from one that never ran. *Test it by taking one clean action from last week and producing the record of which checks evaluated it and what each returned.*
All four are things a tester attempts rather than reads about — which is why threat modeling an agentic system has to cover the workflow the agent replaced, not just the model.
NIST's AI RMF gives you governance scaffolding, and CSA's draft Agentic Profile for it concedes the point: at higher autonomy, human confirmation may arrive too late to matter, so the safeguard has to be pre-authorized and automatic. MITRE ATLAS gives you technique language for the test plan. ISO/IEC 42001 is certifiable, and certification means a management system met a standard — not that a control held under attack. A framework mapping produces a map, not a result.
Removing the human checkpoint is often the right call. The argument here is narrower: you are removing more control surface than your inventory says, and the amount is unknown rather than small. No adversarial test makes an agentic system safe. It converts an unmeasured control into a measured one — a smaller claim and a more useful one. Independent testing is the position that produces that evidence, whoever performs it.
For a self-check, pick one workflow you have automated and answer four questions with evidence rather than intent. Which conditions did the person use to decide something looked wrong, and are any written down as rules today? When one trips, does the action stop, or does someone get an email? Can any approval step be satisfied by an automated identity? And for one clean action last week, can you show which checks ran?
If the answer is "we would have to ask her," that is the finding — and a normal place to be right now.
We are a CREST-accredited, ISO/IEC 27001 certified offensive security firm. When we test an agentic workflow we attempt the controls rather than review them: replaying the exceptions a person used to catch, trying to satisfy approval steps with machine identities, and checking whether a rule stops an action or only reports it. Our AI and ML penetration testing and red teaming hand back the attempt, the result, the artifact, and the conditions, and we run it continuously where the workflow moves faster than an annual cycle. We are services-first, so we assure the stack you already chose.
If you are about to close the loop on a workflow and want a second opinion on what the person in it was doing, get in touch.
