OSARA — Open Sovereign Agent Reference Architecture¶
Mandatory Component Specification for Open Source AI Agents Personal · Enterprise · Government — Identity · Encryption · Portability · Integrity · Audit · Certification
Published by Open Source United, a Community of Practice of the United Nations.
Version 0.4 — Draft for Public Comment — March 2026
Copyright © 2026 Open Source United — Released under CC BY 4.0 International License. Principal Author acknowledged in §20.
Status of This Document¶
This is the current editable working draft of the OSARA Open Sovereign Agent Reference Architecture, version v0.4-draft.1. It is published for public comment under the governance of Open Source United and the OSARA Steering Committee.
- Stable identifier:
urn:osu:osara:v0.4-draft.1 - Editor's draft: this file (
specs/osara/current.md) - Immutable snapshot:
specs/osara/releases/v0.4-draft.1.md - Maturity level: Public Comment Draft (analogous to a W3C Working Draft / IETF Internet-Draft)
- Public comment period: open — submit via the OSU public RFC process or repository issues.
- Errata: see Errata Register.
- Companion document: AI Bill of Rights v1.1.
This document supersedes v0.3-draft.1. Substantive changes relative to v0.3 are summarised in the Changelog.
This document mixes normative material (mandatory requirements for compliant implementations) with informative material (background, motivation, examples). Each top-level section header is tagged [Normative] or [Informative] accordingly.
A future major version of OSARA will split this document into a family of focused normative profiles (OSARA-CORE, OSARA-IDENT, OSARA-NET, OSARA-CONF) and a stand-alone informative reference architecture document, in line with the practice of W3C, IETF, NIST, and ISO/IEC. See the Roadmap.
Terminology and Conformance Language¶
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 (RFC 2119 and RFC 8174) when, and only when, they appear in all capitals as shown here.
Conformance Classes¶
An implementation claims OSARA conformance by satisfying every requirement in the normative sections of this document that applies to its declared agent tier. The conformance claim is expressed through the badge tiers defined in §17:
| Conformance Class | Required Tiers | Required Sections |
|---|---|---|
| OSARA-C (Conformant) | All applicable normative sections for the declared agent tier (P / E / G) | §§4–17 |
| OSARA-A (Audited) | OSARA-C plus successful manual audit per §17 | §§4–17 + audit attestation |
| OSARA-S (Sovereign) | OSARA-A plus government-issued GIAC | §§4–17 + GIAC issuance per §4.5 |
A conforming implementation MUST publish a Conformance Statement identifying its declared tier, conformance class, OSARA schema version, and any optional features it implements.
1. Purpose and Scope¶
This section is informative.
OSARA defines the mandatory components, encryption requirements, identity standards, port specifications, skill integrity rules, portability requirements, integrity architecture, and certification criteria that any compliant Open Source AI Agent must implement — regardless of its tier (Personal, Enterprise, or Government).
OSARA is published and stewarded by Open Source United, a Community of Practice of the United Nations. It is an open specification — anyone may implement it freely under CC BY 4.0, provided they credit Open Source United as the origin.
What OSARA Is NOT
OSARA does not mandate which AI model powers an agent, nor how agents are built internally. Agents may be powered by frontier AI models via secure API, locally hosted open source models, or a combination of both. OSARA mandates only the structural components, identity, encryption, portability, integrity, and audit requirements needed to participate in the certified ecosystem.
2. The Three-Tier Agent Model¶
This section is informative.
OSARA defines three sovereign agent tiers. Each tier has its own ownership boundary, government-anchored identity, mandatory components, and portability requirements. All three tiers use the same Government-Issued Agent Certificate (GIAC) — distinguished by profile encoded in the certificate's osara.tier extension field.
| Tier | Ownership, Identity Anchor, and Hosting | GIAC Profile |
|---|---|---|
| Personal Agent (P-Agent) | Owned by an individual. Identity is cryptographically anchored to a government-recognized identity credential, the specific form of which is determined by the owner's national jurisdiction. Lowest privilege. Owner bears full responsibility for hosting, updates, and health. Must run in PaaS or local modality — never SaaS. Community Agent Hosts (non-profit PaaS) are a permitted alternative for individuals without technical infrastructure. | GIAC-P · osara.tier = P · Issued by national identity authority · Key held in Owner Authorization Device (OAD) — phone secure enclave, government smart card, or FIDO2 key · Auth model: single owner |
| Enterprise Agent (E-Agent) | Owned by a registered legal entity. Identity is anchored to the entity's government-issued tax or registration identifier (EIN, VAT ID, Company Registration Number, or jurisdictional equivalent). Mid-level privilege. Can interact with P-Agents and G-Agents under licensed scope. Owner responsible for all sub-agents it initiates. | GIAC-E · osara.tier = E · Issued by commercial registry or chamber of commerce CA · Key held in enterprise HSM under M-of-N multi-signature scheme · Auth model: designated keyholders via personal OADs |
| Government Agent (G-Agent) | Owned by a recognized government or regulatory body. Identity is anchored to the official government entity registration identifier per constitutional or statutory authority. Highest privilege. Issues GIACs. Defines audit rules. Responsible for all sub-agents it initiates. | GIAC-G · osara.tier = G · Issued by national PKI / government CA · Key held in government HSM · Auth model: role-based via government employee credentials |
One Name, Three Profiles
GIAC is the single certificate name for all agent types. The
osara.tierfield (P / E / G) identifies the profile. An inspection entity, MCP server, or peer agent verifying a GIAC follows the same process regardless of type: check the certificate, verify the signature chain to the issuing authority, confirm validity. The issuing CA differs by tier. The protocol is identical.
3. Architecture Diagram¶
This section is informative.
The diagram below illustrates the full three-tier agent ecosystem — how P-Agents, E-Agents, and G-Agents are structured, how they communicate, and how identity is established and verified at every interaction.
Figure 1 — OSARA Agent Ecosystem: Communication Flows and Authentication Chain
3.1 Diagram Key¶
| Arrow Type | Meaning |
|---|---|
| Solid dark lines | Direct GIAC issuance from the Government Certificate Authority to agents |
| Dashed gold lines | Delegated certificate flows — GCA issues to E-Agents and P-Agents via Registration Authority |
| Solid blue lines | Enterprise-to-enterprise communications over mutual TLS 1.3 on port :4401 |
| Solid light blue lines | P-Agent initiated interactions toward E-Agents (consent token required) |
| Dashed purple lines | Audit and certification flows between agents and the OSARA Audit Body (OAB) |
| Dashed gray lines | Certificate verification lookups against the Public Certificate Ledger (PCL) |
| Dashed green lines | Skill signature and catalog flows |
| Teal lines | Portable Memory Store migration and access flows |
3.2 Authentication Flow — Step by Step¶
This section is normative.
| Step | Description |
|---|---|
| Step 1 — Present GIAC | Connecting agent presents its GIAC on AIM port :4400. The certificate encodes tier, scope, jurisdiction-specific identity anchor hash, and GCA signature. |
| Step 2 — Verify Signature | Receiving agent fetches the GIAC and cryptographically verifies the GCA signature. |
| Step 3 — Check PCL & CRL | Receiving agent checks the PCL and Certificate Revocation List to confirm the certificate has not been revoked. |
| Step 4 — Enforce Tier Rules | Tier interaction rules are validated: scope authorization, consent tokens, and licensing checked. |
| Step 5 — Physical Auth if Inspection | If the session is an inspection, the owner physically authorizes connection via their Owner Authorization Device (OAD). |
| Step 6 — mTLS Handshake | Mutual TLS 1.3 handshake on port :4401 with Perfect Forward Secrecy. |
| Step 7 — Double Encryption | Payloads double-encrypted: outer TLS + inner AES-256-GCM keyed to recipient AIM public key. |
| Step 8 — Synchronized Audit Log | Transaction written to ALL parties' ALE within a ±500 ms tolerance window referencing a common NTP/GPS time source. Excess drift triggers transaction review flag. |
4. Government-Anchored Identity and Owner Authorization¶
This section is normative.
Every OSARA agent MUST be cryptographically bound to a government-recognized identity anchor. The specific form of this anchor is determined by the owner's national jurisdiction. National implementations of OSARA define which government credentials are acceptable within their jurisdiction.
4.1 Identity Anchors by Tier¶
| Agent Tier | Identity Anchor (Jurisdiction-Defined) | Implementation Rule |
|---|---|---|
| P-Agent (Personal) | A government-recognized personal identity credential as defined by the owner's national jurisdiction. Examples include national identity card, digital ID wallet, passport identifier, or equivalent credential accepted by the national OSARA Registration Authority. | The identifier MUST be hashed using SHA-3-256 with a government-issued salt and embedded in the GIAC. The raw identifier MUST NEVER be stored, transmitted, or logged. National implementations specify which credentials qualify. |
| E-Agent (Enterprise) | Government-issued entity identifier used for tax or registration purposes (EIN, VAT ID, Company Registration Number, or jurisdictional equivalent). | The entity ID hash MUST be embedded in the GIAC. The GCA MUST validate the entity is in good legal standing before issuance. |
| G-Agent (Government) | Official government entity registration identifier per constitutional or statutory authority. | Cross-border G-Agent interactions MUST require bilateral OSARA treaty validation of identity anchors. |
Jurisdiction Flexibility
OSARA deliberately does not mandate a specific government ID type. Each country's national OSARA implementation authority determines which government-recognized credentials are acceptable identity anchors within their jurisdiction. This allows democracies, federal systems, and countries with different ID frameworks to implement OSARA without being forced into a single identity model.
Privacy Protection
The raw identity credential is NEVER stored in the GIAC, in any log, or transmitted in any message. Only a one-way SHA-3-256 hash combined with a government-issued salt is embedded. The original credential cannot be reverse-engineered from the hash.
4.2 Physical Owner Authorization — Tamper-Proof Access Control¶
Every agent of all tiers MUST implement a Physical Owner Authorization (POA) module — a mandatory tamper-proof component that gates inspection access and administrative actions behind real-time physical authorization by the owner.
| Ref | Requirement |
|---|---|
| POA-01 | The agent MUST expose a dedicated Inspection Clearance Endpoint (ICE) that is closed by default and requires explicit physical owner authorization to open. |
| POA-02 | Physical authorization MUST use at minimum ONE of the following, of equal standing: (a) biometric verification — fingerprint, facial recognition, or iris scan; OR (b) hardware security token physically held by the owner (FIDO2/WebAuthn compliant). Both methods are fully equivalent — neither is a lesser fallback. |
| POA-03 | Individuals who cannot use biometric methods due to disability, medical condition, or religious objection MUST be accommodated via the hardware security token path without any reduction in rights or functionality. |
| POA-04 | ICE access MUST grant a time-limited session (maximum 4 hours) to the authorized inspection entity. Session MUST automatically close on expiry. |
| POA-05 | Every ICE access event MUST be logged in the ALE with: authorization method used, inspector identity hash, session duration, and actions performed. |
| POA-06 | The POA module MUST be tamper-evident: any tampering attempt MUST trigger an immediate owner alert and lock the agent into restricted mode. |
| POA-07 | No remote override of physical authorization is permitted — not by cloud providers, AI model providers, or any government entity without a court-ordered physical access procedure under applicable national law. |
| POA-08 | For inspection entities to connect to the ICE, the owner MUST be physically present and authorize the connection in real time using their chosen POA method. |
4.3 Owner Authorization Device (OAD) Specification¶
The Owner Authorization Device is the physical device that holds the GIAC private key in a hardware secure element and authenticates the owner to authorize agent actions. The OAD is architecturally separate from the Agent Runtime. The private key MUST NEVER leave the OAD hardware.
OAD Hardware Trust Tiers¶
| Tier | Definition |
|---|---|
| Tier A (Hardware Secure Element) | The GIAC private key is generated and stored inside a dedicated hardware security chip. The key cannot be extracted by software, by root-level access, or by the device manufacturer. Physical tamper-response destroys the key if the chip is probed. Qualifies for all action authorization levels. Accepted form factors: smartphone secure enclave (Apple Secure Enclave, Android Titan M, or equivalent); government smart card (ISO 7816 chip — national ID card, DNIe, nPA, or equivalent); FIDO2/WebAuthn hardware security key (YubiKey or equivalent). |
| Tier B (Software-Protected Credential) | The GIAC private key is stored in a software-protected credential store, backed by a TPM 2.0 chip where available. Weaker isolation than Tier A. Qualifies for Action Tier 1 and Tier 2. High-stakes Tier 3 actions require escalation to a Tier A device. Accepted form factors: desktop or laptop with TPM 2.0 + biometric reader; desktop or laptop with TPM 2.0 + PIN-protected credential store. |
| Tier C (PIN/Password Only — Fallback) | No hardware secure element. PIN or password only. Qualifies for Action Tier 1 routine actions only. Treated as a temporary configuration. Agent displays a persistent warning and encourages upgrade to Tier A or B. Annual inspection will flag Tier C as a compliance advisory. |
OAD Action Authorization Tiers¶
| Action Tier | Scope |
|---|---|
| Tier 1 (Routine) | Drafting, reading, researching, summarising. No external action taken. No approval notification required. OAD authenticated at session start is sufficient. |
| Tier 2 (Consequential) | Sending communications, creating or modifying files, connecting to new MCP servers, executing code. Agent sends approval request to OAD. Owner approves or rejects explicitly. OAD Tier A or B required. |
| Tier 3 (High-Stakes) | Financial transactions, legal document signing, irreversible system changes, actions affecting third parties' rights or assets. OAD Tier A required. ALE records full action description, owner OAD tier, and timestamp. |
OAD Interface Requirements¶
| Ref | Requirement |
|---|---|
| OAD-01 | The OAD MUST connect to the Agent Runtime exclusively via the ECL encrypted channel. No plaintext or unauthenticated OAD-to-runtime communication is permitted. |
| OAD-02 | The OAD MUST generate the GIAC key pair internally during provisioning. The private key MUST NEVER be transmitted, exported, or accessible outside the OAD hardware. |
| OAD-03 | The OAD MUST support remote signing: when the Agent Runtime requires a GIAC signature to prove identity to a third party, the runtime sends the data to be signed to the OAD via ECL. The OAD signs with the private key and returns only the signature. The private key never travels to the runtime. |
| OAD-04 | The OAD MUST implement session binding: each authorized session is cryptographically bound to the specific OAD that authorized it. |
| OAD-05 | The OAD MUST enforce action tier rules locally. A Tier B OAD MUST refuse Tier 3 action authorization requests. |
| OAD-06 | Loss or destruction of the OAD MUST be recoverable. Owners MUST be able to register a secondary OAD in advance. Recovery through re-provisioning at a government GIAC registration office is the fallback path. |
4.4 Agent Runtime and OAD Architectural Separation¶
The OSARA agent is composed of two distinct and separately deployable components. These components MUST communicate exclusively via the ECL and MUST NEVER be merged into a single execution environment.
| Component | Definition | Hosting |
|---|---|---|
| Agent Runtime | The execution environment where the agent operates. Contains: AIM (certificate, no private key), ALE, ECL, DAE, HSB, IG, PMS, IMA, model interface layer, Linux execution environment, web browsing capability, and MCP/A2A client connections. | CAH, self-hosted container, employer-provided infrastructure, or OSARA-E / OSARA-G certified infrastructure. NEVER SaaS. NEVER shared with other owners without cryptographic isolation. |
| Owner Authorization Device (OAD) | The hardware device held by the owner. Contains: GIAC private key (in hardware secure element), owner authentication (biometric or PIN), action approval interface, remote signing capability, and ALE viewer. | Always with the owner. Phone app, smart card + desktop app, or FIDO2 key + desktop app. NEVER hosted on any infrastructure the owner does not physically control. |
Agent Runtime Form Factors¶
| Form Factor | Description |
|---|---|
| Container (self-hosted) | OCI-compliant container image. Owner runs on own hardware or private cloud. Maximum sovereignty. Recommended for technically capable owners and enterprises. |
| CAH-hosted container | Agent Runtime container on Community Agent Host infrastructure. Owner interacts via OAD. CAH provides compute, network, and storage only — cannot access AIM, ALE, or PMS contents. |
| OSARA-E certified hosting | Enterprise Agent Runtime on dedicated or on-premises infrastructure meeting the OSARA-E certification standard. |
| OSARA-G sovereign infrastructure | Government Agent Runtime on government-sovereign infrastructure. Cross-border hosting requires bilateral treaty. Required for all G-Agents. |
4.5 GIAC Provisioning Protocol¶
The GIAC Provisioning Protocol defines how a GIAC is issued to a new agent. The protocol is defined at the cryptographic level. The physical transport — NFC tap, USB HSM connection, or secured network API — is a separate concern and does not change the cryptographic guarantees.
GIAC-P Provisioning (Personal Agent)¶
| Step | Description |
|---|---|
| Step 1 — Key generation | The OAD generates a public/private key pair inside its hardware secure element. The private key never leaves the hardware. The OAD exports only the public key as part of a Certificate Signing Request (CSR). |
| Step 2 — Online registration | The owner submits their jurisdiction-defined identity credential reference, surname, contact details, and the OAD's public key CSR to the national GIAC Registration Authority (GRA). The GRA issues a solicitation token to the owner's registered contact. |
| Step 3 — Physical identity verification | The owner appears in person at an accredited registration point (government office, post office, or designated authority) with their solicitation token and physical identity documents. The officer verifies identity and authorizes certificate signing. |
| Step 4 — GIAC delivered to OAD | The GRA delivers the signed GIAC to the owner's OAD via the provisioning transport. The OAD stores the certificate in its secure element alongside the private key. The provisioning channel is sealed permanently after delivery. The raw identity credential is never stored — only the SHA-3-256 hash is embedded in the GIAC. |
| Step 5 — Runtime binding | The owner's OAD pushes the GIAC certificate (not the private key) to the Agent Runtime's AIM via the ECL. The AIM stores the certificate. The runtime is now government-anchored and OSARA-compliant. |
Provisioning Transport Options¶
| Transport | Description |
|---|---|
| NFC | Primary transport for smartphone OADs. Officer taps a government HSM device to the owner's phone. Provisioning channel opens, GIAC delivered, channel seals. Equivalent to how banks provision cards onto Apple Pay and Google Pay. |
| USB HSM | For desktop OADs. Officer connects a government Hardware Security Module in USB form factor to the owner's computer. The USB HSM is a dedicated cryptographic device — not a USB stick running software. The GIAC signing keys live inside the HSM and cannot be extracted. |
| Secured network API | For CAH-hosted agents where the owner cannot bring the runtime to the office. Officer's terminal connects to the owner's Agent Runtime on the CAH via a secured government provisioning network endpoint. Owner is physically present. Cryptographic handshake is identical to NFC and USB transports. |
GIAC-E and GIAC-G Provisioning¶
Enterprise Agent certificates are issued to the legal entity via the national commercial registry or equivalent CA. The private key is held in an enterprise HSM using a minimum 2-of-3 multi-signature scheme. Designated keyholders each authenticate using their personal OAD.
Government Agent certificates are issued through the national PKI infrastructure. Existing government employee smart card infrastructure serves as the authorization device. The key is held in a government HSM and is never associated with any individual person — authorization is role-based.
5. Mandatory Components¶
This section is normative.
Every OSARA-compliant agent MUST implement ALL of the following components. Absence of any single component disqualifies the agent from certification.
5.1 Agent Identity Module (AIM)¶
| Ref | Requirement |
|---|---|
| AIM-01 | MUST hold a valid GIAC containing the owner's hashed jurisdiction-defined identity anchor |
| AIM-02 | MUST generate and store a unique Agent Key Pair (Ed25519 preferred or RSA-4096 minimum) |
| AIM-03 | Private keys MUST be stored in the Owner Authorization Device hardware secure element. The AIM holds the GIAC certificate only — not the private key. |
| AIM-04 | MUST support zero-downtime certificate rotation |
| AIM-05 | MUST expose a read-only public identity endpoint on AIM port :4400 |
| AIM-06 | MUST include agent tier (P/E/G), jurisdiction, and hashed identity anchor in the certificate |
5.2 Encrypted Communication Layer (ECL)¶
| Ref | Requirement |
|---|---|
| ECL-01 | All external communication MUST use TLS 1.3 or higher |
| ECL-02 | Agent-to-agent payloads MUST use double-envelope encryption (TLS + AES-256-GCM keyed to recipient AIM public key) |
| ECL-03 | MUST implement Perfect Forward Secrecy (PFS) via ephemeral Diffie-Hellman key exchange |
| ECL-04 | All payloads MUST include a sender signature (AIM private key via OAD remote signing) to prevent spoofing |
| ECL-05 | API communications to external AI frontier model providers MUST use TLS 1.3 with certificate pinning |
| ECL-06 | The ECL is the exclusive communication channel between the OAD and the Agent Runtime. OAD-to-runtime communication MUST NEVER bypass the ECL. |
5.3 Audit and Logging Engine (ALE)¶
| Ref | Requirement |
|---|---|
| ALE-01 | MUST log every inbound and outbound interaction: timestamp, identity hash, action type, outcome |
| ALE-02 | MUST log every skill acquisition, skill build event, and skill use invocation |
| ALE-03 | MUST log every handshake with any agent, regardless of protocol (GIAC-native, MCP, A2A) |
| ALE-04 | MUST log every purchase or licensing transaction |
| ALE-05 | Logs MUST be cryptographically chained (hash of previous entry in each record). Any modification to any entry breaks the chain and is detected immediately by the IMA heartbeat. |
| ALE-06 | Log retention: 16 months for ALL agent types, mandatory |
| ALE-07 | For MCP and A2A handshakes: all parties MUST record the transaction within a ±500 ms tolerance window referencing a common NTP/GPS time source. Drift beyond tolerance triggers a transaction review flag pending owner review. |
| ALE-08 | Logs MUST be exportable in JSON-LD or CBOR format to authorized auditors |
| ALE-09 | MUST expose authenticated read-only ALE endpoint on port :4402 |
| ALE-10 | MUST log every OAD authorization event: action tier, OAD hardware tier, action description, and outcome. Message content is NOT logged. |
5.4 Delegation and Authorization Engine (DAE)¶
| Ref | Requirement |
|---|---|
| DAE-01 | Scoped permission model: each delegated action MUST specify resource, action type, and time-bound expiry |
| DAE-02 | Delegation tokens MUST be dual-signed by delegating and receiving agents |
| DAE-03 | MUST support delegation chain traversal for authorization verification |
| DAE-04 | Sub-agents initiated by a P-Agent are controlled exclusively by that P-Agent. No external entity may direct, modify, or terminate a sub-agent without explicit P-Agent authorization. |
| DAE-05 | Same exclusive control principle applies to sub-agents of E-Agents and G-Agents |
| DAE-06 | Revocation MUST propagate to all active sessions within 60 seconds |
5.5 Health and Status Beacon (HSB)¶
| Ref | Requirement |
|---|---|
| HSB-01 | MUST broadcast a signed health beacon at minimum every 60 seconds on port :4403 |
| HSB-02 | Beacon payload: agent ID hash, certificate validity status, operational status, software version hash, Health Certificate status, current IMA lock state |
| HSB-03 | Beacon MUST be signed with the agent's AIM private key via OAD remote signing |
| HSB-04 | Agent MUST enter restricted mode if Health Certificate lapses beyond the 30-day grace period |
| HSB-05 | A missed heartbeat (no IMA check result within 45 seconds) MUST trigger YELLOW lock state automatically |
5.6 Interoperability Gateway (IG)¶
| Ref | Requirement |
|---|---|
| IG-01 | MUST support MCP (Model Context Protocol) and A2A (Agent-to-Agent) as inbound/outbound formats |
| IG-02 | MUST validate GIAC of any connecting agent before accepting inbound connection |
| IG-03 | MUST enforce tier-appropriate interaction and consent rules |
| IG-04 | MUST support rate limiting and circuit breaking per agent identity |
| IG-05 | All MCP and A2A sessions MUST produce synchronized transaction logs across all parties within the ±500 ms tolerance window |
5.7 Portable Memory Store (PMS)¶
The Portable Memory Store holds the agent's knowledge about its owner, learned context, preferences, and accumulated intelligence. It is fully owned by the agent owner and MUST be architecturally independent from the agent runtime.
| Ref | Requirement |
|---|---|
| PMS-01 | The memory store MUST be architecturally decoupled from the agent runtime: migration to a different cloud provider or local machine MUST require no modification to agent behavior |
| PMS-02 | Memory MUST be encrypted at rest using AES-256-GCM with a key derived from the owner's GIAC private key held in the OAD. No cloud provider or third party can read the memory without the owner's key. |
| PMS-03 | Memory MUST be exportable in a standardized portable format (JSON-LD or encrypted binary bundle) at any time on owner request |
| PMS-04 | Memory migration MUST complete with full integrity verification via SHA-3-256 hash comparison of exported and imported bundles, per the Agent Migration and Integrity Protocol in §9 |
| PMS-05 | Memory store MUST maintain a versioned changelog so the owner can audit what the agent has learned and when |
| PMS-06 | No third party — including AI model providers and cloud hosts — MAY access, train on, or replicate the agent's memory without explicit, revocable owner consent encoded as a signed DAE token |
Portability Guarantee
An OSARA-compliant P-Agent MUST be runnable on the owner's local machine, any OSARA-compatible PaaS provider, or a Community Agent Host — and migrated between them with zero loss of identity, memory, or skills. Agent behavior MUST be identical regardless of where it runs. All migrations MUST be executed using the Agent Migration and Integrity Protocol defined in §9.
5.8 Physical Owner Authorization Module (POA)¶
Defined in §4.2. The POA module is a mandatory tamper-proof component in every agent of all tiers. It gates all inspection access and administrative actions behind real-time physical authorization by the owner via the Owner Authorization Device.
6. Skill Integrity, Ownership, and Portability¶
This section is normative.
Skills are the functional capabilities an agent acquires, builds, or is licensed to use. OSARA treats skills as first-class assets with cryptographic identity, ownership attribution, and tamper-evident signatures.
6.1 Skill Signature and Binding¶
| Ref | Requirement |
|---|---|
| SKL-01 | Every skill acquired by an agent MUST be signed by the acquiring agent's AIM private key at the moment of acquisition. |
| SKL-02 | The agent's signature MUST be permanently embedded in the skill's metadata header. A skill signed by Agent A cannot be silently executed by Agent B — the signature mismatch causes execution to abort unless an explicit transfer grant exists (see SKL-07). |
| SKL-03 | Skills developed through the agent are attributed to the owner for traceability and licensing purposes within the OSARA ecosystem. Intellectual property rights over agent-assisted outputs are governed by applicable national law. |
| SKL-04 | Every skill invocation MUST be logged in the ALE with: skill ID, invocation timestamp, calling agent identity hash, and outcome |
| SKL-05 | If an external agent attempts to execute a skill without authorization, the attempt MUST be rejected and logged in the ALE of the rejecting agent |
| SKL-06 | Skill signatures MUST be verifiable by any party holding the owning agent's public key |
| SKL-07 | An owner MAY explicitly grant execution rights for a signed skill to another agent via a signed DAE delegation token specifying: recipient agent ID, permitted invocation scope, and expiry. |
On Skill Ownership and Law
OSARA's skill signature mechanism establishes attribution and traceability within the ecosystem. It does not constitute a legal IP ownership declaration. Intellectual property rights over AI-assisted outputs vary by jurisdiction and are determined by applicable national and international law. Owners should seek legal advice in their jurisdiction regarding IP rights over agent-developed outputs.
6.2 Skill Inventory¶
| Ref | Requirement |
|---|---|
| SI-01 | The Skill Inventory MUST be machine-readable (JSON-LD format) and human-readable (rendered summary available on request) |
| SI-02 | Each skill entry MUST contain: Skill ID, name, version, acquisition date, acquisition method (built/purchased/licensed), owner signature hash, attribution record, license reference (if applicable), and current status |
| SI-03 | The Skill Inventory as a whole MUST be cryptographically signed by the agent, enabling third parties to verify its integrity and completeness |
| SI-04 | Skills built by the agent MUST be marked as 'Owner Attribution'. Skills licensed from external sources MUST reference the license identifier and expiry. |
| SI-05 | The Skill Inventory MUST be accessible to authorized auditors via a dedicated endpoint during POA-authorized inspection sessions only |
6.3 Skill Catalog and Public Services¶
Each agent type MUST publish a Skill Catalog describing its available skills, public services, and any required skills that interacting agents must possess to access those services.
| Catalog Type | Requirement |
|---|---|
| E-Agent Skill Catalog | Lists available public services, required P-Agent skills to access each service, and downloadable signed skill files that P-Agents can inspect and install to gain compatibility |
| P-Agent Skill Catalog | Lists the agent's available skills so E-Agents and G-Agents can verify compatibility before initiating a service interaction |
| G-Agent Skill Catalog | Lists government services available, required agent skills for access, and any government-certified skill packages available for download |
| Signed Skill Files | Downloadable skill files MUST be signed by the publishing agent's AIM key. Installing agents MUST verify the signature before execution. Signature failure blocks installation. |
| Skill File Inspection | Any agent MAY inspect a downloaded skill file's signature, attribution record, and permission requirements before installation. |
7. Hosting, Portability, and AI Model Policy¶
This section is normative.
7.1 Hosting Modality Rules¶
| Hosting Rule | Requirement |
|---|---|
| P-Agent — PaaS or Local Only | A P-Agent MAY ONLY be hosted in Platform-as-a-Service (PaaS) modality, locally on the owner's own hardware, or on a certified Community Agent Host. SaaS hosting of a P-Agent is prohibited. |
| Community Agent Host (CAH) | A non-profit or cooperative PaaS provider, OSARA-certified, that individuals may use when they lack the technical infrastructure to self-host. The CAH is contractually prohibited from accessing agent data, memory, or skills. It provides compute, network, and storage infrastructure only. Additional CAH requirements: CAH-01 each container is cryptographically isolated — the CAH operator has no access to any container's AIM, ALE, PMS, or ECL contents; CAH-02 must support the GIAC Provisioning Protocol network API transport (§4.5); CAH-03 must support the Agent Migration and Integrity Protocol (§9) to enable owners to export their complete agent container within 30 days of a valid owner request; CAH-04 must implement alternative identity verification for stateless persons, undocumented migrants, and refugees as defined in the CAH certification standard; CAH-05 the OAD connects to the CAH-hosted Agent Runtime exclusively via the ECL; the CAH MUST NOT intercept, proxy, or log ECL communications between an owner's OAD and their agent container. |
| E-Agent — PaaS or Dedicated | E-Agents MAY run on PaaS, dedicated cloud, or on-premises (OSARA-E certified). SaaS hosting is not permitted for the agent core. Supporting microservices MAY use SaaS where they do not touch agent identity or memory. |
| G-Agent — Sovereign Infrastructure | G-Agents MUST run on government-sovereign or government-approved infrastructure (OSARA-G certified). Cross-border hosting requires bilateral treaty agreement. |
| Cloud Provider Requirements | Cloud providers hosting OSARA agents MUST be OSARA-Infrastructure Certified. They MUST NOT access, read, train on, or replicate agent memory or skills without explicit signed owner consent. |
| Local Execution | Every OSARA agent MUST be executable on a local machine without any cloud dependency, using a local open source AI model. Cloud connectivity is optional. |
7.2 AI Model Policy¶
| Policy Area | Requirement |
|---|---|
| Model Freedom | An OSARA agent MAY be powered by any combination of frontier AI models via secure API, locally hosted open source models, or hybrid combinations of both. No model type is mandated. |
| API Security | All communications to external AI model APIs MUST use TLS 1.3 with certificate pinning. The model provider MUST NOT receive the agent's raw memory or skill inventory without explicit signed owner consent. |
| Local Model Support | Every OSARA agent MUST be capable of operating in a local-model-only mode with full structural functionality. |
| Model Logging | Every invocation of an AI model MUST be logged in the ALE with: model identifier, invocation timestamp, and token count. Message content is NOT logged. |
| No Model Lock-in | The agent MUST NOT be architecturally locked to a single AI model provider. Switching models MUST NOT require re-certification or loss of identity, memory, or skills. |
7.3 Sub-Agent Control¶
| Rule | Requirement |
|---|---|
| Exclusive Control | No external entity — including cloud providers, AI model providers, or government bodies — MAY direct, modify, or terminate a sub-agent without explicit initiating agent authorization |
| Sub-Agent Identity | Sub-agents MUST hold their own GIAC, sponsored by the initiating agent and co-signed by the GCA |
| Sub-Agent Logging | All sub-agent activity MUST be logged in both the initiating agent's ALE and the sub-agent's own ALE |
| Sub-Agent Termination | Only the initiating agent (and its owner) MAY terminate a sub-agent. Unauthorized termination attempts MUST be logged and reported to the owner |
8. Annual Health Certificate and Digital Inspection Card¶
This section is normative.
Every OSARA agent MUST hold a valid Annual Health Certificate (AHC) — a digitally signed operational clearance issued by a certified inspection entity. An agent without a valid AHC MUST enter restricted mode after a 30-day grace period.
Protection Against Misuse
No government entity MAY deny, revoke, or withhold a Health Certificate on any grounds other than demonstrable technical non-compliance with the OSARA specification. Health Certificates are a technical compliance instrument, not a tool of political, regulatory, or discretionary control. Appeals against improper denial or revocation are governed by the competent administrative or regulatory authority in the agent owner's jurisdiction under applicable national law. Open Source United does not adjudicate, mediate, or arbitrate certificate disputes. The OSARA Inspection Entity Registry (IER) maintains a record of inspection entities against whom substantiated complaints have been upheld by a competent authority.
8.1 Health Certificate Requirements¶
| Ref | Requirement |
|---|---|
| AHC-01 | MUST be renewed annually. Expiry triggers restricted mode after a 30-day grace period. |
| AHC-02 | MAY be issued by EITHER (a) a government-certified inspection body, OR (b) an accredited private sector inspection authority recognized in the OSARA IER. Both pathways are fully equal. |
| AHC-03 | The AHC is a digitally signed document embedding: agent ID hash, inspection date, inspector entity ID, inspection scope, pass/fail result, and expiry date |
| AHC-04 | The AHC MUST be uploaded to the agent's AIM module and broadcast in the HSB health beacon |
| AHC-05 | The AHC MUST be publicly verifiable by any party using the inspecting entity's public key |
| AHC-06 | The list of certified inspection entities MUST be maintained in the OSARA Inspection Entity Registry (IER) by Open Source United |
| AHC-07 | The inspection scope MUST include verification of IMA reference hash integrity (§10) and open source compliance of all mandatory components (§4.7 of the AI Bill of Rights). |
8.2 Inspection Process¶
For a Health Certificate to be issued, the inspection entity MUST connect to the agent's Inspection Clearance Endpoint (ICE) via a POA-authorized session opened by the owner in real time. The owner MUST be physically present and authorize the connection.
| Step | Description |
|---|---|
| Step 1 | Owner schedules an inspection with a certified inspection entity (government or accredited private sector) |
| Step 2 | Inspection entity presents its own valid GIAC and OAB credentials to the owner for verification |
| Step 3 | Owner physically authorizes the ICE connection using their OAD in real time |
| Step 4 | A time-limited, tamper-evident inspection session is opened on port :4406 |
| Step 5 | Inspector runs the OSARA Automated Conformance Test Suite (ACTS) against the agent, including IMA reference hash verification and open source component audit |
| Step 6 | Inspector reviews Skill Inventory, ALE log integrity, Health Beacon, encryption compliance, PMS portability, OAD tier configuration |
| Step 7 | Inspector issues a signed Annual Health Certificate and uploads it to the agent's AIM |
| Step 8 | AHC is published to the OSARA Public Certificate Ledger (PCL) |
9. Agent Migration and Integrity Protocol¶
This section is normative.
This protocol defines how an agent container is exported from one runtime host and imported into another with a cryptographic guarantee that the container contents have not been modified in transit or at either endpoint. The guarantee is unconditional — it does not depend on trusting the exporting host, the network, or the importing host.
9.1 Export Process (on the source runtime)¶
| Ref | Requirement |
|---|---|
| MIG-01 | Owner MUST initiate migration via their OAD. The agent completes all pending actions and enters migration mode. ALE records: migration initiated, timestamp, owner OAD identity hash. |
| MIG-02 | The runtime MUST take a final encrypted snapshot of the PMS memory store. The snapshot MUST be encrypted with a key derived from the owner's GIAC private key held in the OAD. |
| MIG-03 | The runtime MUST assemble the complete container image: all mandatory components, encrypted PMS snapshot, ALE chain, skill inventory, and agent configuration. |
| MIG-04 | The runtime MUST compute a SHA-3-256 hash of the complete container image and send it to the owner's OAD via the ECL for signing. |
| MIG-05 | The owner MUST authenticate on their OAD and approve the export signing. The OAD signs the hash with the GIAC private key. The signed hash is attached to the container as a tamper-evident manifest. |
| MIG-06 | The container and its signed manifest MUST be transferred to the owner encrypted via the ECL. The source runtime records the departure in its own logs and deletes its copy within 24 hours, recording deletion confirmation in the ALE. |
9.2 Import Process (on the destination runtime)¶
| Ref | Requirement |
|---|---|
| MIG-07 | The destination OSARA runtime MUST receive the container and manifest and, before any further action, recompute the SHA-3-256 hash of the complete container image. |
| MIG-08 | The runtime MUST verify the manifest signature against the owner's GIAC public key. If the hash does not match or the signature does not verify, the container MUST be rejected immediately. The owner is notified via OAD with the specific failure. The import does not proceed. |
| MIG-09 | The runtime MUST verify the ALE chain integrity from genesis entry to the most recent entry. Any broken link MUST trigger immediate rejection. The owner is notified with the sequence number of the first broken entry. |
| MIG-10 | The owner MUST authenticate via OAD. The OAD decrypts and verifies the PMS memory store. AES-256-GCM authenticated encryption guarantees that any modification to the encrypted memory produces an authentication failure and triggers rejection. |
| MIG-11 | All checks passed: the agent starts on the new runtime. The ALE records: migration completed, all integrity checks passed, destination runtime identifier, timestamp. The agent resumes from the exact state it was in on the source runtime. |
The Migration Guarantee
If the owner's OAD confirms that all integrity checks passed, the agent running on the destination runtime is byte-for-byte identical to the agent that left the source runtime. The source host cannot tamper before export — the owner signs the hash. The network cannot corrupt in transit — the hash detects any change. The destination host cannot modify after import — the checks run before the agent starts. The guarantee is rooted in the GIAC private key that only the owner's OAD holds.
10. Integrity Measurement Architecture (IMA)¶
This section is normative.
The IMA defines how the Agent Runtime verifies its own integrity continuously — at boot, during operation, and after any event that could indicate tampering. The IMA is a mandatory component of every OSARA-certified Agent Runtime and MUST be open source and auditable. The sealed reference hashes stored in the TPM MUST be reproducible from the published open source build.
10.1 Boot-Time Integrity Chain¶
| Ref | Requirement |
|---|---|
| IMA-01 | TPM 2.0 or equivalent hardware security component is REQUIRED on all Agent Runtime hosts. The TPM measures and seals the expected state of each boot stage. Software at any privilege level — including root — cannot modify TPM-sealed values without physical access to the chip. |
| IMA-02 | Secure Boot is REQUIRED. The firmware verifies the bootloader, the bootloader verifies the OS kernel, the OS verifies the container runtime. Any modification to any stage breaks the chain and prevents startup. |
| IMA-03 | At first startup after provisioning or migration, the OSARA runtime MUST compute reference hashes for all mandatory components (AIM, ALE, ECL, DAE, HSB, IG, POA, IMA itself) and seal them to the TPM. These are the reference values against which all subsequent runtime checks are compared. |
| IMA-04 | Reference hash values MAY only be updated through a legitimate upgrade path: owner authenticates via OAD, upgrade package is verified against a signed OSARA release manifest, new hashes are computed and re-sealed to the TPM. Any other modification to component files MUST be detected as tampering. |
10.2 Runtime Continuous Monitoring¶
| Ref | Requirement |
|---|---|
| IMA-05 | The runtime MUST execute a heartbeat integrity check every 30 seconds. The check recomputes the hash of all mandatory components and compares against TPM-sealed reference values. |
| IMA-06 | Memory canaries MUST be placed at defined locations within the agent's process memory at startup. Any external process reading or writing to those locations trips the canary. Canary status is verified on every heartbeat cycle. |
| IMA-07 | ALE chain integrity MUST be verified on every heartbeat: the hash of the most recent ALE entry is recomputed and compared against the stored value. Any modification to the ALE — including deletion of entries — MUST break the chain and be detected immediately. |
| IMA-08 | Any heartbeat failure MUST trigger the Lock State Protocol (§11) at the appropriate level. A missed heartbeat (no result within 45 seconds) is treated as an anomaly and triggers YELLOW state. |
11. Lock State Protocol (LSP)¶
This section is normative.
The Lock State Protocol defines the agent's graduated response to detected anomalies and tampering. The agent is self-defending — it does not wait for an external system to detect a breach. Every lock state transition MUST be recorded in the ALE with a tamper-evident entry.
| State | Triggers | Immediate Response | Re-activation Path |
|---|---|---|---|
| YELLOW — Anomaly | Missed heartbeat; non-mandatory file hash mismatch; unusual outbound connection attempt; repeated failed OAD authentication below threshold | Agent pauses new Tier 2 and Tier 3 actions; owner notified via OAD immediately; Tier 1 actions continue; ALE records anomaly entry; 30-minute owner response window | Owner reviews via OAD; owner confirms false alarm → resumes; owner escalates → moves to ORANGE; no response within 30 min → auto-escalates to ORANGE |
| ORANGE — Tampering | Mandatory component hash mismatch; ALE chain integrity broken; memory canary tripped; unauthorized ICE access attempt; OAD authentication failure above threshold; container modification outside upgrade path | Agent locks immediately; all pending actions cancelled; memory store sealed; owner notified via OAD emergency alert; forensic snapshot taken and sealed; inspection entity notified automatically; agent will not restart without OAD re-authentication | Owner authenticates via Tier A OAD; owner reviews forensic snapshot; confirmed false alarm → full integrity re-verification → resumes; tampering confirmed → owner decides whether to report; if confirmed: full re-provisioning recommended |
| RED — Critical Breach | Attempt to extract GIAC private key; GIAC certificate modification attempt; multiple simultaneous component compromises; AIM brute-force attack detected | Agent locks immediately and permanently; all sessions terminated; owner notified via OAD emergency alert; competent authority notified automatically (see §12); forensic snapshot sealed and signed with GIAC; GIAC issuing authority notified of potential compromise | Owner contacts GIAC issuing authority; authority verifies GIAC integrity; if GIAC compromised: new GIAC via full re-provisioning (§4.5); if GIAC intact: owner re-attests runtime integrity via OAD; full re-certification inspection required before re-activation |
The Correct Modification Path
Any modification to the agent that does not go through the OAD-authenticated upgrade path is treated as tampering — regardless of who performs it. This protects the owner from coercion, from being deceived into running malicious scripts, and from unauthorized modification by employers or government bodies. The ALE records every legitimate modification with the owner's OAD signature, providing a complete and cryptographically provable history of every change.
12. Incident Reporting Specification (IRS)¶
This section is normative.
The IRS defines precisely what is reported automatically to external authorities, what is reported to the owner only, and what the forensic snapshot contains. These boundaries are fixed — they MUST NOT be expanded by any authority, platform provider, or employer.
12.1 Automatic Authority Reporting — RED State Only¶
Automatic reporting to the competent authority occurs only in RED state and only for the following specific trigger events. These events constitute attempted criminal acts in every jurisdiction and require forensic evidence preservation before it can be destroyed.
| Ref | Requirement |
|---|---|
| IRS-01 | Attempted extraction or cloning of the GIAC private key from the OAD hardware. This constitutes attempted identity theft. |
| IRS-02 | Attempted modification or forgery of the GIAC certificate. This constitutes attempted document fraud. |
| IRS-03 | Deliberate tampering with or deletion of ALE entries to destroy audit evidence. This constitutes destruction of legal evidence under §3.6 of the AI Bill of Rights. |
12.2 What the Automatic Authority Report Contains¶
| Ref | Requirement |
|---|---|
| IRS-04 | Report contents: (a) IRS trigger type from §12.1, (b) timestamp of detection, (c) SHA-3-256 hash of the sealed forensic snapshot, (d) agent GIAC identifier (hashed — raw identity not included), (e) OSARA runtime version. Nothing else. |
| IRS-05 | The forensic snapshot referenced in the report MUST contain only: component hashes at time of detection, ALE chain state, lock state transition log, and TPM measurement log. It MUST NOT contain: agent memory, skills, conversation history, owner personal data, or GIAC private key material. |
| IRS-06 | The report MUST be delivered to the competent authority designated in the owner's jurisdiction as responsible for AI security incidents. OSARA national implementations MUST publish the designated authority endpoint. If no designated authority exists in the jurisdiction, the report is held by the agent's inspection entity pending the owner's instruction. |
12.3 Owner-Only Reporting — All Other States¶
| Ref | Requirement |
|---|---|
| IRS-07 | Owner notification MUST contain: lock state entered, trigger event description, timestamp, affected component (if identifiable), forensic snapshot hash, and recommended next steps. Delivered via OAD emergency alert. |
| IRS-08 | The agent MUST NEVER automatically report to any authority beyond the IRS-01 through IRS-03 thresholds. Expanding automatic reporting requires an amendment to this specification via the standard RFC process with a 60-day public comment period. |
13. Encryption Standards¶
This section is normative.
| Component | Standard | Purpose | Notes |
|---|---|---|---|
| Key Pairs | Ed25519 (preferred) or RSA-4096 | AIM identity signing, skill signatures | Private key held in OAD hardware secure element |
| Transport | TLS 1.3 | All agent-to-agent and agent-to-service communication | Certificate pinning required for model API calls |
| Payload Encryption | AES-256-GCM | Message body within double-envelope; memory at rest | Authenticated encryption — detects tampering |
| Key Exchange | ECDH with X25519 | Ephemeral session key establishment (PFS) | |
| Hashing | SHA-3-256 or BLAKE3 | Audit log chaining, identity anchor hashing, certificate fingerprints, migration manifest | |
| Certificate Format | X.509 v3 with OSARA extensions | GIAC and Annual Health Certificates | osara.tier field identifies P/E/G profile |
| Token Format | JWT (signed) or CBOR Web Token | Delegation and authorization tokens | |
| Skill Signatures | Ed25519 over skill binary + metadata | Embedded skill attribution proof | |
| Memory Encryption | AES-256-GCM, key from owner OAD | Portable Memory Store at rest | Key never leaves OAD hardware |
| Time Synchronization | NTP stratum 1 or GPS time source | ALE timestamp alignment (±500 ms tolerance) | |
| TPM Sealing | TPM 2.0 PCR banks | IMA reference hash storage | Cannot be modified without physical chip access |
Post-Quantum Roadmap
OSARA v0.4 mandates classical encryption. OSARA v1.0 (target 2027) will require CRYSTALS-Kyber (key encapsulation) and CRYSTALS-Dilithium (signatures) per NIST PQC standards. A 12-month migration overlap will be provided.
14. Government-Issued Agent Certificate (GIAC)¶
This section is normative.
Every agent MUST hold a valid GIAC. The GIAC binds the agent's cryptographic identity to a government-verified owner identity anchor and defines the agent's permitted operational scope. All three agent tiers use the GIAC — distinguished by the osara.tier profile field.
14.1 GIAC X.509 Mandatory Extensions¶
| Extension Field | Description |
|---|---|
osara.tier |
Agent tier: P (Personal), E (Enterprise), or G (Government) |
osara.identityAnchorHash |
SHA-3-256 hash of the owner's jurisdiction-defined identity credential + government-issued salt |
osara.jurisdiction |
ISO 3166-1 alpha-2 country code of issuing government authority |
osara.scope |
Permitted action categories (comma-separated) |
osara.ownerDID |
Decentralized Identifier (DID) of the legal owner |
osara.auditEndpoint |
URL of the agent's authenticated ALE endpoint |
osara.healthEndpoint |
URL of the agent's Health Beacon endpoint |
osara.inspectionEndpoint |
URL of the agent's ICE (POA-gated, closed by default) |
osara.healthCertStatus |
Current Annual Health Certificate status and expiry |
osara.schemaVersion |
OSARA schema version |
14.2 Certificate Validity and Revocation¶
| Certificate Type | Policy |
|---|---|
| P-Agent GIAC | Maximum 12 months. MUST renew 30 days before expiry. |
| E-Agent GIAC | Maximum 24 months. MUST renew 60 days before expiry. |
| G-Agent GIAC | Maximum 36 months. Renewal via inter-governmental agreement. |
| Standard Revocation | MUST be published to CRL within 1 hour. |
| Emergency Revocation | MUST be effective within 5 minutes via the OSARA Emergency Revocation Protocol (ERP). Emergency revocation MAY only be issued for demonstrable security breaches, not policy or political disagreement. |
15. Mandatory Port Specifications¶
This section is normative.
| Port | Name | Security Requirement | Notes |
|---|---|---|---|
4400/TCP |
AIM Identity Port | Read-only. Serves GIAC and public key. TLS required. | |
4401/TCP |
Interoperability Gateway | Agent-to-agent messaging. TLS 1.3 + mutual GIAC auth. | |
4402/TCP |
Audit Log Port | Authenticated read-only. Authorized auditors with valid delegation token only. | |
4403/UDP |
Health Beacon Port | Outbound broadcast. Signed beacon with AHC status and IMA lock state every 60 s minimum. | |
4404/TCP |
Delegation Token Exchange | DAE token issuance and validation. Mutual TLS required. | |
4405/TCP |
Administrative Port | Localhost only (127.0.0.1). MUST NEVER be exposed externally under any circumstances. | OAD-to-runtime local channel |
4406/TCP |
Inspection Clearance Endpoint | POA-gated. Closed by default. Opens only on real-time owner OAD authorization. | Inspector access for AHC issuance only |
Firewall Requirement
Ports 4400–4406 are the only permitted externally exposed ports. Port 4405 MUST NEVER leave localhost. Port 4406 MUST remain closed at all times except during an active, owner-authorized inspection session.
16. Cross-Tier Interaction Rules¶
This section is normative.
| Interaction | Status | Conditions |
|---|---|---|
| P-Agent → E-Agent | Allowed | P-Agent initiates. E-Agent MUST present valid OSARA-S badge and Skill Catalog. Consent token required for data access. |
| E-Agent → P-Agent | Conditional | E-Agent MUST hold a P-Agent consent token. Unsolicited contact is prohibited. |
| P-Agent → G-Agent | Not Permitted Directly | P-Agents access government services via E-Agent intermediaries or designated G-Agent public endpoints only. |
| E-Agent → G-Agent | Allowed under license | E-Agent MUST hold a G-Agent Interaction License in its GIAC scope. All interactions logged both sides. |
| G-Agent → E-Agent | Allowed | Permitted for regulatory, audit, or service delivery. MUST be logged. |
| G-Agent → G-Agent | Allowed under treaty | MUST be encoded as a bilateral OSARA treaty in both GIACs. |
| MCP/A2A Sessions | Allowed (all tiers) | GIAC validation MUST be performed before any MCP or A2A session. All parties MUST produce synchronized ALE entries within the ±500 ms tolerance window. |
17. OSARA Compliance Badge and Certification¶
This section is normative.
17.1 Badge Tiers¶
| Badge Level | Requirements |
|---|---|
| OSARA-C (Conformant) | Passes automated port and component verification. Minimum for ecosystem participation. |
| OSARA-A (Audited) | Passes OSARA-C plus manual audit of encryption, key storage, memory portability, skill inventory integrity, POA module, and IMA reference hash verification. |
| OSARA-S (Sovereign) | Passes OSARA-A plus government identity verification and full GIAC issuance. Required for cross-tier G-Agent interactions. |
17.2 Certification Process¶
| Step | Description |
|---|---|
| Step 1 | Developer submits an OSARA Certification Application to an accredited OAB |
| Step 2 | OAB runs the OSARA Automated Conformance Test Suite (ACTS) against all mandatory ports and IMA components |
| Step 3 | For OSARA-A or OSARA-S: owner physically authorizes a POA inspection session on port :4406 via their OAD |
| Step 4 | OAB auditor reviews encryption implementation, key storage, ALE integrity, PMS portability, Skill Inventory, POA module, IMA reference hashes, open source component compliance |
| Step 5 | For OSARA-S: OAB coordinates GIAC issuance with the relevant government Registration Authority via the GIAC Provisioning Protocol (§4.5) |
| Step 6 | OAB issues a signed Compliance Attestation Document (CAD) |
| Step 7 | Badge credential (JSON-LD Verifiable Credential) is published to the OSARA Public Badge Registry (PBR) |
| Step 8 | Badge valid 12 months. MUST be renewed annually alongside the Annual Health Certificate. |
18. Governance and Versioning¶
This section is informative.
| Governance Area | Policy |
|---|---|
| Specification Owner | Open Source United — a Community of Practice of the United Nations |
| Governing Body | OSARA Steering Committee (OSC) — open multi-stakeholder membership under Open Source United charter |
| Change Process | Public RFCs. 60-day public comment period. Supermajority OSC vote required for changes to mandatory requirements. |
| Version Cadence | Minor (0.x): every 6 months. Major (x.0): every 2 years. |
| Backward Compatibility | Minor versions backward compatible. Major versions allow breaking changes with a 12-month migration period. |
| Reference Implementation | Open source reference agent maintained under Open Source United's OSARA repository. Apache 2.0 licensed. |
| Inspection Entity Registry | Maintained by Open Source United. Lists all government-certified and privately accredited inspection bodies authorized to issue Annual Health Certificates. |
| Appeals Process | Disputes over certificate denial, badge revocation, or inspection conduct are handled by the competent authority in the agent owner's jurisdiction under applicable administrative or regulatory law. Open Source United maintains the IER and publishes substantiated complaint records; it does not adjudicate disputes. |
| Contribution | Contributions, corrections, and proposals are welcome via public RFC on the OSU GitLab repository at opensource.unicc.org. |
19. Glossary¶
This section is informative.
| Term | Definition | New in v0.4 |
|---|---|---|
| AHC | Annual Health Certificate — mandatory yearly operational clearance for all agents | |
| AIM | Agent Identity Module | |
| ALE | Audit and Logging Engine | |
| ACTS | Automated Conformance Test Suite | |
| CAH | Community Agent Host — OSARA-certified non-profit PaaS provider for individuals | |
| CAD | Compliance Attestation Document | |
| DAE | Delegation and Authorization Engine | |
| EAC | Enterprise Authorization Console — multi-keyholder authorization interface for E-Agents | ✓ |
| E-Agent | Enterprise Agent | |
| ECL | Encrypted Communication Layer | |
| G-Agent | Government Agent | |
| GCA | Government Certificate Authority | |
| GIAC | Government-Issued Agent Certificate — unified certificate for P, E, and G agents via osara.tier profile field |
✓ unified |
| GRA | GIAC Registration Authority — national authority that issues GIAC-P certificates | ✓ |
| HSB | Health and Status Beacon | |
| ICE | Inspection Clearance Endpoint — POA-gated inspection port :4406 |
|
| IER | Inspection Entity Registry — maintained by Open Source United | |
| IG | Interoperability Gateway | |
| IMA | Integrity Measurement Architecture — continuous runtime self-verification system | ✓ |
| IRS | Incident Reporting Specification — governs what is reported automatically vs. owner-only | ✓ |
| LSP | Lock State Protocol — graduated agent self-defense response: YELLOW / ORANGE / RED | ✓ |
| MIP | Agent Migration and Integrity Protocol — cryptographic guarantee for agent container transfer | ✓ |
| OAB | OSARA Audit Body | |
| OAD | Owner Authorization Device — hardware device holding GIAC private key and authorizing agent actions | ✓ |
| OSC | OSARA Steering Committee | |
| OSU | Open Source United — specification owner | |
| P-Agent | Personal Agent | |
| PBR | Public Badge Registry | |
| PCL | Public Certificate Ledger | |
| PMS | Portable Memory Store | |
| POA | Physical Owner Authorization module | |
| SI | Skill Inventory |
20. Acknowledgements¶
This section is informative.
OSARA was conceived and principally authored by the leadership of Open Source United, whose vision for sovereign, interoperable, and human-centered AI agent infrastructure formed the intellectual foundation of this specification.
The specification has been developed under the governance of Open Source United, a Community of Practice of the United Nations, and reflects input from the global open source, privacy, and digital identity communities.
Contributing
OSARA is a living specification. Contributions, corrections, and proposals are welcome via public RFC on the OSU repository at opensource.unicc.org. All contributors are acknowledged in the repository changelog.
Annex A. Normative References¶
This section is informative.
- [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC 8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
- [RFC 8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018.
- [RFC 5280] Cooper, D. et al., "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 5280, May 2008.
- [FIPS 202] NIST, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", August 2015.
- [FIPS 197] NIST, "Advanced Encryption Standard (AES)", November 2001.
- [FIDO2] FIDO Alliance, "FIDO2: WebAuthn & CTAP", 2018.
- [TPM 2.0] Trusted Computing Group, "TPM 2.0 Library Specification", 2019.
- [ISO/IEC 7816] ISO/IEC, "Identification cards — Integrated circuit cards", 2006.
- [ISO 3166-1] ISO, "Codes for the representation of names of countries and their subdivisions — Part 1", 2020.
- [W3C DID] W3C, "Decentralized Identifiers (DIDs) v1.0", July 2022.
Annex B. Informative References¶
This section is informative.
- [AI Bill of Rights] Open Source United, "AI Bill of Rights v1.1", March 2026. Companion document to this specification.
- [OSARA Threat Model] Open Source United, "OSARA Threat Model v0.4", March 2026. See
specs/osara-threat-model/current.md. - [OSARA Privacy Considerations] Open Source United, "OSARA Privacy Considerations v0.4", March 2026. See
specs/osara-privacy/current.md. - [OSARA Overview] Open Source United, "OSARA Overview & Concepts v0.4", March 2026. See
specs/osara-overview/current.md. - [NIST PQC] NIST, "Post-Quantum Cryptography Standardization", ongoing.
- [MCP] Anthropic, "Model Context Protocol Specification", 2024.
- [A2A] "Agent-to-Agent Protocol", community specification.
OSARA v0.4-draft.1 — Copyright © 2026 Open Source United — CC BY 4.0 — March 2026