Skip to content
OWP

14. Security Considerations

This section describes the principal security considerations of the protocol. Implementers MUST address all considerations herein and SHOULD additionally address the considerations of the underlying transport, storage, and key-management systems.

14.1 Threat Model

The protocol is designed under the following threat assumptions:

  • The runtime is trusted. The runtime is the enforcement boundary for the Charter. A compromised runtime can falsify any Audit Envelope and authorise any action. Operating organisations MUST protect runtime integrity through standard infrastructure controls; this is out of scope for the protocol.
  • Workers are not trusted. A Worker’s Driver may misbehave (whether through model error, prompt injection, code defect, or malice). The runtime MUST enforce the Charter against the Worker; the Worker’s signature on outbox actions provides attribution but does not provide trust.
  • Capability Providers are partially trusted. Providers are authenticated at registration but are otherwise treated as third parties. Provider responses MUST be validated against the Capability’s response schema; invalid responses MUST be refused and recorded.
  • Network adversaries exist. All inter-component traffic MUST be authenticated, integrity-protected, and confidential. Specific cryptographic mechanisms are wire-binding concerns (§17).
  • Reviewers are trusted but verifiable. Reviewer decisions are recorded with the Reviewer’s signature. Compromise of a Reviewer identity is a serious incident; key rotation procedures (§14.3) MUST be exercised promptly.

14.2 Cryptographic Algorithms

Implementations MUST use signature algorithms providing at least 128-bit security. RECOMMENDED algorithms include Ed25519, ECDSA over P-256, and RSA-PSS with 3072-bit keys. Hash algorithms MUST provide at least 256-bit collision resistance (SHA-256, SHA-3-256, BLAKE3 are RECOMMENDED).

Algorithm agility is REQUIRED: the algorithm used for any signature or hash MUST be encoded in the signed/hashed object such that future algorithm transitions do not invalidate prior records.

14.3 Key Management

Worker keys, Human Role keys, runtime keys, and Provider keys MUST be rotated on a defined schedule. Key rotation MUST NOT invalidate prior signatures: a signature is verified against the public key bound to the signing identity at the time of signing, regardless of the identity’s current key.

A key registry maintained by the runtime MUST persist all keys ever bound to identities, with timestamps. The registry is authoritative; verifying a historical signature requires consulting the registry to determine the public key in effect at the signing time.

14.4 Replay and Idempotency

Workers MUST be tolerant of duplicate Signal delivery (§6.1). Capability invocations MUST be idempotent at the protocol level: invoking the same Capability with the same parameters within the same Intent MUST be safe. Where the underlying Capability is not naturally idempotent (e.g. sending an external email), the Provider MUST implement de-duplication using the runtime’s invocation ID.

14.5 Authority Forging

The risk that a Worker’s Driver attempts to claim an authority it does not have is mitigated by runtime evaluation of every action. The runtime, not the Worker, decides whether an action is authorised. Worker signatures attest to “the Worker requested this action” and not to “the Worker is authorised to do this.” Authorisation is the runtime’s decision and is recorded as such.

14.6 Escalation Flooding

A misbehaving Worker may attempt to flood Human Roles with Escalations. The runtime MUST enforce per-Worker and per-Human-Role rate limits on Escalations and SHOULD provide Reviewers with visibility into Escalation patterns. Rate limits are configurable per deployment and MAY be tightened by Compliance Profiles.

14.7 Confidentiality of Audit Envelopes

Audit Envelopes contain detailed records of organisational work, including potentially sensitive payloads. Implementations MUST encrypt Envelopes at rest and in transit between runtime components. Access to Envelopes MUST be governed by the same authority model as the underlying work: Workers see the Envelopes of their own Intents; Reviewers see the Envelopes of Functions they audit; Architects see Envelopes during authoring of new Function versions.