[RFC] Add R10 (SHOULD): Encrypted Forensic Recovery for sensitive action data

[zimmerle]

Summary

AARM v1.0 protects sensitive content in receipts through redaction (destructive) or hashing (integrity-preserving but non-recoverable). Neither supports a legitimate operational need: forensic recovery of sensitive payloads by authorized personnel, without that content being readable to routine receipt-store consumers or backups. This issue proposes R10: Encrypted Forensic Recovery, an additive SHOULD conformance requirement specifying field-level envelope encryption (JWE General JSON Serialization, RFC 7516) with classification-aligned multi-recipient key tiers, and decryption modeled as an AARM-governed action.

What I'm asking for

Direction-level feedback before opening a PR. The RFC is structurally complete, but I want to confirm the approach aligns with TWG thinking before investing in the follow-on artifacts (pattern document, conformance table patch). Specifically: is this gap on the roadmap, is the proposed design directionally sound, and is SHOULD the right conformance level?

Key questions for the TWG

1. Is this gap already under discussion somewhere I haven't seen?
2. Is SHOULD the right conformance level, or is there appetite for MUST from the start?
3. Should the RFC mandate specific JOSE algorithms (Section 5.2 of the draft does), or only require "any IANA-registered AEAD / key-wrap"?
4. Preferred location in the repo. A new rfcs/ directory establishing precedent, or land directly as patterns/encrypted-forensic-storage.mdx plus a conformance/requirements.mdx patch?
5. Decryption operation naming: aarm.receipt.decrypt_field (bikeshed-friendly).
6. Relationship to existing parameters_hash / output_hash fields. Keep both (different purposes) or replace?
7. Are there contributors I should loop in directly (e.g., people who shaped the Receipt Generator or Approval Service specs)?

Full RFC draft

Click to expand - ~2,500 words

RFC: Encrypted Forensic Recovery for Sensitive Action Data

Field	Value
RFC	TBD (proposed)
Title	Encrypted Forensic Recovery for Sensitive Action Data
Status	Draft
Author	Felipe Zimmerle, PhD (KonaSense, Inc.)
Contact	felipe@konasense.com
Created	2026-05-15
Targets	AARM v1.1 (additive to v1.0)
Proposes	New conformance requirement R10 (SHOULD)
Affects	Receipt Generator, Telemetry Exporter, Policy Engine, Approval Service

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, and RECOMMENDED in this document are to be interpreted as described in RFC 2119 and RFC 8174.

---

1. Abstract

AARM v1.0 protects sensitive data in receipts and telemetry primarily through redaction (destructive) and hashing (integrity-preserving but non-recoverable). Neither mechanism supports a legitimate operational need: forensic recovery of sensitive content by appropriately authorized personnel, without that content being readable in routine audit storage or by routine operator audiences.

This RFC proposes R10: Encrypted Forensic Recovery: an additive, optional conformance requirement that defines a field-level encryption scheme for sensitive content in AARM receipts. The scheme uses standard envelope encryption (JWE General JSON Serialization, RFC 7516) with multiple recipients, organized into classification-aligned key tiers. Decryption is itself modeled as an AARM-governed action, producing its own signed receipt and flowing through the existing Policy Engine and Approval Service.

The proposal is fully backward-compatible with AARM v1.0. Systems that do not implement R10 are unaffected.

---

2. Motivation

2.1 The Operational Gap

Consider a representative incident:

A monitor flags that an AI agent invoked a tool with a credential in its parameters. The Security Operations team needs to determine: which credential was used, whether the same credential appears in other recent sessions, and whether the use was authorized. The investigation may occur hours or days after the original action.

AARM v1.0 gives the implementer two options for the sensitive parameter:

Option	Effect	Forensic Cost
Store in plaintext	Investigator can read directly	Secret exposed to all receipt-store readers; broad blast radius if backups, replicas, or query interfaces are compromised
Redact / hash	Secret not exposed in storage	Investigator cannot recover the original value, even with full authorization

Neither matches the operational reality: a small number of authorized personnel must be able to read sensitive payloads under controlled, audited circumstances; everyone else, and every routine pipeline, must not.

This pattern is well-established in adjacent domains, payment card environments, healthcare records, regulated audit logs, and is consistently solved with field-level envelope encryption keyed by data classification. AARM has not yet adopted it.

2.2 Why Not Just "Store Encrypted at Rest"?

Disk-level or database-level encryption ("encryption at rest") does not solve this problem. Such encryption is transparent to applications: any process that can query the receipt store sees plaintext. It defends against physical media theft, not against routine read access by services, operators, backups, or compromised query interfaces.

Field-level encryption, where the ciphertext is what is stored, queried, and replicated, and decryption requires possession of a private key not available to routine consumers, is the correct boundary for sensitive action data.

---

3. Goals and Non-Goals

3.1 Goals

1. Forensic recoverability. Authorized personnel MUST be able to recover the plaintext of sensitive fields, under controlled and audited conditions.
2. Routine non-exposure. Sensitive fields MUST NOT be readable to consumers of receipts, telemetry, backups, or downstream pipelines without explicit decryption authority.
3. Tiered access. Different classifications of sensitive content (credentials, PII, internal-confidential, etc.) MUST be separately keyed, so that compromise of one tier's keys does not expose other tiers.
4. Multiple authorized readers per tier. Each tier MUST support a set of recipients (security engineering, DPO, break-glass authority, etc.), any of whom can independently decrypt.
5. Decryption auditability. Every decryption MUST produce its own AARM receipt, recording who decrypted what, when, and under what authorization.
6. Standard primitives. The scheme MUST use IANA-registered cryptographic algorithms and well-established formats. No bespoke crypto.
7. Backward compatibility. Existing AARM v1.0 deployments and verifiers MUST continue to function without modification.

3.2 Non-Goals

1. Correlation across encrypted appearances. This RFC deliberately does not propose a mechanism for detecting when the same sensitive value appears in multiple receipts without decrypting. Correlation tags (e.g., keyed HMACs over plaintext) were considered and rejected on grounds of additional key-custody burden and incremental brute-force exposure surface. Forensic "did this credential appear elsewhere?" queries are answered by authorized decryption of candidate receipts.
2. Encrypted search. This RFC does not provide structured search over encrypted fields. Such mechanisms (deterministic encryption, searchable symmetric encryption) carry significant additional security trade-offs and are out of scope.
3. Post-quantum cryptography. The algorithms specified are classical. Algorithm agility (Section 5.3) provides a migration path when post-quantum primitives are standardized in JOSE.
4. Standardizing sensitive-content detection. The classifier that identifies a field as CREDENTIAL vs PII vs other is deployment-specific and out of scope. This RFC consumes the classification produced by AARM's existing data-classification machinery.

---

4. Design Overview

4.1 Field-Level Envelope Encryption

Sensitive fields are individually encrypted using JWE General JSON Serialization (RFC 7516, Section 7.2.1). This is standard envelope encryption with two layers:

• Content encryption. A fresh symmetric Content Encryption Key (CEK) is generated per encryption and used with an AEAD algorithm to produce the ciphertext.
• Key wrapping (multi-recipient). The CEK is wrapped separately for each authorized recipient using the recipient's public key. Each recipient receives a wrapped copy of the same CEK; any recipient can unwrap their copy and decrypt the shared ciphertext.

The JWE blob containing the ciphertext and all wrapped CEKs replaces the plaintext value in the receipt.

4.2 Classification-Aligned Key Tiers

Each sensitivity classification maps to a key tier. A key tier defines a recipient set: the public keys whose corresponding private-key holders are authorized to decrypt content of that classification.

Tier ID (suggested default)	Classification	Suggested Recipients
tier-credential	CREDENTIAL	Security Engineering, Break-Glass
tier-pii	PII	Data Protection Officer, Privacy Engineering, Break-Glass
tier-confidential	CONFIDENTIAL	Data Owner, Security Operations, Break-Glass

The mapping from classification to tier, and the recipient set within each tier, MUST be policy-configurable. The defaults above are illustrative only.

Each tier is encrypted under its own JWE blob. A receipt containing both a credential and a PII field produces two independent JWE blobs (one per field, each addressed to its tier's recipient set). Compromise of the tier-credential private keys does not expose tier-pii content.

4.3 Break-Glass Recipient

Every key tier SHOULD include a break-glass recipient as a default member of the recipient set. The break-glass private key SHOULD be protected by multi-party authorization (e.g., Shamir's Secret Sharing with a threshold of t of n custodians).

The break-glass recipient ensures recoverability under organizational changes (departures, role transitions) without requiring re-encryption of historical receipts, which would violate AARM's append-only receipt requirement (R5).

4.4 Decryption as an AARM Action

Decryption of a sensitive field is itself an AARM-governed action. The proposed canonical operation:

Field	Value
tool	aarm.receipt
operation	decrypt_field
parameters	{ "receipt_id": "...", "field_path": "...", "justification": "..." }

A decryption action:

• MUST flow through the standard Policy Engine
• MUST default to STEP_UP authorization for tier-credential and tier-pii content
• MUST produce its own signed receipt, with the decrypted-receipt's receipt_id recorded as a reference in the new receipt's context
• MUST NOT include the plaintext result of decryption in its own receipt's parameters or output (the recovered plaintext is returned to the authorized caller out-of-band; the receipt records the act of decryption, not the value)

This reuses AARM's existing approval, audit, and policy machinery to govern decryption, rather than introducing a parallel control plane.

---

5. Specification

5.1 Encrypted Field Schema

When a receipt field is encrypted under R10, its value MUST be replaced with an object of the following shape:

{
  "encrypted": true,
  "classification": "CREDENTIAL",
  "key_tier": "tier-credential",
  "jwe": {
    "protected": "<base64url(JWE Protected Header)>",
    "iv": "<base64url>",
    "ciphertext": "<base64url>",
    "tag": "<base64url>",
    "recipients": [
      {
        "header": {
          "kid": "security-eng-2026q2",
          "alg": "ECDH-ES+A256KW",
          "epk": { "kty": "OKP", "crv": "X25519", "x": "..." }
        },
        "encrypted_key": "<base64url>"
      },
      {
        "header": {
          "kid": "breakglass-2026q2",
          "alg": "RSA-OAEP-256"
        },
        "encrypted_key": "<base64url>"
      }
    ]
  }
}

Required fields:

Field	Required	Description
encrypted	MUST	Boolean literal true. Marks the field as R10-encrypted.
classification	MUST	The data classification that drove encryption (e.g., CREDENTIAL, PII).
key_tier	MUST	Identifier of the key tier under which the field was encrypted.
jwe	MUST	A JWE General JSON Serialization object per RFC 7516 §7.2.1.

5.2 Mandatory and Recommended Algorithms

The following algorithm requirements apply:

Layer	MUST support	SHOULD support	MUST NOT use
Content encryption (enc)	A256GCM	A128GCM, ChaCha20-Poly1305 (if registered)	Any non-AEAD mode (e.g., A256CBC without HS512); none
Key wrap for EC recipients	ECDH-ES+A256KW	ECDH-ES+A128KW	Plain ECDH-ES (direct mode) for multi-recipient
Key wrap for RSA recipients	RSA-OAEP-256	RSA-OAEP-384, RSA-OAEP-512	RSA1_5

All algorithm identifiers MUST be drawn from the IANA JOSE Algorithms registry. Implementations MAY support additional registered algorithms; they MUST NOT introduce non-registered identifiers.

The none algorithm MUST NOT be accepted under any circumstances.

5.3 Algorithm Agility

Each JWE encryption records its algorithms in the protected header (enc) and per-recipient header (alg). Implementations MUST honor these on decryption regardless of the currently configured defaults. This enables migration to new primitives (including future post-quantum algorithms once registered in JOSE) without invalidating historical receipts.

5.4 Key Tier Configuration

A key tier configuration is a policy-level object structured approximately as follows:

key_tiers:
  - id: tier-credential
    classifications: [CREDENTIAL]
    recipients:
      - kid: security-eng-2026q2
        public_key_jwk: { kty: "OKP", crv: "X25519", x: "..." }
        custodian: "security-engineering"
        custody_method: "HSM"
      - kid: breakglass-2026q2
        public_key_jwk: { kty: "RSA", n: "...", e: "AQAB" }
        custodian: "breakglass-multisig"
        custody_method: "shamir-3-of-5"
    default_decryption_decision: STEP_UP
    default_approvers: [security-engineering-lead, ciso]

Tier configuration MUST be versioned; the version applicable at encryption time MUST be discoverable from the receipt (e.g., via the key_tier identifier embedding a version, or by referencing the policy version in the receipt's decision.policy.version).

5.5 Receipt Generator Behavior

When generating a receipt that contains fields classified at or above a configured threshold:

1. For each sensitive field, look up the configured key tier for the field's classification.
2. Generate a fresh CEK using a cryptographically secure random source.
3. Encrypt the plaintext field value using the tier's configured content encryption algorithm (e.g., A256GCM) with the CEK and a fresh IV.
4. For each recipient in the tier, wrap the CEK using the recipient's configured key wrap algorithm.
5. Construct the JWE General JSON Serialization object.
6. Replace the plaintext field value in the receipt with the encrypted field schema defined in Section 5.1.
7. Sign the receipt as specified in R5. The signature MUST cover the encrypted form (i.e., the JWE blob is signed, not the plaintext).

If encryption fails for any reason (no configured tier, no available recipients, cryptographic operation failure), the Receipt Generator MUST fail closed: the originating action MUST be denied and a denial receipt produced. Plaintext storage as fallback is explicitly prohibited.

5.6 Decryption Flow

A consumer wishing to recover a plaintext value:

1. Submits an aarm.receipt.decrypt_field action through the standard Action Mediation Layer.
2. The Policy Engine evaluates the request against policy. The default decision for tier-credential and tier-pii SHOULD be STEP_UP.
3. On approval, the Decryption Service:
   a. Locates the referenced receipt and the encrypted field.
   b. Identifies the requester's authorized recipient identity (via existing identity binding, R6).
   c. Unwraps the CEK using the appropriate private key (typically via HSM operation).
   d. Decrypts the ciphertext.
   e. Returns the plaintext to the authorized caller via the response channel.
4. A new receipt is generated for the decryption action, recording requester identity, target receipt and field path, decision, approver, and timestamp. The plaintext MUST NOT appear in this receipt.

5.7 Telemetry Behavior

The existing rule from the side-channel-leakage threat, that telemetry exporters SHOULD scrub or hash sensitive fields before export, remains in effect. R10 does not change this. The encrypted forensic store is a separate recoverable layer; telemetry continues to be redacted/hashed for routine monitoring consumers.

Implementations MAY include encrypted fields in telemetry exports, provided the consuming SIEM is itself treated as a trust boundary at the appropriate level. By default, telemetry SHOULD NOT include encrypted fields.

---

6. Conformance

6.1 Proposed Requirement Text (for conformance/requirements.mdx)

R10: Encrypted Forensic Recovery

The system SHOULD support encryption of sensitive fields in receipts using a multi-recipient envelope encryption scheme aligned with data classification.

○ Encrypt sensitive fields using JWE General JSON Serialization (RFC 7516)
○ Use only IANA-registered AEAD content encryption algorithms
○ Support multiple recipients per encrypted field, organized into classification-aligned key tiers
○ Include a break-glass recipient in each tier, protected by multi-party authorization
○ Model decryption as an AARM action, governed by the standard Policy Engine and Approval Service
○ Produce a signed receipt for every decryption, referencing the source receipt
○ Fail closed on encryption failure: never store plaintext as fallback

Verification: Configure a tier with multiple recipients. Submit an action containing a field classified at that tier. Verify the resulting receipt contains a JWE blob with the correct recipient set and that the receipt signature validates over the encrypted form. Submit a decryption action; verify it flows through policy evaluation, produces its own receipt, and returns plaintext only to the authorized caller. Attempt decryption with an unauthorized identity; verify denial.

6.2 Conformance Level Placement

R10 is proposed as SHOULD rather than MUST:

• It addresses an operational need that not every deployment has (organizations without sensitive-payload forensic-recovery requirements remain conformant without it).
• It introduces non-trivial key custody operational burden.
• A MUST classification would force key-management infrastructure on implementers for whom it is overkill.

If implementation experience demonstrates the requirement is broadly applicable, future spec versions MAY promote it to MUST.

---

7. Integration with Existing Components

Component	Change
Action Mediation Layer	No change. Classification continues to be produced as in v1.0.
Context Accumulator	No change.
Policy Engine	Adds rules governing aarm.receipt.decrypt_field actions. Tier configuration loaded as policy.
Approval Service	Reused for decryption STEP_UP flows. No new functionality required.
Receipt Generator	Extended per Section 5.5. New encrypted-field schema (Section 5.1) added.
Telemetry Exporter	No required change. MAY be configured to include encrypted blobs (Section 5.7).
New: Decryption Service	New logical component. May be co-located with Receipt Generator or operated independently. Manages private key access (typically via HSM).

---

8. Threat Model

8.1 Threats Addressed

Threat	R10 Mitigation
Receipt store breach (read access to ciphertext only)	Plaintext not recoverable without private keys not held in the receipt store environment.
Backup or replica exposure	Same: ciphertext is what is replicated.
Routine operator access to receipt store	Routine operators are not recipients; cannot decrypt.
Single-tier key compromise	Compromise of tier-credential keys does not expose tier-pii content (independent JWE blobs).
Single-recipient compromise within a tier	Other recipients in the tier (including break-glass) remain available; the tier is not fully compromised.
Departed-personnel access loss	Break-glass recipient ensures continued forensic access without re-encrypting historical receipts.

8.2 Threats NOT Addressed

Threat	Why Out of Scope / How Mitigated Elsewhere
Insider abuse by legitimate recipient	Cryptographic measures cannot prevent legitimate key holders from decrypting. Mitigation: decryption-as-action ensures every decryption is non-repudiably audited (Section 5.6).
All recipient keys compromised simultaneously	Full plaintext exposure. Mitigation: multi-party break-glass; HSM custody; standard key management practice.
Compromise of the AARM system at encryption time	If the system performing encryption is compromised, it has plaintext access by definition. Out of scope; addressed by infrastructure security controls.
Quantum cryptanalysis of stored ciphertexts	Out of scope for v1.1. Algorithm agility (Section 5.3) provides future migration path.
Side channels in the encryption implementation	Out of scope; addressed by implementation-level cryptographic engineering best practice.

8.3 Interaction with Existing AARM Threats

R10 strengthens defenses against side-channel leakage (existing threat) by providing a recoverable alternative to destructive redaction. It does not alter defenses against other threats in the AARM threat model.

---

9. Operational Considerations

9.1 Key Custody

Private keys for tier recipients SHOULD be protected by Hardware Security Modules (HSMs) or equivalent custody mechanisms. The threat model assumes private keys are not accessible to the receipt store, telemetry pipeline, or routine operator audiences.

Break-glass keys SHOULD be protected by multi-party authorization. Shamir's Secret Sharing with a threshold of at least 2-of-3 (and typically 3-of-5) is RECOMMENDED. Custodians SHOULD be drawn from organizationally distinct roles to avoid single-points-of-collusion.

9.2 Key Rotation

Public keys for tier recipients MAY be rotated. Rotation MUST NOT invalidate historical receipts:

• Old private keys MUST remain available for decryption of receipts encrypted under their corresponding public keys.
• New receipts use the current generation of public keys.
• Receipts reference the specific key generation used via the JWE kid field.

Re-encryption of historical receipts under new keys is explicitly NOT REQUIRED and MUST NOT be performed in a way that violates R5 (tamper-evident, append-only receipts).

9.3 Recipient Set Changes

Adding a new recipient to a tier affects only new encryptions. Historical receipts retain their original recipient set. If a new recipient requires access to historical content, the mechanism is:

1. An existing recipient (typically break-glass) performs decryption-as-an-AARM-action.
2. The recovered plaintext is delivered to the new recipient through an appropriate out-of-band channel.

This preserves receipt immutability while permitting access control evolution.

9.4 Retention

Encrypted receipts may be retained according to the same policy as plaintext receipts in v1.0 deployments. Encryption does not by itself extend or shorten retention obligations under applicable regulations. Organizations subject to "right to erasure" obligations (e.g., GDPR Art. 17) SHOULD consider that destruction of all copies of a key tier's private keys renders that tier's ciphertexts permanently unreadable, a property that MAY be operationally useful for compliant erasure of indirectly-stored personal data.

---

10. Backward Compatibility

R10 is fully backward-compatible with AARM v1.0:

• Implementations not adopting R10 are unaffected. Their receipts continue to use redaction or hashing per existing patterns.
• Verifiers (R5 signature verification) operate on canonical receipt content. The encrypted-field schema is treated as opaque data within the signed receipt; signature verification does not require decryption capability.
• Conformance at the AARM Core and AARM Extended levels (defined in conformance requirements) is unaffected. R10 conformance is independently claimed.
• Receipts produced under R10 can be consumed by R10-unaware tooling, which sees the encrypted-field object as a structured value but cannot decrypt it. No tooling breaks.

---

11. Open Questions

The following points are deliberately left open for TWG discussion:

1. Public key distribution. How are tier recipient public keys discovered and trusted by the Receipt Generator? Options include: static configuration in policy, a JWKS endpoint, integration with an existing organizational PKI. This RFC does not mandate a specific mechanism.

2. Cross-organization receipts. In multi-tenant or cross-organization deployments, do recipient sets cross organizational boundaries? If so, how is trust established? Likely deferred to a future RFC.

3. Field path identification. The decrypt_field action references a field by path. Is JSON Pointer (RFC 6901) the appropriate path syntax, or should AARM define its own?

4. Decryption rate limiting. Should there be a normative requirement on rate-limiting decryption requests to prevent enumeration attacks against the receipt store? Or is this left to the Policy Engine configuration?

5. Integration with R9 (least privilege). R9 requires just-in-time scoped credentials. If credentials are short-lived to the point of being unusable post-action, is forensic recovery of the credential value still necessary? (Argument: yes, forensic understanding of what was used, not just that something was used. But this should be discussed.)

6. Relationship to existing parameters_hash / output_hash fields. Should these continue to be emitted alongside the encrypted form, or replaced? Recommendation: continue to emit, as they serve a different purpose (integrity proof of recorded action vs. recoverable content). Open for confirmation.

7. Algorithm requirements as MUST vs. SHOULD. Section 5.2 lists mandatory algorithms. Should the spec be more permissive (any IANA-registered AEAD) or more restrictive? Calibration question for the TWG.

---

12. Prior Art and References

Standards

• RFC 7516: JSON Web Encryption (JWE)
• RFC 7518: JSON Web Algorithms (JWA)
• RFC 8037: CFRG ECDH and Signatures in JOSE
• RFC 5652: Cryptographic Message Syntax (referenced for multi-recipient prior art)
• RFC 6901: JSON Pointer
• RFC 2119 / RFC 8174: Requirement levels

AARM Specification References

• conformance/requirements.mdx: R1 through R9 (this RFC proposes R10)
• components/receipts.mdx: Receipt Generator and Receipt schema
• components/policy-engine.mdx: Policy Decision and Enforcement Points
• components/approval-service.mdx: STEP_UP authorization workflow
• threats/side-channel-leakage.mdx: Threat addressed by this proposal
• patterns/receipt-signing.mdx: Existing signature mechanism (preserved)

Prior Art

• Hybrid Public Key Encryption (RFC 9180): modern alternative to JWE for hybrid encryption; deferred in favor of JWE due to ecosystem maturity in JSON-native contexts.
• AWS KMS envelope encryption and the GCP/Azure equivalents, operational prior art for the multi-recipient, tier-keyed pattern.
• age / rage - modern file encryption tools using single-CEK-with-multiple-wrapped-recipients structure analogous to JWE General JSON Serialization.

---

13. Acknowledgments

The author thanks the following individuals for their review, feedback, and contributions to this proposal:

• Rafael Silva (KonaSense, Inc)
• Gustavo Monteiro (KonaSense, Inc)
• Cristiano Lincoln (KonaSense, Inc)

---

Appendix A: Worked Example

A representative receipt fragment, before and after R10 encryption, for an action invoking a database with a credential parameter.

Before (v1.0, with redaction)

{
  "action": {
    "tool": "database",
    "operation": "connect",
    "parameters": {
      "host": "db.internal.example.com",
      "username": "agent_svc",
      "password": "[REDACTED]"
    }
  }
}

After (v1.1 with R10 encryption)

{
  "action": {
    "tool": "database",
    "operation": "connect",
    "parameters": {
      "host": "db.internal.example.com",
      "username": "agent_svc",
      "password": {
        "encrypted": true,
        "classification": "CREDENTIAL",
        "key_tier": "tier-credential",
        "jwe": {
          "protected": "eyJlbmMiOiJBMjU2R0NNIn0",
          "iv": "48V1_ALb6US04U3b",
          "ciphertext": "5eym8TW_c8SuK0ltJ3rpYIzOeDQz",
          "tag": "XFBoMYUZodetZdvTiFvSkQ",
          "recipients": [
            {
              "header": {
                "kid": "security-eng-2026q2",
                "alg": "ECDH-ES+A256KW",
                "epk": { "kty": "OKP", "crv": "X25519", "x": "BT7aR0Ah9eJxQH6dRtfqIzZE0fkJ_t7C..." }
              },
              "encrypted_key": "Y3UVMc2_S0V8H5VfQk5z..."
            },
            {
              "header": {
                "kid": "breakglass-2026q2",
                "alg": "RSA-OAEP-256"
              },
              "encrypted_key": "rT99rwrBTbTI7IJM8fU3..."
            }
          ]
        }
      }
    }
  }
}

The receipt is then signed per R5; the signature covers the encrypted form. The plaintext credential never enters durable storage.

---

Appendix B: Worked Example: Decryption Receipt

When Security Engineer Bob recovers the credential above:

{
  "receipt_id": "rct_decrypt_8a3f",
  "version": "1.0",
  "action": {
    "action_id": "act_decrypt_2c91",
    "timestamp": "2026-05-20T14:22:31Z",
    "tool": "aarm.receipt",
    "operation": "decrypt_field",
    "parameters": {
      "receipt_id": "rct_original_7f8a",
      "field_path": "/action/parameters/password",
      "justification": "INC-2026-0517 forensic review"
    },
    "identity": {
      "human": "bob@company.com",
      "service": "decryption-service",
      "session": "sess_inv_4421",
      "scope": "tier-credential:decrypt"
    }
  },
  "decision": {
    "result": "ALLOW",
    "policy": {
      "policy_id": "decrypt-credential-stepup",
      "version": "2026-04-01"
    },
    "reason": "STEP_UP approved by ciso@company.com"
  },
  "approval": {
    "approver": "ciso@company.com",
    "decided_at": "2026-05-20T14:22:28Z",
    "decision": "APPROVED",
    "reason": "Tied to active incident INC-2026-0517"
  },
  "execution": {
    "started_at": "2026-05-20T14:22:31Z",
    "completed_at": "2026-05-20T14:22:31.085Z",
    "success": true,
    "output_hash": null
  },
  "signature": { "algorithm": "Ed25519", "key_id": "aarm-signing-2026-q2", "value": "..." }
}

Note that execution.output_hash is null and no plaintext appears in this receipt. The plaintext was returned to Bob through the response channel and is not durably recorded.