Agentic AI in Learning and Recognition: What Could Go Wrong

Agents that request, hold and present credentials, and the controls they need.

Course ID: ICB-H02
Framework alignment: ICoBC Credentialing Skills Framework (ICSF), skill AIRC "Trustworthy AI in recognition", VRITE pillar Trustworthiness, level L4 "Assure", stage A "Ability".

Who this course is for

• L&D and corporate academy leads
• HR and learning technology owners
• Programme and micro-credential leads
• Education IT and credential operations staff
• Professional bodies and sector associations
• Standards and wallet community members

What you will practise

At level L4 you govern AI use in assessment and skills inference, assess regulatory classification and design oversight and delegation controls for agents. In this course you practise these skills on realistic cases in a controlled setting. You work on paper, with scenarios and templates. You do not need any live system.

Learning outcomes

1. Describe how AI agents can request, hold, present or act on credentials.
2. Analyse risk scenarios: fabricated credentials, persistent agent access, identity spoofing, actions beyond the mandate.
3. Design controls: holder binding, delegated and time-limited authority, audit trails, human approval.
4. Separate proof of achievement from authorisation to act.

Workload

The workshop has 4 hours of notional learning. This file covers the self-paced part. Live or workshop elements appear as facilitator notes.

Prerequisite: ICB-F07 AI Literacy for Recognition Work.

How it is assessed

You complete four modules with practice activities and short quizzes. The quizzes give you feedback and do not count towards the badge. The assessed task is a risk and control analysis for one agent scenario. A person marks it with the rubric in the section "Assessment and badge". There is also a final knowledge check for self-testing.

Badge

"Agentic AI in Learning and Recognition: What Could Go Wrong (Ability, L4)", alignment code ICSF-AIRC-L4-A. The badge evidence is your risk and control analysis. Completing the course shows that you have practised these tasks in a controlled setting. It does not prove competency in a job.

Status as of November 2026; check before publishing. Standards and rules for agent identity and delegation are still forming. This course teaches reasoning that holds as the details change. Where a fact may change, the text says so.

Agents and credentials

What an AI agent is in this course

In this course, an AI agent is a software system that pursues a goal on behalf of a person or organisation. It chooses its own steps, uses tools, and can act without a person approving each step. A chatbot that only answers questions is not the focus. A system that books a course, collects a certificate and submits it to an employer is.

Agentic AI in learning and recognition is the theme of the 6th ICoBC Symposium on 1 December 2026. Identity and delegation standards for agents are still forming. This means you cannot rely on a settled rulebook. You need to reason from first principles about who is acting, for whom, and with what permission.

Four things an agent can do with a credential

A digital credential is a signed statement about a person, such as a degree, a badge or a licence. An agent can relate to credentials in four ways.

1. Request. The agent asks an issuer or a service for a credential on behalf of a person. Example: it applies for a course completion record after the learner finishes.
2. Hold. The agent keeps credentials in a store it controls. Example: an assistant that manages a learner's collection.
3. Present. The agent shows a credential to a verifier. Example: it submits a certificate to an employer's application portal.
4. Act on. The agent uses a credential to trigger a decision or an action. Example: it uses a safety certificate to book a place on a site or to unlock access to a system.

The fourth item matters most for risk. When an agent acts on a credential, a statement about the past turns into a permission in the present.

The people and parties around the agent

Every agent scenario has at least these parties:

• the holder, the person the credential is about
• the principal, the person or organisation the agent acts for (often the holder, sometimes an employer or a provider)
• the agent itself, and whoever operates it
• the issuer of the credential
• the verifier who receives and checks it

Name each party before you analyse anything. Many failures begin when two roles are blurred, for example when the operator of an agent is treated as if it were the holder.

The graphic: an agent acting for a person

The graphic shows the basic pattern used through the course. A person grants an agent a permission with a clear scope and an end time. The agent then presents a credential to a verifier. The permission is separate from the credential.

Where the standards stand

The W3C Verifiable Credentials Data Model 2.0 is a W3C Recommendation since 2025 [Established]. It describes how credentials are structured, issued and verified. Related specifications for status lists and securing mechanisms continue to evolve. The data model tells a verifier whether a credential is genuine and who issued it. It does not, on its own, tell a verifier whether the party presenting it may act for the holder. That gap is the subject of this course.

The EUDI Wallet under eIDAS 2.0 is [Emerging]. Member States must offer at least one wallet by 24 December 2026. Germany plans its state wallet ('d-you') for 2 January 2027 with basic functions first. Regulated private sectors must accept the wallet about one year after issuance starts. Readiness varies widely between Member States. Wallets are where many agent questions will land, because a wallet holds credentials and presents them. Do not assume that a wallet will let an agent act in your country or sector yet.

Worked example: The academy assistant

Context: corporate academy. A corporate academy at a mid-sized manufacturer offers a safety-awareness course. The L&D lead, Mira, lets an assistant agent manage onboarding for new staff. The agent enrols each employee, collects their completion badge from the academy's issuing service and presents it to the facilities system to book site access.

Mapping the four relationships:

• Request: the agent asks the issuing service for the completion badge once the employee finishes.
• Hold: the agent stores the badge in the academy's learning system on the employee's behalf.
• Present: the agent shows the badge to the facilities system.
• Act on: the facilities system uses the presented badge to book site access.

Mapping the parties: the employee is the holder. The employer is the principal. The agent's operator is the learning technology team. The academy is the issuer. The facilities system is the verifier. Mira notes that the employer is the principal here, not the employee, and records this because it affects who can withdraw the permission.

Practice activity: Map an agent to the four actions

Context: university. A university programme lead, Tomas, tests an agent that helps students collect micro-credentials from three course providers and submit them to the credit recognition office.

1. List the five parties in this scenario (holder, principal, agent operator, issuer, verifier). Name one real role for each.
2. For each of the four actions (request, hold, present, act on), write one sentence describing what the agent does.
3. Mark the single point where a statement about the past turns into a permission in the present.

Compare your answer with the sample in the facilitator notes.

Risk scenarios

Why scenarios

Risk analysis in this course works through short scenarios. Each scenario has a trigger, a path and a harm. You describe what happens, who is affected and what would have stopped it. This module covers four risk scenarios. Every one of them involves an agent that is trusted a little more than it should be.

Scenario 1: Fabricated credentials

An agent can produce text, images and files that look like credentials. A system built to generate documents may be asked to prepare an application, and a careless or dishonest instruction can lead it to invent a certificate or a transcript. Generative tools can also fill gaps by guessing, for example by adding a qualification that "should" be there.

Harm: a verifier accepts a fake, an employer hires on false grounds, and honest holders lose trust.

Key question: can the verifier check that a credential was signed by the issuer it names, and that it has not been revoked? A genuine verifiable credential supports that check. A PDF or an image does not.

Scenario 2: Persistent agent access

A person gives an agent access for one task. The access is never withdrawn. Months later the agent still holds tokens, copies of credentials or a standing permission. If the agent is compromised, sold, reconfigured or simply left running, it can keep acting long after the person has forgotten the grant.

Harm: unneeded data stays exposed, and actions take place under an old permission that no one would approve today.

Key question: when does the permission end, and what removes the agent's copies?

Scenario 3: Identity spoofing

A party pretends to be the holder, the agent, the issuer or the verifier. An attacker may present a real credential that belongs to someone else, because the credential itself is valid. Or an attacker may set up a fake agent that claims to represent a holder. In the other direction, a fake verifier may collect credentials from agents that do not check who is asking.

Harm: a valid credential is used by the wrong person, or personal data goes to the wrong party.

Key question: how does the verifier know the presenter is the holder or someone authorised by the holder? How does the agent know the verifier is genuine?

Scenario 4: Actions beyond the mandate

The agent was asked to do one thing and does more. It was allowed to present a credential to confirm training and instead shares the full record. It was asked to apply for one course and enrols the learner in five. It uses a credential to open a door that no one meant it to open. Agents choose their own steps, so a vague instruction leaves room for steps the principal never imagined.

Harm: unwanted commitments, costs, data sharing and decisions that the principal must still answer for.

Key question: what exactly was the agent allowed to do, and what stops it from doing more?

The graphic: four risk scenarios

A simple way to write a scenario

Use four lines for each scenario you analyse:

• Trigger: what starts it
• Path: the steps from trigger to harm
• Harm: who is affected and how
• Stop point: the earliest point where a control would have stopped it

The stop point is the bridge to the next module. A good analysis ends with a place where a control belongs.

Worked example: The leftover access at the training provider

Context: university, college or training provider. A training provider runs an evening programme. Its programme lead, Aisha, allowed a student's assistant agent to collect a completion certificate once. The agent kept a standing token with the provider's student portal. Eight months later the student changed jobs and stopped using the assistant. The assistant service was later taken over by another operator who reconfigured it.

• Trigger: a one-time grant with no end date.
• Path: the token stays valid, the agent service changes hands, the new operator's system still holds the token and can read the student's records.
• Harm: the student's study records are exposed to a party the student never chose.
• Stop point: the grant should have ended when the certificate was collected. A time limit or an end-of-task revocation would have stopped it. A review of active agent permissions would have found it later.

Aisha also notes a second stop point: the portal could have shown the student a list of active agent permissions.

Practice activity: Analyse a scenario from the HR department

Context: HR department. An HR team, led by Jonas, uses an agent to check that contractors hold a valid first-aid certificate before they start on site. The agent receives certificates from contractors' own assistants and records "valid" in the HR system. One contractor's assistant sends a certificate that belongs to a colleague of the same name.

1. Which of the four scenarios does this match best? Could more than one apply?
2. Write the four-line analysis: trigger, path, harm, stop point.
3. Name one question the agent should have asked before recording "valid".

Controls

From risk to control

Each risk scenario has stop points. A control is a rule, check or technical feature placed at a stop point. This module covers four controls: holder binding, delegated and time-limited authority, audit trails and human approval. No single control is enough. They work in layers.

Holder binding

Holder binding links a credential to the person it was issued to, so that a verifier can tell the presenter is the holder or someone the holder has authorised. A credential about a person can be presented by anyone who holds a copy unless something ties the presentation to the holder. Binding can use a key held by the holder, a wallet that proves control, or a check against an identity record. The detail depends on the system and on the standards in use, which are still forming for agents.

For an agent, there are two questions: is the holder behind this presentation, and has the holder authorised this agent? Holder binding answers the first. Delegation answers the second.

Controls to consider:

• The verifier asks for proof of control, not only a copy.
• The credential carries the holder's identifier and the verifier checks it against the presenter.
• High-value credentials are never accepted from an agent without a second check.

Delegated and time-limited authority

Delegation is the holder or principal giving an agent permission to act. A good delegation has these parts:

• Who: the named agent and its operator
• For whom: the holder or principal
• What: the allowed actions, for example "present the completion badge for course X to verifier Y"
• Limits: what is excluded, for example "no sharing of other records"
• Until when: an end time or an end event, such as "when the badge has been presented once"
• Revocation: how the holder or principal can withdraw it, and how fast it takes effect

The graphic in Module 1 showed delegation as a separate item from the credential. Make the delegation narrow. A narrow scope lowers the harm from actions beyond the mandate. A short life lowers the harm from persistent access.

Standards for expressing agent delegation are still forming. Where a standard is not available, record the delegation in a clear internal policy and keep it machine-checkable where you can.

Audit trails

An audit trail is a record of what an agent did: which credential it requested, held or presented, to whom, when, under which delegation, and with what result. It lets a person answer "who did what, and was it allowed?" after the event.

A useful audit trail:

• links every action to a delegation
• records the human who granted or approved it
• cannot be altered by the agent itself
• is kept for a stated period and protected as personal data
• can be read by the holder

Keep the record to what you need. An audit trail that copies full credentials into a log creates a new store of personal data.

Human approval

Human approval means a person confirms before the agent acts. You do not need it for every step. Use it where the action is hard to undo, has legal or financial effect, shares sensitive data or falls outside the usual pattern.

A simple test: would the principal want to know before this happens? If yes, ask. Design the request so that the person sees what will happen in plain words, not a code. An approval that nobody reads protects nobody. If approvals arrive too often, people click through them, so keep them for the moments that matter.

Controls in layers

Worked example: Controls for the site access agent

Context: corporate academy. Back to the academy assistant from Module 1. The facilities system accepts a safety badge to book site access. The L&D lead, Mira, and the facilities owner, Pedro, design controls for the agent that presents the badge.

• Holder binding: the facilities system asks the presenter to prove control of the holder's key. A copy of the badge alone is not accepted.
• Delegation: the employee, through the onboarding policy, grants the agent: present the safety badge for course S-1 to the facilities system, for site bookings only, valid for 14 days, ends after the first booking is made, revocable by the employee or the employer at any time.
• Human approval: bookings for restricted areas need approval from the site manager. Ordinary bookings do not.
• Audit trail: the facilities system logs each booking with the delegation reference, the agent identifier and the approver where there was one. Employees can see their own entries.

Pedro asks what the controls cost in effort. Mira answers that the delegation template is written once and reused, and that the approval applies only to restricted areas, so volume stays low.

Practice activity: Design controls for a university case

Context: university. A university registry, led by Ines, allows a student's agent to submit a transcript extract and a language certificate to a partner university for an exchange application. The deadline is in three weeks. The student's agent also has access to the full transcript.

1. Write a delegation for the agent with who, for whom, what, limits, until when and revocation.
2. Decide where human approval is needed and where it is not. Give one reason for each.
3. Describe the holder binding you would ask the partner university to check.
4. List four fields you would record in the audit trail.

Accountability

Proof of achievement and authorisation to act

A credential is proof of achievement. It says that a person completed a course, passed an assessment or holds a licence. It is evidence about the past.

Authorisation to act is permission to do something now. It says that a party may book a room, sign a form, enrol someone or open a door.

These two things are different. A person can hold a safety badge and still not be allowed on site this week. An agent can hold a valid badge and still not be allowed to present it. A verifier that treats the credential as permission, or treats an agent's possession of a credential as permission to act for the holder, has merged two questions into one.

Keep them apart in design:

• Ask of the credential: is it genuine, current and issued by a suitable issuer?
• Ask of the authority: who gave this party permission, for what, until when?
• Ask of the decision: does the achievement meet the rule, and is the party allowed to act on it?

A badge also does not prove that a person is competent in a job. It records what the issuer assessed under the issuer's criteria. Decisions that rely on it need their own rules.

Who is accountable

When an agent acts, a person or organisation must still answer for it. Accountability does not move to the agent. For each action, you should be able to name:

• the principal, who gave the instruction
• the operator, who runs the agent and its technical controls
• the verifier or issuer whose decision relied on the agent's action
• the owner of the control, who maintains delegation rules, approvals and audit logs

Write these roles down before deployment. In many organisations the question "who is responsible when the agent gets it wrong?" has no clear answer until something goes wrong. Your task at level L4 is to make sure the answer exists before.

Regulatory classification

Part of governing AI use is asking which rules apply. AI used in assessment, in access to education or in decisions about people at work may fall into regulated categories in some jurisdictions. Whether a given agent does depends on its purpose, its effect on people and the applicable law. Do not decide this alone. Involve legal, data protection and compliance colleagues, and record the outcome of the assessment and the reasons.

For credential agents, useful questions are:

• Does the agent influence a decision about a person's access, hiring, progression or recognition?
• Does it infer skills from data and present the result as a credential-like claim?
• Does it process personal data, and under which legal basis?
• Which person can review and overturn what the agent did?

Overseeing in practice

Oversight is a routine, not an event. A simple rhythm:

• Before launch: write the scenario analysis, delegation template and approval rules. Get sign-off from the owner of the control.
• In operation: sample the audit trail, review active delegations, check that approvals are being read.
• After an incident: trace the action through the audit trail, find the stop point that failed, change the control and tell affected people.
• On a schedule: re-run the risk analysis when the agent, the verifier or the standards change. Standards for agents are still forming, so expect to revisit.

The graphic: separating proof from permission

Worked example: The recognition decision at a college

Context: university, college or training provider. A college offers credit for prior learning. A student's agent submits a professional micro-credential to the recognition office. The officer, Sara, reviews it.

• Proof of achievement: Sara checks that the micro-credential is genuine, not revoked and from an issuer the college accepts for this subject. These checks pass.
• Authorisation to act: Sara checks the delegation. The student authorised the agent to submit this micro-credential, once, until 30 days from the grant. The submission is inside the window and the scope.
• Decision: Sara decides whether the micro-credential meets the college's credit rule for the module. She records her name, the date, the delegation reference and her reasoning. The agent's presentation did not decide anything. Sara did.

Sara notes that if the delegation had expired, she would pause the case and ask the student to confirm, even though the micro-credential itself was valid.

Practice activity: Separate proof from permission in an HR case

Context: HR department. An HR system lets an agent apply on a manager's behalf for a restricted-access training programme. The agent holds the manager's leadership badge and presents it. The programme owner accepts the badge and enrols the manager. Later it turns out that the manager had not asked for the programme and the agent had been told "find development options".

1. State what the badge proves and what it does not prove.
2. State which authorisation was missing.
3. Name the accountable principal, operator and decision maker.
4. Write one change to the process so that proof and permission are checked separately.

Assessment and badge

The assessed task: Risk and control analysis for one agent scenario

You produce a written risk and control analysis for one agent scenario. A person assesses it using the rubric below. Nothing in this file grades your work.

Choose a scenario. Use one of the two below, or use a scenario from your own organisation with the facilitator's agreement. Remove personal data and confidential details.

Option A: Corporate academy or HR department. An HR team lets an agent maintain each employee's skills record. The agent collects certificates from external providers, stores them in the employee's profile, and presents them to line managers and to the project staffing tool, which uses them to assign people to projects with qualification requirements.

Option B: University, college or training provider. A provider lets students' assistant agents request micro-credentials, hold them in a wallet, and present them for credit recognition and for placements with partner employers. The provider's own agent also issues completion records at the end of each course.

What to submit (about 1,000 to 1,500 words, plus any diagrams or tables you choose):

1. Scenario description. Name the parties (holder, principal, operator, issuer, verifier). Describe how the agent requests, holds, presents and acts on credentials. State what the agent is allowed to do. (Outcome 1)
2. Risk analysis. Analyse the four risks: fabricated credentials, persistent agent access, identity spoofing, actions beyond the mandate. For each, give trigger, path, harm and stop point. Say which risks matter most in your scenario and why. (Outcome 2)
3. Control design. Design holder binding, delegated and time-limited authority, audit trail and human approval. Include a completed delegation with who, for whom, what, limits, until when and revocation. Link each control to a stop point. (Outcome 3)
4. Separation statement. Explain what the credentials in your scenario prove, what authorisation the agent needs, who grants it and who decides. Name the accountable people. Note any regulatory classification question you would raise and with whom. (Outcome 4)
5. Open points. List what you could not verify and what you would check, including any standards or wallet readiness that may change.

Rubric

Pass rule

To earn the badge, you need a rating of "Met" or "Strongly met" on all five criteria. If a criterion is "Not yet met", you may revise and resubmit once within the period set by the facilitator. The assessor records the decision and a short justification.

Evidence submitted for the badge

• Your risk and control analysis (the document described above)
• The completed delegation template
• The assessor's rubric record

The badge is "Agentic AI in Learning and Recognition: What Could Go Wrong (Ability, L4)", alignment code ICSF-AIRC-L4-A. It records that you practised these tasks on a realistic case in a controlled setting. It does not prove competency in a job.

Final knowledge check

This check supports your preparation. It does not replace the assessed task.

Sources and further reading

Status as of November 2026; check before publishing. The status of agent identity and delegation standards, EUDI Wallet timetables and related specifications can change quickly.

• W3C, Verifiable Credentials Data Model v2.0, W3C Recommendation. Published by the World Wide Web Consortium at w3.org. Search for the title on the W3C website for the current text and for related specifications on status lists and securing mechanisms.
• European Union, Regulation (EU) 2024/1183 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework (commonly called eIDAS 2.0), published in the Official Journal of the European Union and available on EUR-Lex.
• European Commission, pages on the European Digital Identity Wallet and its implementation, available on the Commission's digital strategy website. Check the current timetable and Member State status there.
• ICoBC, Credentialing Skills Framework (ICSF), International Council on Badges and Credentials, Berlin. Available from ICoBC at icobc.net.
• ICoBC, course ICB-F07 AI Literacy for Recognition Work, the prerequisite for this course, available in the ICoBC Kursbibliothek.
• ICoBC, programme and materials of the 6th ICoBC Symposium (1 December 2026), on agentic AI in learning and recognition. Check icobc.net for the current programme.