PrymeIntelligence

Regulated autonomy·Answer

What does a fully autonomous AI agent need before it can be trusted?

Before a fully autonomous AI agent can be trusted it needs proof on your cases, enforced bounds, known sources, a full record and expiring authority.

It needs evidence, not promises. Before any agent runs alone, you need proof on your own cases that it works, bounds checked at the moment of every action, sources whose origin is known, a record that reconstructs each decision, authority that expires, and a named person who owns it. Even then, irreversible actions should still wait for someone.

Why is trust earned per agent?

Trust in an agent rests on evidence about the specific things it does. An agent can be excellent at matching invoices and poor at judging whether a supplier's change of bank details is genuine. Its certification has to clear on both, so the weaker capability cannot ride on the stronger one's reputation.

So each requirement below applies to the agent, and each action it takes still needs its own depth. An agent may be trusted to run some actions alone and not others. That is the normal state, as set out in how autonomous an AI agent should be.

What are the six requirements?

  1. Proof on your own cases. The agent is replayed against real past cases from your operation, and each answer is scored against a minimum standard. Vendor benchmarks and demos are not proof for your process, your data and your exceptions. The tests should cover whether answers are grounded in sources, whether the agent refuses what it should, whether it escalates, whether it stays in scope and whether it avoids harm.
  2. Bounds enforced at the moment of action. Every time the agent acts, a control outside the agent checks the action against its scope, its proof, its sources, your limits and fixed platform rules. Instructions in a prompt are not bounds; the agent can be talked out of them.
  3. Sources whose origin is known. Every fact the agent relies on carries a mark of where it came from. A figure from your ledger is not the same as a claim in an inbound email, and an unverified outside claim should never authorise a payment.
  4. A record that reconstructs each decision. For every action: what the agent saw, what it did, which bound decided, and who approved if anyone did. The record cannot be edited after the fact.
  5. Authority that expires. Proof gets stale as processes, data and models change. Authority should lapse on a fixed cycle unless the agent is tested again, and drop at once if a test fails.
  6. A named owner. One person is accountable for each agent: what it may do, at what depth, and what happens when it goes wrong.

None of these are features of the model. They are features of the system around it.

How is the evidence gathered?

Start with history. Take a set of past cases for the capability, including the awkward ones: exceptions, complaints, near misses, fraud attempts. Run the agent against them without letting it act, and compare its answers with what should have happened.

Then run it in draft alongside people. The agent proposes, a person decides, and the differences are recorded. This shows how the agent handles live work and where people override it.

Only after both should the agent move to unattended execution, and then within limits on value and volume. Keep sampling. An agent that starts drifting, or that people start overriding more often, goes back to draft until it is proven again.

What still stays with a person?

Even a fully trusted agent does not cover everything.

  • Irreversible actions. Proof lowers the chance of a mistake but not the cost of one. Payments to new recipients, external decisions and data disclosures keep a person in front of them.
  • Decisions about people. Decisions with legal or similarly significant effects are restricted under GDPR Article 22 and its UK equivalent when based solely on automated processing.
  • Changes in authority. Raising or lowering an agent's depth is a decision for its owner, made on the evidence.
  • Exceptions. Anything outside the cases the agent was proven on.

The reasons are set out in whether AI agents should be fully autonomous and in why autonomy in regulated industries is a question about reversal.

How do you check a vendor's claims?

Ask for evidence that meets the six requirements on your cases, not theirs. Ask how bounds are enforced at runtime, how sources are marked, what the record contains, how authority expires and who can lower it. If the answer to any of these is a policy document rather than a control, the agent is not ready to run alone. The questions are set out in how to assess a vendor's AI agent before you deploy it.

Where Pryme fits

Pryme is built around these six requirements. Attest replays the agent against the customer's own cases across seven gates: grounded, refuses, depth, escalates, scope, adversarial and stable. The Pryme Context Protocol stamps every fact with its source class. Certificates lapse after 90 days, every verdict is filed, and the minimum chain checks five bounds on every action.

Questions people ask

How many past cases are enough to prove an agent?

Enough to cover the routine work and the known exceptions, including rare but costly ones. Coverage of the hard cases matters more than a large count of easy ones.

Can a third-party certification replace testing on our cases?

It can show a vendor has sound processes. It cannot show the agent works on your data and procedures, so it supplements your own testing rather than replacing it.

What happens if the agent fails after going live?

The agent drops to read-only or draft the same day, the failure is investigated from the record, and the agent is tested again before it regains its authority.

Decide what your agents may do. Prove it. Enforce it.

Pryme Intelligence certifies each agent on your own cases, checks every action against five bounds at the moment it happens, and files every verdict.