AI agents and the person behind the account
A named account can carry delegated work. Decide what the result supports before giving someone responsibility.
An account record can identify whose account was used while leaving open who performed the task. When an AI agent acts with permission, a manager still needs to distinguish the delegated work from the account holder's own contribution before relying on the result.
The AI credential experiment made that distinction visible. AI agents worked through Jacob Top Møller's authorised account, and 424 credentials were issued to it and independently verified on public provider pages. The experiment's register describes the assessment work as AI-performed. Jacob supplied authorisation and human steps including sign-ins; his time was not measured. Issuance established an account-level result, without measuring his learning.
For a business owner, the useful question extends beyond training: what decision does this record justify? A completion entry may be enough to confirm that a process reached its end. Accepting delegated work also requires a clear account of who checked it and which uses have been approved.
What a verified credential tells you
Verification and a claim's meaning require separate judgments. A genuine award can accurately describe a completion without establishing that the named person answered the questions unaided.
The W3C's Verifiable Credentials Data Model makes the limit explicit: verification does not establish the truth of the claims inside a credential. A verifier applies its own business rules before relying on those claims. That standard does not establish how the experiment's providers implemented their awards; it gives a useful distinction between checking authenticity and deciding what the claim supports.
A manager who reads a training record therefore needs the assessment conditions. Was AI assistance allowed? What work did the learner personally perform? Did anyone observe that work? A more convincing-looking badge cannot supply an answer that the assessment never established.
The experiment did not test whether identity checks or supervised exams could be defeated. It started none of the four finals recorded as requiring camera images, face registration or screen sharing, following the experiment's own rule against camera access and false attestation. Those unattempted gates provide no evidence about how an agent would perform against them.
Permission to act has a scope
Authorising an agent to do a task establishes permission for that task; it does not turn the task into a demonstration of the account holder's ability. An owner may deliberately delegate work and still want the record to describe that delegation accurately.
There is already a technical vocabulary for keeping parties apart. The IETF's OAuth token exchange specification distinguishes the party on whose behalf a request is made from the acting party. Whether an implementation carries both identities depends on its design and policy. This is a protocol distinction, not evidence that the learning sites in the experiment used that mechanism.
The corresponding business conversation can be plain. An employee may be allowed to use AI to practise, draft an answer or compare alternatives. Permission to do those things does not automatically include permission to submit an assessment with an own-work declaration. The provider's rules still need checking, alongside the employer's intended use of the result.
A useful instruction names the permitted work and where the agent must stop. For example, a hypothetical employer could allow AI help during practice, require the employee to disclose that help, and reserve the final demonstration for an observed task under stated conditions. That is a proposed arrangement, subject to the course rules, rather than a description of how a provider or employer currently operates.
What belongs in the handover
A useful handover distinguishes permission to do the work from acceptance of its result. A business owner needs to know what was delegated, what happened and what still requires a decision.
Imagine a hypothetical owner asking an employee to use an AI agent to prepare a customer briefing. The permission covers research from public sources and a draft for internal review. Sending it to the customer remains a separate decision. If the system later shows the briefing as complete under the employee's account, that status alone leaves both the agent's contribution and the remaining approval unclear.
The handover could say that the agent prepared the draft, the employee checked the claims against the linked sources, and the owner has yet to approve customer use. It should identify any important unresolved point. The owner can then accept the draft as an internal input, request a correction or approve a defined use. The employee's account remains the account used; the record no longer asks its name to explain the whole sequence.
A change in scope needs another decision. If the agent reaches a source that requires a separate login, the original permission to use public material has not settled that access. If the employee wants to send the briefing, permission to prepare it has not settled publication. These are proposed boundaries for this hypothetical assignment, not a description of a particular product's controls.
In training, the equivalent distinction is between permission to use help and a claim that the learner personally met the assessment conditions. An employer's permission cannot settle a provider's own-work rule. If the conditions do not permit the intended delegation, the responsible next step is to change the arrangement or stop that activity. A completed item cannot resolve the conflict afterwards.
Responsibility after delegation
The person accepting AI-assisted work should state what they are accepting and which uses remain outside that decision. That makes it possible for the next person to continue without guessing what a completion meant.
In the hypothetical briefing, the owner might approve the draft for a team discussion while leaving customer use undecided until an unresolved claim is checked. Recording that limited acceptance avoids presenting an internal review as permission for wider distribution. If the work changes later, the earlier approval refers to the version that was reviewed, not automatically to the new result.
This is a proposal for clearer business handovers, not a legal conclusion about liability or a security control design. More recording is not automatically better: keep the information needed for the decision, with appropriate privacy and access limits. A useful account of who did what and who accepted which use can be short.
The next time a task appears as complete under someone's name, ask what that completion means for the next person. If they still have to guess who acted or whether a further approval is needed, the handover is unfinished even when the system has closed the task.