Before you contract AI agents that are going to act on behalf of your company, there are six questions worth asking in writing. They are not technical: they are about accountability, limits and checkability. A solid provider answers them in the same meeting; one that has to go away and look them up is improvising its governance while talking to you.

The underlying logic is that an agent is not software you consult, but software that acts. If it acts, someone answers for it. And if someone answers for it, that has to be demonstrable. It is the same reasoning that underpins the digital ID for AI agents.

1. Which company is legally accountable for this agent, with a registry code?

Good answer: a specific company, with a legal form and a registry code, published alongside the agent. In our case, Cosmolabs OÜ, an Estonian company with registry code 17106582.

Bad answer: a trade mark, a product name or "our team". A brand has no legal personality and answers for nothing.

What you are checking is whether there is an identifiable party to hold to account. If there is not, the rest of the conversation is decorative.

2. Can I see, written down and published, what the agent is forbidden to do?

Good answer: an explicit list of prohibitions, accessible without asking permission, covering at least money, contracts, data deletion, autonomous communications and modifying other systems.

Bad answer: a description of capabilities. If a provider only describes capabilities, there is no evidence to assess where the authorisation boundary sits.

The list of prohibitions tells you more than the list of capabilities, because it bounds the risk even as the product evolves.

3. What digital signature proves it, and where is the private key held?

Good answer: an open standard — for example, W3C Verifiable Credentials 2.0 signed with ES256 — and a private key held in a key management module, outside the web server.

Bad answer: "we have logs". Logs have to be reviewable within the framework agreed with the client, with the necessary access and confidentiality guarantees.

If the answer involves a proprietary format, ask who else can validate it. If only their tool can, you are still trusting their word.

4. If you change the agent's prompt or tools, do I find out?

Good answer: there is a signed version of the manifest, a change process and a check of the effective configuration. A registered hash helps, but on its own it does not detect external permissions or prompts loaded into another service.

Bad answer: "we would let you know". That depends on someone remembering, in the middle of a deployment, to tell a client.

This is the question that separates providers most sharply, because it requires the system to have been designed with that property from the start. The technical detail is in what a digital ID for AI agents is.

5. How is that identity cancelled if there is an incident?

Good answer: public revocation, a defined expiry and a rehearsed access withdrawal with measured times. The provider should explain caches, sessions and the behaviour when verification fails.

Incomplete answer: "we deactivate the agent", with no evidence of the cut-off and no update to its public status. The revocation guide explains why both have to be checked.

6. Can I check it myself, without asking your permission?

Good answer: a public page where anyone runs the checks without signing up. You can see it working in the public verifier for the agent Argos, and consult the list in the public agent registry.

Bad answer: access on request, a dashboard you have to enter with the provider's credentials, or a PDF sent by email. If verification depends on the party being verified, it is not verification.

If your provider cannot answer all six, it does not mean they are bad people. It means their transparency depends on you believing them.

A scoring table to take into the meeting

Score each question from 0 to 2: 0 if there is no answer, 1 if it is an internal promise, 2 if a third party can check it.

#	Question	0 points	1 point	2 points
1	Accountable company	Only a brand	Company named verbally	Company and registry code published
2	Prohibitions in writing	None exist	In a private contract	Published and accessible
3	Signature and key custody	No signature	Proprietary signature	Open standard and key in a KMS
4	Notice of changes	No	Manual communication	Identity bound to the manifest hash
5	Cancellation	Internal deactivation	Revocation on request	Public revocation, expiry and tested cut-off
6	Independent check	Impossible	On request	Public page with no sign-up

A provider below 6 points is not ready for its agents to act outside your perimeter. Between 6 and 9, it works for internal tasks with supervision. Above 10, you can consider giving it external scope with human approval.

Two extra questions if the agent touches customers

When the agent communicates with people, add two more. The first: how does it identify itself as an AI system in every channel, not just on the website? That is the core of the transparency obligation we analyse in Article 50 of the AI Act for SMEs.

The second: who approves each external action and how is that approval recorded? In our superagents, the top operational level is A4: persistent or external action only with valid human approval. No autonomous money movement, no deleting audit trails, no privilege escalation: those actions are out of reach for any agent, whatever its level.

What to do with the answers

The answers to these six questions should end up in the contract, not in an email. Specifically: the accountable company with its registry code, the list of prohibitions as an annex, a commitment to notify or to break the credential when the configuration changes, a revocation deadline in the event of an incident, and the URL for public checking.

And it is worth remembering the limit: the signature verifies the origin and integrity of a declaration. It does not guarantee quality, or that every limit is enforced during execution. Protecting the system against abuse is another layer, which we cover in AI agent security.

Frequently asked questions

Do these questions apply if the provider is large?

Yes, and they tend to be more revealing. A large provider has abundant documentation about the model and, often, very little about the specific scope of the agent it deploys in your company, which is what matters here.

What do I do if the provider cannot answer the fourth one?

Ask at least for a contractual notification of configuration changes with a deadline, and keep the version of the manifest or the functional description as of the contract date. It is not equivalent, but it gives you something to check against.

Does this apply to internal agents that do not talk to customers?

It applies proportionally. An internal agent does not create the same transparency obligation, but it carries the same scope risks: data access, irreversible actions and uncontrolled configuration changes.

How long should a provider take to answer?

In the meeting itself, except for the registry code. If they need a week to tell you what their agent is forbidden to do, the real answer is that they have not decided yet.

What to do with this

1. Send the six questions in writing before the demo, not after.
2. Score with the table during the meeting, not from memory the next day.
3. Take the answers into the contract, with the list of prohibitions as an annex.
4. Check for yourself the verification URL they give you, in a window with no session open.
5. Repeat the exercise at every renewal, because an agent's configuration changes far more than traditional software does.

If you want us to review your current providers' answers and the real scope of your agents with you: book your Digital Audit.

Editorial update of 17 September 2026, produced with the support of AI tools and cross-checked against public documentation. It is not presented as an external audit.

Identity and execution: the scope of this explainer

The public checks describe the credential and its relationship with the registered manifest. They do not prove the authentication of whoever presents it, the state of each external permission, or that actions are actually blocked. See the published evidence and limits.