[Use Case] “delegation” of operation by an AI Agent owner (person natural or legal person) to an AI Agent to act on his behalf

Complete every field. Replace the angle-bracket placeholders. Tick boxes with [x].

1. Identification

Title: “delegation” of operation by an AI Agent owner (person natural or legal person) to an AI Agent to act on his behalf
Submitting organization: IN Groupe
Contact name: Alban FERAUD
Contact email: alban.feraud@ingroupe.com

Sector (tick all that apply; a cross-industry case may tick more than one):
- [ ] Education
- [ ] Displaced persons / humanitarian
- [ ] Health
- [X] Financial services
- [] Telecom
- [ ] Media and publishing
- [ ] Logistics
- [ ] Energy
- [ ] Critical infrastructure
- [X] Smart home / IoT
- [X] Other (specify): any case where a person would delegate an operation to an AI Agent

2. The situation

Describe the functional interaction: who is acting, what they are trying to achieve,
and what happens. The trust and security aspects are drawn out in Sections 3 to 5.

Plain language description (required, 3 sentences max):
Actor (every party involved):
Action:
Decision required (at the moment the agent acts, what does the party on the receiving
end have to decide? Write it as a question, e.g. "May this firm's agent be let into the
house on the homeowner's authority?"):
Problem encountered (why that decision cannot be made today):
Current mitigation:
Residual gap:

3. Actors and context

Taxonomy roles involved
- [ ] Principal — possesses the authority being exercised; source of the mandate
- [ ] Relying party — must decide whether to accept the agent's authority
- [ ] Builder
- [ ] Deployer / Owner
- [ ] Agent instance
- [ ] User — interacts with the agent; may or may not be the principal
- [ ] Infra provider
- [ ] Attestor
- [ ] Other (specify):

Mandates in this case (required)

List each grant of authority. State the legal regime governing each one: the regime
fixes what could be conferred, at what moment standing may change, and with what
continuing effect. A single-regime case is entirely valid. Actor above lists every
party; this table covers only the authority relationships between them.

Cross-border?
- [ ] Yes — jurisdictions involved:
- [ ] No

Embodied (physical actuation or sensing)?
- [ ] Yes — physical context:
- [ ] No

Agent action type (required; tick all that apply. Where several apply, the most
consequential governs the case)
- [ ] Read-only
- [ ] Consequential (reversible)
- [ ] Irreversible

Crosses organisational boundary? (required)
- [ ] Yes (specify):
- [ ] No

Risk level (required)
- [ ] Low
- [ ] Medium
- [ ] High

4. Theme relevance

Check every theme this situation exercises, mark the single primary theme, and justify
each checked theme against Section 2 above. If your case maps to specific theme
proposals in the themes repository, link them below.

Related theme proposals:

5. Requirements

One row per requirement. Add rows as needed. Type: Legal / Business / Technical.
Technical requirements are the primary output; include legal or business requirements
where they bear on a technical decision. Criticality: Must / Should / Nice-to-have.

6. Assessment criteria

Success criteria:
Measurable metric:

7. Duplication check

Required under ITU-T Recommendation A.7 clause 7: the Focus Group does not duplicate work underway in ITU-T study groups or other bodies.

Existing standards or SDOs (which existing work touches this case):
Overlap notes (why the work named above does not already solve this):

8. Maturity

Pilot status

• [ ] Hypothetical
• [ ] Pilot in progress
• [ ] Deployed in production

Reference implementation:

9. IP and confidentiality

Confidentiality level

• [ ] Public
• [ ] FG-internal only
• [ ] Redact before publication

IP notes (optional):

10. Assets

Link to assets:
- [ ] Dataset
- [ ] Code
- [ ] Protocol
- [ ] Other:

IP notes (optional):