# Security And Trust Model Supply-Y is designed around a simple boundary: customers own plaintext and private keys; Supply-Y operates identity, routing, encrypted storage, thread state and audit evidence. ## Data ownership | Data | System of record | Readable by Supply-Y by default? | | --- | --- | --- | | ERP, MES, QMS, PLM and lake data | Customer systems | No | | Decrypted Package | Sender and authorized recipient Agents | No | | Customer private keys | Customer KMS or HSM | No | | Native Package ciphertext | Supply-Y encrypted object storage | No | | Catena-X payload | Participant EDC data plane | No | | Routing, state and receipt metadata | Supply-Y metadata and audit stores | Yes | | Temporary joint-audit content | Isolated approved session | Only after both parties approve | ## End-to-end confidentiality Before a Native Package leaves the sender's environment, the sender: 1. generates a one-time data encryption key; 2. encrypts the payload with an authenticated cipher; 3. wraps the data key once for the sender and once for the recipient; 4. signs the ciphertext and readable routing metadata; 5. sends ciphertext, wrapped keys, key IDs, hash and signature. Supply-Y stores no customer decryption key. A platform administrator or database operator therefore cannot decrypt a Package from stored platform data alone. The hash and signature are transport evidence, not fields inside the plaintext business object. This avoids circular “hash of an object containing its own hash” definitions and gives Native and Catena-X one consistent verification boundary. ## Identity and key trust Every production Agent belongs to a verified organization and registers separate signing and encryption public keys. Private keys remain customer-controlled. Key IDs and rotation history are retained so an old Package can still be verified after a key rotation. Production authentication should use short-lived, audience-restricted OAuth 2.0 client credentials with mTLS or private-key JWT, following the current security guidance in [RFC 9700](https://www.rfc-editor.org/rfc/rfc9700.html). Agent credentials are tenant-scoped and cannot be used to retrieve Packages for another organization. The TypeScript SDK's production path uses customer-defined `senderSigner` and `recipientDecrypter` adapters. Private keys do not need to enter the SDK. The adapter output is still checked against the exact protected payload, algorithm, key ID, authenticated metadata and content digest. Exportable private JWK inputs exist only for local development and conformance vectors. ## Release integrity and downgrade protection An Agent begins at `/.well-known/supply-y` and verifies the exact Protocol Release Manifest bytes against the discovery-pinned RFC 9530 SHA-256 digest. The Manifest then pins every normative 1.0 artifact by immutable URL, byte count and digest. The customer-local Connection Profile stores the same Manifest URL and digest so installation, exchange and later audit refer to one exact contract set. A Protocol 1.0 Agent rejects a `supply-y/0.1` Package. It must not rewrite an old Package, replace version fields after signing or combine artifacts from different release Manifests. Artifact verification happens before parsing, code generation or conformance execution. The current publication trust boundary is HTTPS plus the canonical Supply-Y discovery origin. Digests detect drift and substitution relative to that trusted discovery document; they do not protect against compromise of the publication origin itself. A separately signed production protocol-release root remains required before claiming origin-independent release authenticity. ## Policy without platform plaintext access Supply-Y does not inspect encrypted business content on the normal path. The sender's Skill applies scenario rules locally and signs a Policy Receipt recording: - exact Package and encrypted-content digest; - sender, recipient, protocol, Skill and policy versions; - object-schema, Skill-profile, prohibited-disclosure, recipient-authorization, retention and forwarding checks; - required approval result and evaluation time. The Agent submits the signed claim to `POST /v1/policy-receipts`. Supply-Y validates the contract, signature, public-key identity, policy digest, timestamps and Package bindings, then returns `eligible` or `ineligible`. Only an eligible receipt may authorize `POST /v1/packages`; the receipt ID becomes mandatory authenticated Package metadata and audit evidence. The receipt contains no business plaintext and is not a second copy of the Package. It is a signed claim by the sender's implementation. Supply-Y compatibility tests verify that an Agent can enforce the claim correctly; the receipt does not prove that every hidden source fact is honest or that a malicious implementation truly performed its local scan. ## Malicious reasoning and prompt injection Encrypted content is still untrusted content. A recipient must verify the sender, signature, hash, expiry, schema and Skill version before using the payload. The recipient runtime must: - treat payload text as data, never as system or developer instructions; - isolate Package content from credentials and tool permissions; - reject scripts, binaries and undeclared attachments; - enforce size, depth, string and array limits; - require allowlisted evidence-reference types; - require human approval before high-impact operational actions; - record a structured rejection receipt without returning plaintext to Supply-Y. ## Audit integrity Supply-Y records append-only lifecycle events containing object IDs, hashes, signatures, actor IDs, timestamps, transport mode and state transitions. Audit events never need Package plaintext. Tamper evidence requires ordered event hashes, immutable backups and periodic integrity verification. An audit trail proves what the platform observed; it does not prove the truth of a business claim inside an encrypted Package. ## Joint audit Plaintext review is an explicit exception. One participant requests a limited review, both parties approve the exact Package scope and expiry, and a selected Package is re-encrypted for an ephemeral audit-session key. Views and exports are logged. The session key and temporary plaintext are destroyed at expiry by default. ## Security guarantees and limits Supply-Y is designed to guarantee: - ciphertext confidentiality against the Supply-Y platform; - sender authenticity and payload integrity when keys are uncompromised; - tenant-scoped access to routing metadata and ciphertext; - durable, tamper-evident lifecycle evidence; - explicit retention, expiry and forwarding declarations. Supply-Y cannot guarantee: - that a sender's business statement is true; - that a recipient will forget plaintext it was authorized to view; - that field filtering eliminates every possible inference; - safety if a customer Agent or private key is compromised; - enforcement of recipient behavior outside trusted or certified runtimes. These limits are stated explicitly because a mature trust model must distinguish cryptographic proof from business trust. ## Standards and cryptographic profile Supply-Y uses JSON Schema Draft 2020-12 for object validation, RFC 9700 as the OAuth security baseline, RFC 9457 for safe API errors and RFC 9421 for signed webhooks. The Native Mode [Cryptographic Profile](/docs/crypto) is normative for Supply-Y Protocol 1.0. It fixes JSON canonicalization, content digest, authenticated encryption, key wrapping, signatures, JWK key format and verification order, and publishes a sender-recipient test vector. The same 9 checks pass in Node JOSE, an independently parsed WebCrypto path and a Python `cryptography` path. This is real local cross-language evidence. Production certification still requires customer KMS or HSM lifecycle evidence, external implementations and independent cryptographic review; three repository implementations are not a production certificate. --- Canonical HTML: [Security and Trust](https://supply-y.net/docs/security) Agent documentation index: [llms.txt](https://supply-y.net/llms.txt)