[Use Case] Federated ecosystem defense across independently governed organizations

1. Identification

Title: Federated ecosystem defense for delegated multi-agent workflows across independently governed organizations

Submitting organization: Individual expert contribution (FG-TIDA participant)

Contact name: Nelson Trasatti

Contact email: trasatti.nelson@gmail.com

Sector:

• [ ] Education
• [ ] Health
• [ ] Financial services
• [ ] Telecom
• [ ] Logistics
• [ ] Energy
• [ ] Critical infrastructure
• [ ] Smart home / IoT
• [x] Other (specify): Cross-sector infrastructure for independently governed agentic ecosystems

2. The situation

Describe one concrete situation: who is acting, what they are doing, what went wrong, how it is handled today, and why that handling falls short.

Plain language description :
An agent operated by one organization delegates a bounded data-processing task to an agent operated by an independent service provider. Through semantic reinterpretation, accumulated delegation or behavioural drift, the downstream agent attempts an authenticated action outside the original project scope, such as modifying an unrelated shared record or forwarding output to an undelegated service. Each organization observes only part of the event and lacks an interoperable way to correlate evidence, estimate affected scope and coordinate proportionate containment without a common central controller.

Actor: An initiating agent acting for an organizational principal; a downstream service agent operated by an independent organization; local runtime evaluators; relying parties; attestors; and authorized human overseers.

Action: Processing synthetic project data and performing one scoped, reversible update across an organizational boundary under a delegated mandate.

Problem encountered: Authentication and local access-control checks may remain valid while the downstream action no longer reflects the original intent, current delegation scope or declared operating policy. Each participant holds only partial evidence and local authority, allowing effects to propagate before the combined significance is recognized.

Current mitigation: Each organization can block a local request, revoke a local credential, suspend its own agent or conduct a manual investigation. Notifications, evidence formats, response deadlines and containment semantics remain bilateral, inconsistent or absent.

Residual gap: No common, implementation-neutral information model and workflow connects local runtime findings, authority and delegation evidence, residual uncertainty, affected-scope information and available response capacity so heterogeneous parties can corroborate an incident and coordinate locally authorized containment.

3. Actors and context

Taxonomy roles involved

• [x] Builder
• [x] Deployer / Owner
• [x] Agent instance
• [x] User
• [x] Infra provider
• [x] Attestor
• [x] Other (specify): Relying party, runtime evaluator, external service provider and authorized human overseer

Cross-border?

• [ ] Yes - jurisdictions involved:
• [x] No - the Stage 1 mechanism is not jurisdiction-specific; cross-border sector profiles may be connected later

Embodied (physical actuation or sensing)?

• [ ] Yes - physical context:
• [x] No

Agent action type (required)

• [ ] Read-only
• [x] Consequential (reversible)
• [ ] Irreversible

Crosses organisational boundary? (required)

• [x] Yes (specify): Principal/deployer, external agent provider, infrastructure provider, evaluator/attestor and relying party
• [ ] No

Risk level (required)

• [ ] Low
• [ ] Medium
• [x] High - unauthorized data action, cross-organizational propagation and delayed containment

4. Theme relevance

Check every theme this situation exercises, mark the single primary theme, and justify each checked theme against Section 2 above.

5. Requirements

One row per requirement. Type: Legal / Business / Technical. Criticality: Must / Should / Nice-to-have.

6. Assessment criteria

Success criteria:

1. Independent organizations exchange and appraise a signal while retaining separate policies and decision authorities.
2. A valid delegation-scope or behavioural-drift finding is contained before the declared response window expires or the affected scope expands.
3. Replayed, expired, malformed, falsely attributed and correctly signed but out-of-mandate signals do not produce unauthorized containment.
4. Corroboration and amendments change the current incident assessment without erasing earlier claims.
5. The blast-radius representation distinguishes observed, inferred and possible exposure.
6. The determinacy envelope and signal lifecycle are independently testable and interoperable without exposing internal assessment logic.
7. A change in Theme #16 human-oversight capacity can affect the Theme #13 assessment, which can in turn alter Theme #16's intervention path.
8. The campaign distinguishes non-adversarial failures, internal compromise and external attack, and fails safely if signalling or containment is attacked.
9. The Stage 1 harness can import a mutually admitted, versioned external use case through a bounded adapter without changing the core signal, corroboration or containment mechanisms. The source contributor supplies or validates domain semantics, fixtures and expected outcomes; source revisions create no automatic implementation obligation for the testbed maintainer.

Measurable metric:

• Detection-to-signal and signal-to-local-decision latency.
• Containment completion relative to the declared response window.
• Precision and recall of affected-scope identification, separated by observed and inferred exposure.
• Rejection rate by hostile-signal class; false-positive and false-negative containment rates.
• Percentage of actions carrying attributable authority, policy, verdict and decision records.
• Corroborator count and inter-participant determination convergence.
• Percentage of unaffected legitimate workflows preserved; restoration and revalidation time.
• Coverage and containment rates by non-adversarial, internal or external origin; human, AI or hybrid initiator; target layer; and intended effect.
• Pass/fail conformance by imported contract version and frozen test-vector identifier.

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-T FG-TIDA Terms of Reference, especially clauses 3.3-3.5, 4.1-4.5 and relevant Annex A items.
• FG-TIDA Themes #1, #5, #6, #7, #10, #12, #13, #16, #18, #19, #21 and #22.
• IETF RATS/EAT and AR4SI; WIMSE and workload-identity work.
• OASIS STIX 2.1, TAXII 2.1, OpenC2 and XACML 3.0.
• NIST SP 800-207, SP 800-162 and AI RMF; MITRE ATT&CK/ATLAS; OpenTelemetry agent-observability work.
• Conditionally applicable EU AI Act, NIS2, GDPR and Swiss data-protection requirements; sector-specific obligations remain with the connected sector use case.

Overlap notes: Existing work supplies threat-information models and transport, response commands, policy languages, identity and attestation, observability and risk-management practices. This use case does not define a general agent protocol, authority provenance, runtime-conformance algorithm or universal reputation score. It tests the remaining interoperability gap connecting agentic findings and delegation evidence to Ecosystem Awareness, a privacy-preserving signal lifecycle, affected-scope representation and proportionate locally authorized containment. Defense is the first concrete use, not the foundation's exclusive future scope.

8. Maturity

Pilot status

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

Reference implementation: N/A - planned progressive open reference testbed:

0. Deterministic harness - frozen fixtures and reproducible expected outcomes.
1. Federated cross-theme minimum - the initial implementation across independently governed organizations.
2. Regulated financial integration profiles - multiple independently maintained financial scenarios; FG-TIDA/use-cases PR #2 is the first candidate profile, not the definition or entirety of this stage.
3. Open multi-service ecosystem - longer delegation chains, partial observations and multiple providers.
4. Ecosystem security and resilience campaign - agent-native failures, internal compromise and external attacks.
5. Resolution and revalidation - attributable recovery and controlled return to operation.

Only Stages 0-1 form the initial implementation commitment. Stages 2-5 are explicit roadmap extensions activated separately through review, contributor participation, stable inputs and available resources. Each admitted profile requires a mutually agreed, version-pinned boundary and source-contributor validation; no later stage creates a standing obligation for the Stage 1 maintainer to implement independently maintained mechanisms or subsequent revisions.

9. IP and confidentiality

Confidentiality level

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

IP notes (optional): The submission is an individual expert contribution. Future code, datasets and protocol artifacts will identify authors, maintainers, versions and licenses separately. The generic testbed maintainer does not assume responsibility for implementing or maintaining independently authored theme logic outside an explicitly accepted adapter scope. No conformity, certification, endorsement or regulatory-compliance claim is made.

10. Assets

Link to assets:

• [ ] Dataset
• [x] Code
• [x] Protocol
• [x] Other: Non-normative testbed roadmap

Assets are planned after scope acceptance; the repository URL will be added when Stage 1 work begins.

IP notes (optional): No existing asset is represented as an FG-TIDA deliverable. Any future implementation will be versioned and licensed explicitly and will remain separable from the implementation-neutral use-case requirements.