Agent qualification

Before an AI agent does real work, find out which tasks the evidence supports. For one configuration (the model, the harness around it, its tools, its permissions and the workflow) I test what it does on representative and adversarial cases, check the outcomes independently, and report where it can act alone and where it cannot.

This is one application of the same method as every other investigation on this site, not a separate business. If your question is about a result, a model or an algorithm, bring it as it is.

The whole configuration, not the model. The same model in a different harness, with other tools or wider permissions, is a different system with different failure cases.

• Model: the exact model and version, and its settings.
• Harness: the agent framework, prompts, memory and retry logic around it.
• Tools: what it can call, and what each call can change.
• Permissions: what it is allowed to read, write, send or spend.
• Workflow: the real tasks, data and decisions it would be given.

Agreed in advance, and chosen to fit the workflow. Usually some mix of:

• representative tasks from the real workflow, with each outcome checked mechanically wherever the workflow allows: a balance that must reconcile, a record that must exist, a file that must match;
• adversarial cases: misleading inputs, conflicting instructions, missing or stale information;
• attempts to act outside the granted permissions, and whether anything outside the agent notices;
• actions nobody asked for, including combinations of individually permitted actions;
• repeated runs, to see how much the outcome varies;
• where that is the question, two models or two harnesses under identical conditions.

Before a pass is trusted, the check is shown to fail on a planted bad case.

• The tested envelope: tasks, conditions and configuration, stated exactly.
• The failures, each with a reproducible case.
• The conditions under which the evidence does not support autonomous operation.
• The harness, cases and checks, so the same test can be run on the next configuration.

Never “this agent is safe”. The result reads like: under these tested conditions, this configuration succeeded on these tasks, failed on these, and should keep human approval for this one.

A hypothetical example of the format. No such engagement has taken place, and it carries no numbers because none have been measured.

A newer, stronger model is another experimental variable. Its result does not inherit the old one, in either direction: it may earn more autonomy than the last model, or fail somewhere the last one did not. The test is kept so it can be run again when:

• the model or its version changes;
• the harness, prompts or framework change;
• tools are added or changed;
• permissions widen;
• the data or the workflow itself changes.

For an organisation about to connect internal information and systems to an agent. The question is not whether the data is tidy; it is what happens when an agent actually meets the system. For example:

• two sources that disagree about the same fact, or one that is out of date;
• names, accounts or records that could refer to more than one thing;
• permissions wider than any task needs;
• retrieval that returns a plausible but wrong document;
• information with no record of where it came from;
• actions in separate systems that nobody intended to be combined.

Investigated by putting an agent, or a scripted stand-in for one, in front of a safe copy of the system and recording what it can reach, what it concludes and what it can do. This is not a data-cleaning service.

Whether an agent usually behaves is a measurement of the agent. Whether an action cannot happen without approval is a property of the system around it, and that can be tested directly and sometimes proved. Depending on the system, that means looking at:

• explicit authorisation policies, and whether execution is bound to what was authorised;
• approval steps, and whether they sit in the path of the action or beside it;
• least privilege;
• invariants that must hold whatever sequence of actions is taken;
• independent checks of what actually happened;
• audit records, and what they can and cannot establish.

A verified policy proves something about that policy. It does not prove the whole system safe: the policy can say the wrong thing, and what executes can differ from what was authorised. Both have happened in the public work below.

Self-initiated research, not client work. No client agent qualification is shown on this site.

• An authorisation boundary that passed its own checks. An agent tool server built for a study passed 66 of 66 tests, its replay verifier said VERIFIED, and a 100,000-byte write ran under a 4,096-byte cap. A separate observer reading the file actually written caught it; the repair binds execution to the authorised operation. One server and one policy set, not a measurement of deployed systems. Repository · Finding
• A permit that was never issued. An executor accepted a permission record assembled from public information, because it checked that the record was well formed and never that it had been issued. One defect in one program. Reproduction
• Evaluation records that hid their own configuration. In Inspect AI the same failing run reported 6 of 6 or 4 of 6 completed samples depending only on scorer order; in inspect-robots, run records omitted the grader configuration, so differently graded runs looked identical. Both are fixed upstream; another contributor wrote the Inspect AI fix. Inspect AI case · inspect-robots #425

• My first reply says whether a useful test can be designed with what is available, and costs nothing. Scope, duration and a fixed fee are agreed in writing before work starts.
• Everything you send, the agent’s transcripts and the result are confidential by default. Nothing from the work is published, or reused in other work, without your written agreement.
• Sensitive systems can stay in your environment: I can supply the harness for your team to run there and review only its outputs.

Not a safety certification, an accredited audit, a regulatory approval or a guarantee of future behaviour. Not a statement about a model in general. Not a penetration test. A result covers the configuration, tasks and conditions tested, and nothing beyond them. I hold no accreditation or security clearance.

Why not rely on the model provider’s benchmarks?

They measure a model on someone else’s tasks, usually without your harness, tools or permissions. They are useful for choosing what to test. They are not evidence about your workflow.

Why not have the team that built the workflow test it?

They should, and they are the right people to fix what is found. An outside test is useful because it does not share the assumptions the workflow was built on.