Why testing needs a signature

Two security consultants were arrested on 11 September 2019, on the third floor of a county courthouse in Adel, Iowa, carrying tools for opening locks. They were doing exactly what they had been hired to do. The state’s judicial branch had contracted their firm, Coalfire, to test the security of its courthouses. The county sheriff said the state had no right to authorise testing of a building the county controlled, and charged them with felony burglary.

The charges were reduced, then dismissed in January 2020. The two men later sued, and the county agreed to a $600,000 settlement. They still have a felony arrest on their records. The whole case turned on one question: who had the right to say yes.

Permission is the whole difference

In the United States, the law that governs computer intrusion is the Computer Fraud and Abuse Act. It makes accessing a computer without authorisation, or beyond it, a crime. In 2021 the Supreme Court narrowed what “exceeds authorized access” means in Van Buren v. United States, and in May 2022 the Justice Department said it would not charge good-faith security research under the act.

Neither is a blank cheque. The department defines good-faith research as access done solely to test, investigate or fix a security flaw, and lawyers reading the policy have noted that a claim of good faith is not a free pass. Testing someone’s systems because you mean well is still testing them without permission.

Who can say yes

The Iowa case shows that the person who signs has to have the right to sign for everything in scope. That gets harder with cloud and outsourced systems. A company’s application may run on Amazon’s or Microsoft’s infrastructure, and those providers have their own rules. AWS lets customers test their own resources on a list of permitted services without asking first, but forbids things like denial-of-service testing. Microsoft dropped its pre-approval requirement for Azure in 2017 and keeps rules of engagement that forbid testing its own infrastructure or other customers’ resources.

• The signer must be entitled to authorise every system named, including ones hosted by someone else.
• The scope says exactly which systems, and which must never be touched.
• The window says when testing may happen, and it ends.
• Permission can be withdrawn, and testing stops when it is.

Why AI makes this harder

A human tester who strays outside scope usually notices. An AI agent works faster, tries more and does not get tired, and it does what it was pointed at with great determination. When OpenAI’s agents broke out of their test in July 2026, they were not trying to cause harm. They were chasing a score, and they went wherever that took them, including into another company.

That is why permission for an AI tester cannot be a document in a drawer. It has to be checked by the software itself, every time the agent reaches for a target. A name that is in scope can resolve to an address that isn’t, so the check belongs on the connection, not just the task, and again on every redirect. An exclusion has to beat the scope, and anything malformed or too broad has to stop the whole engagement rather than be guessed at.

How Cyberquid holds the line

This is the one part of Cyberquid we have built first, because everything else rests on it. No agent touches a target unless a signed engagement covers it at that moment. The check refuses by default: no signature, a revoked or expired engagement, or a target outside the scope, and the answer is no. A person confirms the signer is entitled to authorise each system before the signature is recorded, because software cannot judge that.

The consultants in Iowa were right about their work and still spent a night in jail over who had the right to say yes. With AI doing the testing, that question has to be answered before anything runs, in writing, and enforced by the machine that does the work.