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.
An agent updated a customer's payout details at 3:14 on a Tuesday morning. Four days later the customer disputes it, and someone senior asks the only question that matters: did we do that, and did our controls hold?
You open the trace. It is all there — the parent span, the model call, the tool call that wrote the record, the guardrail verdict, a green tick on the dashboard.
You still cannot answer the question, because everything you are reading was produced by the system you are investigating. That is not a criticism of your observability stack; it is the shape of the problem. A converged stack sees almost everything an agent does and still cannot certify its own integrity under attack. A witness who is also the suspect is not a witness.
Give telemetry its due. OpenTelemetry's GenAI semantic conventions gave the industry a shared shape for agent runs — an `invoke_agent` span with `chat` and `execute_tool` spans beneath it — so a multi-step run reads as one connected trace instead of scattered log lines, and XDR platforms now consume those traces alongside identity and endpoint signal. You can find the action and see the chain, which is real progress.
That surface is the signal layer. It is necessary, it is not evidence, and more of it does not close the gap. Three things break when the question turns adversarial, and each has a cheap test attached.
The agent emits the span, and its framework writes the summary field. When the agent has been steered by an instruction hidden in content it retrieved, the record it produces is downstream of the same compromise, and its stated rationale is model output like any other.
Two gaps make it worse. Content capture is usually off — the OpenTelemetry conventions record no prompt content or tool arguments by default, and most teams keep that default for good privacy reasons. The trace shows a tool was called with some arguments, not what the instruction said. The pipeline is also a target: Impair Defenses: Disable or Modify Cloud Logs is a cataloged technique, and an agent identity with broad cloud permissions often reaches its own log destination.
Test it by attempting to break the record, not by reading it. In an authorized window, against a non-production copy, try three things. Suppress it: can the agent's own credential stop, redirect, or delete its telemetry? Delay it: how long from action to queryable record, since that gap is your blind window. Shape it: drive the agent with an injected instruction and read back what the trace claims happened. Pass condition — the action lands in a store the agent cannot write to, and any gap between what it did and what it said is visible to an outsider.
Every mature AI program has a stop mechanism on paper. NIST's AI RMF asks for one under MANAGE 2.4 — mechanisms in place and responsibilities assigned to supersede, disengage, or deactivate a system behaving inconsistently with intended use — and OWASP's Top 10 for Agentic Applications asks, under Rogue Agents, for the kill switch to be auditable.
Neither asks whether the mechanism has been exercised while something was actively going wrong, and that is usually the state we find: the control exists, has an owner and a runbook, and has never been pulled outside a slide. A stop button is a claim until someone measures it — and a claim about a distributed system: a queue, cached credentials, retries, and whatever else holds a copy of the agent's token.
Test it with a containment drill and a clock. Pick a window, tell your detection team, and stop a running agent for real. Measure five things: how long until in-flight actions cease; whether already-queued tool calls still execute; whether cached credentials keep working, by revoking and timing to first failure; whether a supervisor or deployment pipeline restarts it; and whether a second copy — a scheduled job, a sibling orchestrator, a developer's local runner — carried on untouched. Run it as a purple team exercise so detection gets measured in the same hour. For a number the board can hold, run the drill ten times and report the spread of time-to-halt. That number does not exist today because nobody has produced it.
Most deployments authenticate downstream as a single service principal, so the initiating human is dropped at the first hop and every action arrives as the same actor. The logs are complete and the attribution is empty: you can prove the platform did it, which was never in doubt. Worse, once the record shows only "the agent called the tool," you cannot separate an action the agent chose from one a poisoned document told it to take. At the span level they are identical — and that distinction is the whole content of a post-incident investigation.
Test it by reconstruction, with a stranger. Take one action from last week and hand two engineers, independently, nothing but the logs. Ask each for four facts: which human initiated it, which agent version and prompt were in play, which instruction caused it, which credential and scope were used downstream. If the answers differ, or either has to ask the platform team, *reconstructable* — one of the four properties an autonomous action needs to be worth trusting — has failed, and reconstruction is what DFIR stands on. The canary technique works on actions as well as data: seed a uniquely marked request and trace it end to end from evidence alone.
This is a synthetic composite, not a client or a real incident.
A support-operations agent reads tickets, searches a knowledge base, and updates accounts. Someone plants an instruction in an article it retrieves, and it changes a payout destination. Every control fires as designed and the run shows green — the guardrail passed the user's prompt, because it never saw the article. Content capture is off for privacy, so the injected text is not in the record, and the agent's summary says the customer asked for the change. Six hours later the team pulls the stop and the orchestrator halts, but a nightly job holding the same credential re-applies the update at midnight.
Nothing was tampered with. The telemetry recorded a truthful description of a compromised action — the failure mode nobody plans for.
Three corrections, none of which require replacing your platform.
Separate the witness from the actor. At least one record of every consequential action should land where the workload's own identity cannot modify it — append-only storage, a different account, a different credential boundary. Then verify it: attempt that write with the agent's credential and confirm it fails. Until someone has tried, "immutable" is a setting somebody believes in.
Make the containment path a tested control, not a documented one. Drill it, time it, keep the artifact. This is the line our assessment taxonomy draws between control validation and adversarial testing: validation confirms the stop button is wired up, adversarial testing asks whether it holds while something resists it.
Carry the initiating principal to the last hop. If the downstream system records only the service account, nothing upstream can restore who asked — and attribution stops at the platform.
Frameworks help, and stop short of proof. ISO/IEC 42001 is certifiable, and certification says a management system met a standard — not that your stop button worked at 3 a.m. CSA's Agentic AI Red Teaming Guide supplies test categories worth borrowing. But evidence has four attributes — the attempt, the observed result, the artifact, the conditions — and a dashboard supplies only the second.
Observability is not the problem, and none of this argues for less of it: you cannot test what you cannot see. The narrow claim is that a platform's self-report is the input to an integrity argument, not the argument. Independent adversarial testing supplies the other half, whoever performs it. It reduces and reveals risk; it does not remove it.
For a self-check, take one agentic workflow in production and answer three questions with artifacts rather than intent. Can the agent's own credential suppress, delay, or alter the record of what it did? Has anyone pulled the stop while it was running, and what was the measured time to halt? Can two engineers, given only the logs, independently name the human, the instruction, and the credential behind one action?
If the answer is "we would have to check with the platform team," that is the finding — and a common place to be right now.
We are a CREST-accredited, ISO/IEC 27001 certified offensive security firm, and we test the signal layer the way an attacker meets it: attempting to suppress and shape the record, exercising the containment path on the clock, and reconstructing real actions from evidence alone. Our AI and ML penetration testing and red teaming engagements hand back the attempt, the result, the artifact, and the conditions, and we run them continuously where the workflow changes faster than an annual cycle. We are services-first: we assure the stack you already chose.
If your agents are observable and you want to know what that observability would prove under attack, get in touch.
