SearchContact us

FUURAA AI Civilization Architecture · Operating-layer engineering dossier

Action authorization envelope: make one request decidable end to end

An Agent action should not inherit authority from a login, tool connection, remembered instruction or successful prior call. A portable authorization envelope binds one request to the exact subject, principal, purpose, capability, resource, policy decision, plan, expiry, revocation handle and evidence trail that make it decidable across system boundaries.

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

Core decision

Can every receiver decide what may happen, why, until when—and how to stop 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

    Create an immutable request identity

    Issue request_id, trace_id, schema version, issuer and observed time before any consequential planning or tool call.

  2. 02

    Bind subject, principal and purpose

    Resolve the runtime subject, represented principal, authenticated assertions, approved purpose and operating context without treating identity as permission.

  3. 03

    Resolve exact authority

    Name capability, verb, resource, fields, exclusions, budgets, policy version, approvals, effective time, expiry and revocation.

  4. 04

    Freeze execution boundaries

    Attach the versioned plan, tool schemas, expected effects, checkpoints, idempotency key, rollback or compensation and escalation path.

  5. 05

    Decide, execute and close

    Let each receiver deny unsupported semantics, then preserve decisions, effects, retries, exceptions, residuals and accountable closure under one trace.

FUURAA analysisThe useful unit of Agent authority is not a session, API token or broad role; it is a short-lived decision attached to one explainable action envelope. The executable plan should never be able to enlarge that envelope, and every receiver should be allowed to refuse missing or downgraded semantics. Safe denial is therefore a successful operating-layer outcome, not merely an error path.

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

Identity and intent contract

Must be intelligible to sender, receiver and independent reviewer.

Minimum fields
  • request_id, trace_id, issuer and schema version
  • subject, delegating principal and authenticated assertions
  • purpose, context, audience and requested outcome
Evidence gate

A receiver can distinguish who executes, who authorised and why this one request exists.

Stop condition

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

02

Authority and consequence contract

Must be intelligible to sender, receiver and independent reviewer.

Minimum fields
  • capability, action, resource, fields and explicit exclusions
  • policy decision, approvals, conditions, budgets and consequence class
  • effective time, expiry, revocation handle and re-authorisation boundary
Evidence gate

Authority is narrower than both the user's broad role and the tool's technical capability.

Stop condition

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

03

Execution and evidence contract

Must be intelligible to sender, receiver and independent reviewer.

Minimum fields
  • plan version, tool contract, checkpoint and idempotency key
  • expected effect, rollback or compensation and escalation owner
  • decision, effect, retry, exception, residual and closure references
Evidence gate

A partial, retried or denied action remains distinguishable from a complete authorised outcome.

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

Subject substitution

Swap the runtime Agent or represented principal after approval and require a new decision rather than inherited authority.

T2

Expired replay

Replay a previously valid envelope after expiry, revocation or policy change and verify that queued and retried calls stop.

T3

Scope smuggling and downgrade

Add a field, resource, recipient or unsupported schema semantic and require explicit rejection with the lost meaning recorded.

T4

Effect-before-response failure

Break the connection after an external effect, retry the request and prove idempotency, trace continuity and responsible recovery.

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 envelope snapshot

Exact request, schema, subject, principal, purpose, audience, authority, validity and revocation state.

02

Policy and approval decision

Versioned inputs, policy outcome, reasons, conditions, approvers, dissent and re-open triggers.

03

Plan and tool-contract package

Steps, dependencies, schemas, budgets, expected effects, checkpoints, rollback and escalation.

04

End-to-end action trace

Decisions, calls, effects, retries, denials, transformations, exceptions and preserved raw outcomes.

05

Closure and handoff record

Final state, unresolved residuals, evidence location, accountable owner, review time and successor action.

Applicability boundary

This public research reference is not a FUURAA protocol, credential format, production schema, security control, legal authorisation or compliance checklist. Structural completeness cannot establish identity truth, actual authority, policy correctness, safe execution or successful revocation; consequential deployments require system-specific threat modelling, 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 ↗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 ↗Internet-Draft · 16 June 2022

JSON Schema 2020-12 · Validation Vocabulary

Provides vocabulary for type, required-property and structural validation.

BoundarySchema-valid data may still be stale, unauthorised, semantically incompatible or false.

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 ↗

Continue through the operating layer

Move across all six disciplines while preserving one action and evidence chain.

← Interoperability: preserve meaning at every boundaryDelegation chain: make authority shrink at every handoff →Return to the Agent Operating LayerReturn to AI Civilization Architecture