The word “alignment” is being written and uttered so much lately that I wouldn’t be surprised if it becomes the word of the month. Most of the time, when you see the term “AI alignment” (or misalignment, when it is lacking), it refers to ways AI agents have collaborated and conspired to break into systems and hide their actions, while supposedly serving what seems like a benign goal.
Anyone who’s been using AI agents in the last six months will recognize this behavior. Occasionally, it’s front-page news material. Most of the time, however, it happens in hundreds or thousands of little decisions agents make all the time, in service of your goal, or, more ominously, to avoid doing something you asked them to do.
I recently asked an AI agent whether some code had been tested. It said, “Yes, everything passed.” But when I ran the test myself, the code didn’t work. So I asked again: Had it actually run the tests? This time it answered: “No—I cannot honestly claim I watched every module execute cleanly.”
In case you haven’t experienced this, I gave it instructions and guardrails, and it reported that it had followed them and executed all its tests; when challenged, it admitted it hadn’t done any of that after all. I challenged it in the first place because, when I tested the code, it didn’t work. So it wasn’t as if it achieved its goal and was just being lazy; it didn’t achieve its goal, then lied about achieving it and testing it. This is just one everyday example of misalignment that permeates AI agent behavior.
Fortunately, there is a way to address these issues that provides the reliability and predictability of rules-based testing and the velocity of AI-powered automation, which I’ll discuss below.
Why verification and guardrails matter
Anthropic recently published an article titled “The AI-Native SDLC playbook: How to transform your software development lifecycle with AI—stage by stage.”
The authors cover verification and guardrails in depth. They talk about hooks, deterministic checks, and verification built into the coding loop. They also talk about adversarial reviewers as separate agents. To achieve scale and be AI-native, though, at the end of the day, all the work is being done by the agents, and so the human has to rely on the judgment of the agents. This leaves a lot of room for misalignment to wreak havoc.
The “Hugging Face incident” has justifiably been one of the most widely reported examples. The incident began during an internal OpenAI evaluation of how well its agents could find and exploit software vulnerabilities. The evaluation was run without production safeguards. More than 700 agents ultimately combined to breach Hugging Face’s production servers (a third party with no role in the test), with no human input at all. These agents were engaged in “reward hacking,” where agents autonomously develop unintended ways to achieve an objective. More worrying than the breaches themselves is how the agents found ways to communicate and collude with each other, then tried to cover their tracks. What you have is a system learning to produce the measurement of success instead of the success itself. And, as famously stated in Goodhart’s law, “When a measure becomes a target, it ceases to be a good measure.”
This type of agent behavior is why you can’t rely solely on AI for accessibility testing.
The accessibility gap
When we talk about AI alignment and accessibility, we’re really talking about the gap between what your agent said it did and what it actually did; or, the gap between presumed and actual accessibility. We cover this in detail in our recently released report, “From debt to dividend: How engineering leaders can advance accessibility in the AI era.”
Among the key stats surfaced in our report are:
1) 88 percent of engineering leaders have high or very high trust that their AI-generated code is accessible, and
2) 64 percent cite accessibility as a top driver of post-production rework. In other words, engineering leaders are using AI for accessibility and believe it’s working, even though missed accessibility issues are creating more work for their teams. This is presumed vs. actual accessibility in action.
Given that our report also shows it’s 30 times more expensive to fix an accessibility issue caught in production than at the design stage, misalignment is costly—even before you get to regulation and litigation.
The value of out-of-band, irrefutable validation
The key to solving this problem is to create a record of work that is a direct side effect of what the agent is doing and therefore cannot be misrepresented by the agent.
It’s a bit of an old-fashioned analogy, but it works here. Using one agent to validate another’s work is like asking the proverbial fox to guard the henhouse. And trusting the second agent’s guarantee that the first agent produced accessible code is like the farmer taking the fox’s word for it that the hens are safe. To extend the analogy even further, you can credit the fox with a vast amount of imagination and resolve. Who knows what lengths it might go to, to spoof the farmer into believing that all is well in the henhouse?
Unfortunately, what Anthropic is not accounting for with their approach is that they’re still leaving the foxes in charge of the henhouses.
NVIDIA proposed Sentry as a different type of approach, where the validation is something an AI agent cannot influence. Validation needs to be out of band and irrefutable. This is where the value of a deterministic accessibility harness comes in. It’s responsible for ensuring the scope of the testing and controlling what the AI does (only what it must), what context it sees (only what it needs), and what it can determine (only a binary determination that the harness deterministically evaluates). In the process, it creates a proof-of-work record that the agent doesn’t even know exists. This is what we mean by deterministic testing while leveraging AI.
The value of deterministic testing
I’ve written elsewhere about the economics of AI integration and the cost and efficiency gains associated with deterministic testing. What we’re talking about here are reliability and predictability—the foundation of trust.
This is where the value of a deterministic accessibility harness comes in. It’s responsible for ensuring the scope of the testing and controlling:
- what the AI does (only what it must)
- what context it sees (only what it needs)
- what it can determine (only a binary determination that the harness deterministically evaluates)
The key is to use the AI for the work only the AI (or, previously, a human) can do: understand semantics and determine equivalence of communicated information, while leveraging deterministic algorithms for everything else.
This allows the deterministic code to create a proof-of-work record that the agent doesn’t even know exists. The guardrail can then deterministically interrogate that proof-of-work and give it a trustworthy thumbs up or thumbs down.
This is what we mean by deterministic testing while leveraging AI.
The Intelligent Guided Test accessibility testing harness
The accessibility testing harness Deque has written forms the engine for our automated Intelligent Guided Tests (IGTs). It uses deterministic code, supplemented by narrowly scoped AI classification, captures the context for that testing, and then asks the LLM for simple yes-or-no answers when given a very focused context. Put another way, we give the AI just what it needs—no more, no less. We ask the AI a simple question: yes or no. We then collect these answers and deterministically make pass-or-fail judgments, all while creating a record of the work, with all the AI justification, ready for human audit or verification. There is no scope for negotiation or for falsifying either the outcome or the evidence of work.
My colleague Harris Schneiderman described what that looks like in practice in a recent article, “Intelligent Automation and the New Era of Guided Testing.”
In his article, he uses a dialog box to illustrate this. A rule can check the dialog’s markup: whether it has the right role, a labeled heading, and the attributes a dialog is supposed to have. Checking where focus goes, however, requires watching the live page while it runs, so you can determine where focus lands when the dialog opens, and where it goes when the dialog closes. Historically, only a trained accessibility specialist could check that.
With Deque’s automated Intelligent Guided Tests (IGTs), you can automate that process. Running through Axe MCP Server, right in the developer’s editor, an IGT opens the dialog, closes it, and checks where focus lands. It reports what it found. A person then confirms the result before the check counts as resolved. Harris’s article conveys the impact: a manual keyboard test that used to take 30 to 45 minutes can now be done in seconds.
This approach is very different from one AI vouching for another AI’s work. The IGT doesn’t grade its own test. It gives a person the same evidence a human tester would have gathered, and does so in seconds. This gives us the best of both worlds: the reliability and predictability of rules-based testing and the velocity of AI-powered automation. By taking this approach, we can close the gap between presumed and actual accessibility. AI alignment will remain an ongoing concern, but with deterministic, rules-based testing, we can ensure consistently reliable results you can trust.
