<-Workflow Description Go to ToC Security API ->
1 Reference Model
Figure 1 depicts the Reference Model of Zero Trust in MPAI-AIF.
Figure 1 – Reference Model of Zero Trust
An AIF Implementation operates under the assumption that its execution environment is Zero Trust: no component, network, device, service, AIM or communication path is inherently trustworthy. Every AIM and every component verifies, for each interaction, the identity, authorisation, integrity, freshness and confidentiality of the data it exchanges, according to the principles of continuous verification and assumed breach of the Zero Trust frameworks listed in References.
Within one operating-system process every component can read and write the memory of every other. An attacker who controls code in a process defeats any check the process makes on itself, and a check at every in-process Message adds cost and no protection. Trust in a process is therefore established once, before its code runs, by verifying what that code is, and is lost entirely if unverified code runs in it. The Trusted Zone is the set of processes whose code the Controller has verified; within it, the Controller enforces authorisation by construction. Everything that crosses the boundary of a verified process – to another process, to another machine, to the User Agent, to the MPAI Store, to another Controller – is verified at every interaction.
2 Requirements
2.1 Identity
- Each AIM participating in an AIM-to-AIM communication shall possess a verifiable identity.
- An AIM receiving data shall verify the identity of the AIM that generated the data before accepting it for processing.
- Identity verification shall not rely on network location, infrastructure placement, or any assumption of implicit trust.
2.2 Authentication
- Each AIM shall authenticate the identity of the AIM with which it communicates for every data exchange.
- Authentication shall occur on a per-interaction basis and shall not rely on prior authenticated sessions or persistent trust.
- Authentication mechanisms shall be independent of the trustworthiness of the communication environment (“never trust, always verify”).
2.3 Authorisation
- An AIM shall verify that another AIM is authorised to perform each specific action, including the transmission or reception of Data Exchange Metadata or data proper.
- Authorisation decisions shall be enforced at the time of each request and shall not rely on any assumption about the behaviour or location of an AIM in a previous session.
- No AIM shall access, transmit or process data unless explicitly authorised to do so.
2.4 Integrity
- Data transmitted between AIMs shall include verifiable means for the receiving AIM to determine whether the data has been modified in transit.
- A receiving AIM shall detect any alteration, accidental or malicious, of Data Exchange Metadata or data proper.
- Integrity verification shall be independent of the correctness or security of the communication network.
2.5 Confidentiality
- Data transmitted between AIMs shall be protected so that only the designated receiving AIM can access its content.
- No AIM, component or process other than the intended receiving AIM shall be capable of recovering or interpreting transmitted data.
- Confidentiality protection shall apply whether the AIF operates in a local, remote or distributed environment.
2.6 Freshness and replay protection
- An AIM shall provide the receiving AIM with sufficient information to determine that received data is new and not a replay of previously transmitted data.
- A receiving AIM shall reject data that cannot be verified as fresh.
- Freshness assurance shall not rely on the trustworthiness of any portion of the communication environment.
2.7 Continuous verification
- The security properties of AIM-to-AIM interaction – identity, authorisation, integrity, confidentiality, freshness – shall be verified continuously.
- Verification shall occur at every interaction, or at regular times where the interaction is a stream, independently of previous verifications and without assumption of persistent trust. There is no caching of trust and no session persistence.
2.8 Independence of environment
- An AIF Implementation shall not rely on the trustworthiness of the underlying operating system, hardware, communication paths or deployment infrastructure.
- No assumption shall be made that co-location, network topology or infrastructure proximity indicate trustworthiness. Even trusted hardware shall prove its trustworthiness; even local communication shall be authenticated.
- All security properties shall be enforced in environments recognised as potentially compromised.
2.9 Auditability
- An AIF Implementation shall generate auditable information allowing the verification of AIM-to-AIM interactions.
- Audit data shall be tamper-evident.
- AIMs shall not rely on external infrastructure for the correctness or completeness of audit information.
3 Parties and roles
Table 1 – Parties and roles
| Role | Party and function |
| Policy decision | The Controller. It alone decides which AIM may reach which Port, Storage key or payload, from the Metadata of the Module as approved by the MPAI Store. It issues a Grant for each Channel end: a credential that admits exactly that end, for that Module instance. |
| Policy enforcement | The transports and the Storage. Every read and write passes through a handle the Controller bound, and the transport or the Storage checks its Grant at every operation, not once at opening. |
| Identity | Every AIM Instance has an identity: Implementer ID, Implementation ID and the fingerprint of its Implementation. Every Controller and every AIM host is a Trust Anchor, its key held by its root of trust where it has one. Every Module instance has an identifier assigned by its Controller. |
| Trust | As MPAI-PTF specifies: every AIM Instance is a PTF Process Instance, with its Cryptographic Instance Identity, whose key is made where the AIM runs, an Instance Credential and a Process Lifecycle Credential that follows its state. The Controller issues them, and is the PTF Verifier: it runs the Verification Pipeline – identity, credential, life cycle, evidence of what the AIM runs, policy – before an AIM runs. Each decision is a PTF Trust Operation. |
4 How the requirements are met
Table 2 – How the requirements are met
| Requirement | Within a verified process | Between processes of one machine | Between machines, Controllers, User Agent and Controller |
| Identity | AIM Instance identity bound to its handles at instantiation; its identity and credentials (MPAI-PTF) | Grant presented by each end | Each Controller or AIM host a Trust Anchor, proven by the Trust Protocol of MPAI-PTF; Grant per Channel end |
| Authentication | By construction: only the handle bound to that AIM can act | Grant checked at every operation | Mutual TLS, and a message authentication code keyed per Channel on every Message |
| Authorisation | Handles exist only for Channels the Topology declares | As within a process | As within a process; the far end honours only the Channel of the Grant |
| Integrity | Messages are immutable once written | Authenticated local channel | TLS and per-Message code |
| Confidentiality | Process isolation | Local channel and shared memory accessible only to the two ends | TLS; payloads inlined, never referenced across machines |
| Freshness | Controller’s stamp on every Message | Stamp and per-Channel sequence number; a reader rejects a sequence it has seen | As between processes; MaxAge bounds replay |
| Continuous verification | Grants revocable; the handles of a stopped Module are dead | Grant rechecked at every operation | Grants short-lived and renewed; a Controller that leaves range invalidates its identifiers |
| Independence of environment | Code verified against the MPAI Store before it runs | No reliance on the machine being private | No exception for a loopback, a private network or a tunnel |
| Auditability | The Controller records Channel creation, Grants, life cycle, Storage writes and every trust decision in the Trace, signed and hash-chained so that a gap or an alteration is evident | As within a process | Each Controller keeps its own chain; External Messages carry the stamp of their writer |
5 Verification of code
A Controller shall run only code it has verified: an Implementation whose fingerprint the MPAI Store confirms for its AIM Instance Metadata, loaded so that it cannot replace the framework types the Controller relies on. A model obtained from a third party is checked against the hash its settings state before use, and so is a file already present. The Controller – or the AIM host of a remote AIM – measures the binary and the models before the AIM is built, and refuses the Module with MPAI_AIF_NOT_TRUSTED where they are not what the MPAI Store approved or the settings declare. An AIM host proves, when it connects, which Implementation it runs.
6 Profiles
MPAI-AIF specifies two Profiles, declared in the AIF Metadata and in the APIProfile of AIM Metadata.
6.1 Basic Profile
The Basic Profile meets the requirements of 2 as specified in 3 to 5, using the secure transports of the platform – TLS, authenticated local channels, operating-system process isolation – and the fingerprints of the MPAI Store. It uses the Basic API.
6.2 Secure Profile
The Secure Profile adds roots of trust in hardware, so that verification extends to the Controller itself: attestation of the Controller and of AIM hosts by Entity Attestation Tokens, Secure Storage for keys and Grants, and the cryptographic functions of the Security API. Identity keys are held in the root of trust; the code of each party and each Implementation is measured into it; quotes over a Verifier’s nonce are the PTF Attestation Evidence; secrets are sealed to the measurements. In addition:
- The Controller is split in two parts. The Secure Controller accesses Secure Communication and Secure Storage, and interfaces with the Module in the area where secure code is executed. The Non-Secure Controller accesses the non-secure parts of the AIF and interfaces with the User Agent.
- The Controller communicates securely – authentication, attestation, encryption – with the MPAI Store and the User Agent, and accesses Communication, Shared Storage, Access and the MPAI Store through the Trusted Services.
- The Implementer of an AIM guarantees its security by calling the Security API.
- The AIMs of a Composite AIM run on the same computing platform.
