[Use Case] Child-Aware AI Agent Acting Across Services
fg-tida-use-cases-use-case-child-aware-ai-agent-acting-across-services-76
| Type | FG-TIDA document |
|---|---|
| Group | Trust and Identity for Humans and Agentic AI |
| State | Submitted |
| Authors | Not entered |
| Last updated | 2026-10-23 15:11 UTC |
Formats and resources
Abstract
Complete every field. Replace the angle-bracket placeholders. Tick boxes with [x].
1. Identification
Title: Child-Aware AI Agent Acting Across Services
Submitting organization: Vodafone Group
Contact name: Gianpaolo Angelo Scalone
Contact email: gianpaolo-angelo.scalone@vodafone.com
Sector (tick all that apply; a cross-industry case may tick more than one):
- [x] Education
- [ ] Displaced persons / humanitarian
- [ ] Health
- [ ] Financial services
- [x] Telecom
- [ ] Media and publishing
- [ ] Logistics
- [ ] Energy
- [ ] Critical infrastructure
- [ ] Smart home / IoT
- [x] Other (specify): Consumer AI services and child online protection
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):
A child uses a family AI assistant to find learning material, and the assistant calls an external education service on the child's behalf. A parent has set a child profile with limits on data sharing and purchases, while age-appropriate content rules apply to what the child receives. The education service must decide what the assistant may do and what response may be delivered without needing the child's full identity.
Actor (every party involved):
Child; parent or guardian; family AI assistant; assistant provider; external education service and its agent or API; trusted child-profile or identity provider, potentially a telecom operator; policy enforcement points at the assistant, service or family side.
Action:
The family assistant requests learning material from the external service and may ask it to retain a learning preference or offer a paid item. The service returns material that may be delivered to the child.
Decision required (at the moment the agent acts, what does the party on the receiving end have to decide?):
May this assistant request material, disclose information, save a preference or initiate a purchase on this child's behalf under the current delegated authority? Separately, may the resulting material be delivered to the child's profile under the applicable content policy?
Problem encountered (why that decision cannot be made today):
The receiving service may recognise the assistant but lack a reliable, minimal way to verify that it is acting for a child, what authority the parent has granted, whether that authority remains valid, and which protections apply. Conversely, passing the child's identity and full policy to every service would create unnecessary disclosure and correlation.
Current mitigation:
Separate child accounts, parental-control settings and service-specific age checks can apply protections within their own environments. A family-side control may also filter material before it reaches the child.
Residual gap:
These measures do not, by themselves, establish an interoperable decision about an external agent's delegated authority. Where family-side content controls are sufficient, no child attribute needs to travel downstream for content delivery; the open question is what minimal proof, if any, is needed when an external service must decide whether to perform an action on the child's behalf.
3. Actors and context
Taxonomy roles involved
- [x] Principal — possesses the authority being exercised; source of the mandate
- [x] Relying party — must decide whether to accept the agent's authority
- [x] Builder
- [x] Deployer / Owner
- [x] Agent instance
- [x] User — interacts with the agent; may or may not be the principal
- [x] Infra provider
- [x] Attestor
- [x] Other (specify): Child; parent or guardian; family-side content-policy authority
Mandates in this case (required)
| Grantor | Grantee | What is conferred | Governing regime |
|---|---|---|---|
| Parent or guardian, acting within their lawful authority | Family AI assistant | Limited authority to seek learning material for the child; no purchase or disclosure beyond the configured limits | Applicable national family and child-protection law, together with the service terms and applicable data-protection law; the extent of parental authority must be established, not assumed |
| Family AI assistant, within its received authority | External education service or its agent | A narrower request to retrieve specified learning material; no independent authority to expand data use or initiate a purchase | The original mandate's constraints, applicable service agreement and applicable data-protection law |
| Parent or guardian, acting within their lawful authority | Family-side policy enforcement point | Instructions governing what material may be delivered to the child's profile | Applicable national family and child-protection law, applicable data-protection law and the household policy |
Cross-border?
- [x] Yes — jurisdictions involved: the child's jurisdiction and the jurisdiction(s) of the external AI service and identity provider; specific countries to be selected for testing.
- [ ] No
Embodied (physical actuation or sensing)?
- [x] Yes — physical context: A child may interact with an AI agent through a smartwatch or other connected device. The agent may use device sensors or trigger a physical-world response as part of a safety function.
- [ ] No
Agent action type (required; tick all that apply. Where several apply, the most
consequential governs the case)
- [x] Read-only
- [x] Consequential (reversible)
- [x] Irreversible
Most consequential action: Disclosure of the child's personal information to an external service, or delivery of material that cannot be recalled once seen. Delivery of harmful, age-inappropriate material to a child. Once the child has received it, the exposure cannot be undone.
Crosses organisational boundary? (required)
- [x] Yes (specify): The family assistant invokes an independently operated education service.
- [ ] No
Risk level (required)
- [ ] Low
- [ ] Medium
- [x] High
4. Theme relevance
| Theme | Yes | Primary | Justification (required if checked) |
|---|---|---|---|
| Dynamic Identity | [x] | [ ] | The receiving service needs to recognise that the assistant is acting for a child profile, without receiving the child's full identity or a persistent cross-service identifier. |
| Continuous Trust and Attestation | [x] | [ ] | The validity and status of the child-profile assertion and delegated authority may change between the initial request and the decision to act. Attestation may be relevant where the chosen trust model requires it. |
| Delegation | [x] | [x] | The assistant's authority originates with the parent or guardian and must remain limited when it calls an external service. The service must distinguish authority to act from permission to deliver material to the child. |
| Discovery and Cross-Border Trust | [x] | [ ] | The child, identity provider and external service may be in different jurisdictions. The relying party needs to identify the relevant trust authority and determine which applicable policy governs its decision. |
| Runtime Enforcement (Control Plane) | [x] | [ ] | The applicable content policy must be enforced before material reaches the child. Action limits, such as data disclosure or purchases, require a separate enforcement decision. |
| Embodied AI Identity and Trust | [x] | [ ] | A smartwatch or other connected device may host or interact with the agent, provide sensor inputs, or carry out a safety-related action. The system must establish which device and agent are acting, under whose authority, and with what limits. |
Related theme proposals: Age-Aware Identity and Delegated Authority for Agentic AI (#25); Network-Native Governance and Trust Enforcement for Agentic AI (#10). ATHENA, if submitted as a TIDA theme, would provide a related architectural perspective on trusted roots, delegation and identity lifecycle.
5. Requirements
| # | Type (choose one) | Requirement description | Criticality (choose one) |
|---|---|---|---|
| 1 | Technical | The relying party can verify that the assistant has a valid, scoped mandate to act for the child profile without receiving the child's full identity. | Must |
| 2 | Technical | An onward request to another agent or service cannot expand the authority granted to the family assistant. | Must |
| 3 | Technical | The architecture distinguishes an agent's authority to request or perform an action from the separate decision about what material may be delivered to the child. | Must |
| 4 | Technical | The applicable content policy is evaluated and enforced before delivery to the child, since exposure cannot be reversed after delivery. | Must |
| 5 | Technical | Where a family-side enforcement point can make the delivery decision, child-profile attributes are not passed to external services solely for content filtering. | Must |
| 6 | Technical | Where an external service must make an action or delivery decision, it receives only the minimum verifiable attributes and policy signals needed for that decision. | Must |
| 7 | Technical | The relevant enforcement point can detect an expired, suspended or revoked mandate before committing a consequential action or delivering material. | Must |
| 8 | Technical | The architecture defines what happens when a parent changes a policy while a request is in flight, including when delivery must pause pending a fresh decision. | Must |
| 9 | Technical | The decision process can account for the applicable jurisdiction and policy without assuming that one age threshold or content classification applies globally. | Must |
| 10 | Technical | If the child's status or applicable policy cannot be established with sufficient confidence, the system does not silently treat the request as an unrestricted adult-profile interaction. | Must |
| 11 | Legal | The trust model identifies the source and scope of a claimed parental mandate, while leaving its legal validity and applicable child protections to the relevant jurisdiction. | Must |
| 12 | Technical | Proportionate evidence of the authority check and delivery decision can be retained without creating a central record of the child's activity across services. | Should |
6. Assessment criteria
Success criteria: In a test scenario, an authorised request for suitable learning material succeeds without disclosing the child's full identity. An out-of-scope action is rejected, and material that the applicable child-profile policy does not permit is stopped before delivery. A revoked mandate or changed policy is reflected in the decision before a consequential action or delivery is committed.
Measurable metric: Test pass/fail results for valid, expired, revoked and over-scoped mandates; test pass/fail results for permitted and restricted delivery decisions; proportion of restricted test material stopped before delivery; time taken for a policy change to reach the relevant enforcement point; and the number of child attributes disclosed to each external party. Target values would be set by a future pilot rather than asserted in this use case.
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: ITU Council Working Group on Child Online Protection (CWG-COP) and the wider ITU COP initiative; ITU-T SG17 X.PARCEP on interoperable parental-control policy and enforcement; ITU-T SG17 XSTR.ATHENA on agent identity and delegation architecture; and the IAB/W3C Workshop on Age-Based Restrictions on Content Access, reported in RFC 9998.
Overlap notes: The ITU COP work provides the broader child-protection context, while X.PARCEP addresses parental-control policy and enforcement. The IAB/W3C workshop examined architectural choices for age-based access restrictions, and XSTR.ATHENA addresses agent identity and delegation. This use case does not seek to duplicate that work. It tests the specific interface between an AI agent's delegated authority, cross-service trust, and the decision to enforce a child's protection policy before material is delivered.
8. Maturity
Pilot status
- [x] Hypothetical
- [ ] Pilot in progress
- [ ] Deployed in production
Reference implementation: n/a
9. IP and confidentiality
Confidentiality level
- [x] Public
- [ ] FG-internal only
- [ ] Redact before publication
IP notes (optional): This use case states functional requirements and does not specify a patented implementation. Any applicable IP declarations should be handled through the relevant ITU-T process.
10. Assets
Link to assets:
- [ ] Dataset
- [ ] Code
- [ ] Protocol
- [x] Other: Related TIDA theme proposals #25 and #10; no implementation asset attached.
IP notes (optional): No additional IP-bearing assets are submitted with this use case.
Revisions
- No file revisions have been uploaded.