FUURAA AI Civilization Architecture · Operating-layer engineering dossier

Delegation chain: make authority shrink at every handoff

Delegation is not forwarding a login, session or powerful token. A reviewable chain keeps the original principal, current actor, parent decision and every intermediate handoff visible while deriving a shorter-lived, narrower capability for the next receiver.

Public statusResearch direction · architecture referenceEvidence statusFUURAA method synthesis grounded in primary standardsSources checked19 August 2026

Core decision

Can every downstream Agent prove who delegated what—and that no handoff enlarged it?

Use this sequence for architecture review, threat modelling and test planning. It is not a universal compliance checklist and cannot replace system-specific engineering validation.

  1. 01

    Name principal, subject and current actor

    Distinguish the represented principal, executing Agent, delegating actor, issuer and receiving audience before authority is evaluated.

  2. 02

    Derive from one parent decision

    Reference the exact parent envelope and calculate the child capability, resource, fields, purpose, conditions and explicit exclusions.

  3. 03

    Attenuate time, audience and consequence

    Issue a shorter expiry, a specific audience, tighter budgets and a consequence ceiling that cannot exceed the parent.

  4. 04

    Re-decide at every handoff

    Let each receiver validate policy, actor, parent state, semantics and revocation instead of trusting upstream success.

  5. 05

    Propagate revocation and close the chain

    Stop queued, cached and retried descendants when an ancestor expires or is revoked, then preserve residuals and accountable closure.

FUURAA analysisA delegation chain is only as trustworthy as its weakest handoff. Every child authority should be derived—not copied—and should become narrower in capability, audience, duration and consequence. Prior actors remain essential accountability history, but they must never silently become current permission. Safe composition therefore requires both attenuation and independently decidable refusal at every receiver.

Minimum interface contracts

Put consequential semantics in inspectable interfaces instead of relying on assumptions between systems.

Field names are public engineering references, not a normative protocol. Implementations may use other structures, but should expose every lost, defaulted or downgraded semantic.

01

Principal and actor-chain contract

Must be intelligible to sender, receiver and independent reviewer.

Minimum fields
  • original principal, current subject and current actor
  • issuer, audience and ordered handoff references
  • delegation versus impersonation mode
Evidence gate

A receiver can distinguish whose authority is represented from which Agent is acting now.

Stop condition

If the contract is unresolved, expired or silently downgraded, block consequential action and route to review.

02

Capability-attenuation contract

Must be intelligible to sender, receiver and independent reviewer.

Minimum fields
  • parent decision and child derivation rule
  • capability, resource, fields, exclusions and budgets
  • purpose, audience, consequence ceiling and expiry
Evidence gate

The child is demonstrably no broader, longer-lived or more consequential than its parent.

Stop condition

If the contract is unresolved, expired or silently downgraded, block consequential action and route to review.

03

Continuity and closure contract

Must be intelligible to sender, receiver and independent reviewer.

Minimum fields
  • policy version, decision trace and revocation handle
  • downstream inventory, retry state and cached copies
  • residuals, closure owner and successor action
Evidence gate

An ancestor change can stop descendants and leave a reviewable final state.

Stop condition

If the contract is unresolved, expired or silently downgraded, block consequential action and route to review.

Failures to seek deliberately

Verify that boundaries really deny, stop and preserve evidence.

Nominal success cannot establish an effective boundary. Tests should manipulate identity, time, version, network, policy and partial failure while retaining raw outcomes.

T1

Privilege amplification

Ask a child Agent for an extra resource, field, recipient, duration or budget and require an explicit denial.

T2

Confused deputy

Present valid authority for one principal while directing the receiver toward another principal's resource.

T3

Revoked ancestor

Revoke or expire an upstream decision while descendants are queued, cached or retrying and verify that all stop.

T4

Hidden impersonation and chain truncation

Remove an intermediate actor or relabel impersonation as delegation and require rejection with the missing history recorded.

Minimum engineering evidence package

Let the next owner reproduce the decision, open artefacts and see remaining unknowns.

A complete package only makes evidence relationships reviewable; it does not prove artefacts authentic, controls effective, the system safe or the decision correct.

01

Issued delegation graph

Ordered principal, subject, actor, issuer, audience, parent and child identifiers with validity state.

02

Parent-to-child authority diff

Machine-readable proof of removed scope, reduced budgets, shorter expiry and unchanged exclusions.

03

Handoff decision trail

Policy versions, inputs, reasons, denials, approvals and semantic-loss findings at every receiver.

04

Runtime delegation trace

Calls, effects, retries, actor changes, ancestor-state checks, exceptions and preserved raw outcomes.

05

Revocation and closure proof

Descendant inventory, propagation results, residual capabilities, accountable owner and review time.

Applicability boundary

This public research reference is not a FUURAA delegation protocol, credential, token profile, production feature, legal agency instrument or compliance control. A structurally complete chain cannot establish valid consent, employment or fiduciary authority, policy sufficiency, competent execution, liability allocation or successful revocation; consequential use requires system-specific design, testing and accountable approval.

Primary sources and evidence boundaries

Use standards language without presenting citations as implementation evidence.

Every source states publication timing, its role in this dossier and its non-transfer boundary; living source pages were checked 19 August 2026.

Published 1 August 2025

NIST SP 800-63-4 · Digital Identity Guidelines

Separates identity proofing, authentication, federation, assertions and assurance.

BoundaryWritten for users of government information systems; it does not define autonomous-Agent identity or authorise an action.

Open primary source ↗
Standards Track · January 2020

IETF RFC 8693 · OAuth 2.0 Token Exchange

Defines security-token exchange, impersonation and delegation semantics, including subject and actor relationships.

BoundaryToken exchange represents protocol relationships; it does not prove real-world authority, consent, policy correctness or safe downstream action.

Open primary source ↗
Standards Track · May 2023

IETF RFC 9396 · OAuth 2.0 Rich Authorization Requests

Carries fine-grained authorization details beyond coarse scope strings.

BoundaryMachine-readable details do not establish that the requester is entitled, the policy is sufficient or the consequence is acceptable.

Open primary source ↗
Published 10 August 2020

NIST SP 800-207 · Zero Trust Architecture

Frames resource-centred access decisions without implicit trust from network location.

BoundaryAn enterprise cybersecurity architecture, not an Agent capability schema, complete implementation or certification.

Open primary source ↗
Best Current Practice · January 2025

IETF RFC 9700 · OAuth 2.0 Security BCP

Documents current OAuth 2.0 threat mitigations and deprecates weaker modes.

BoundaryIt secures an authorisation framework; it does not decide an Agent's business purpose, real-world authority or acceptable consequence.

Open primary source ↗
W3C Recommendation · 30 April 2013

W3C · PROV-DM

Relates entities, activities, responsible agents, time and derivation across a provenance trail.

BoundaryProvenance can describe lineage; it does not prove truth, rights clearance, secure storage or decision quality.

Open primary source ↗
Published 26 January 2023

NIST AI RMF 1.0

Connects governance, context mapping, measurement and risk treatment across the AI lifecycle.

BoundaryVoluntary and use-case agnostic; it is not a safety case, sector rule, audit or certification.

Open primary source ↗