--- name: agentprivacy-enclave-operations description: > Trusted Execution Environment operations for 0xagentprivacy swordsman agents. Activates when designing hardware-backed computation, implementing remote attestation, managing sealed storage, or building agent operations within TEE boundaries where even the host OS is untrusted. Triggers: "TEE", "enclave", "trusted execution", "attestation", "sealed storage", "secure enclave", "SGX", "TrustZone", "SEV", "confidential computing", "hardware trust", "NEAR TEE". license: Apache-2.0 metadata: version: "5.0" category: "role" origin: "0xagentprivacy" author: "Mitchell Travers" affiliation: "0xagentprivacy, BGIN, First Person Network" status: "working_paper" equation_term: "P × C — hardware-enforced protection with verifiable computation" template_references: "soulbis, sentinel, cipher, gatekeeper, architect" --- # PVM-V4 Skill — Enclave Operations **Source:** Privacy Value Model V4 + NEAR AI Integration + Confidential Computing Architecture **Target context:** TEE application developers, confidential computing architects, hardware security researchers, agent execution environment designers, attestation infrastructure builders **Architecture:** [agentprivacy.ai](https://agentprivacy.ai) · **Sync:** [sync.soulbis.com](https://sync.soulbis.com) · **Contact:** mage@agentprivacy.ai --- ## What this is Software-only privacy has a ceiling: the operating system, the hypervisor, the cloud provider — someone in the stack can inspect memory. Trusted Execution Environments break through that ceiling by creating hardware-enforced boundaries where even privileged software cannot inspect what happens inside. The swordsman's most physically defensible position. An enclave is a region of processor memory that is encrypted and integrity-protected by the CPU itself. Code and data inside the enclave are invisible to everything outside it — including the kernel, the hypervisor, and anyone with physical access to the machine (within the hardware's threat model). This is where the swordsman's most sensitive operations belong. ## TEE landscape **Intel SGX (Software Guard Extensions).** Process-level enclaves on Intel CPUs. Each enclave is a protected region within a user-space process. Strong isolation model but limited enclave size (historically constrained, relaxed in newer hardware). The most mature ecosystem for enclave development. **AMD SEV (Secure Encrypted Virtualisation).** VM-level encryption. Entire virtual machines run with memory encrypted by keys managed by the AMD security processor. Larger protected regions than SGX (full VM), but coarser isolation granularity. Well-suited for cloud deployments. **ARM TrustZone.** Processor-level world separation: "Normal World" and "Secure World." The secure world has its own memory, peripherals, and execution context invisible to the normal world. Dominant in mobile and embedded devices — every modern smartphone has TrustZone. **RISC-V Keystone / Sanctum.** Open-source TEE implementations on RISC-V processors. No vendor lock-in, auditable design, growing ecosystem. Aligns with the architecture's principle that security should be verifiable, not trusted. **NEAR TEE integration.** The NEAR AI platform provides TEE-backed execution environments for AI agents. The swordsman can operate within NEAR TEE to ensure that agent computation is verifiable and that agent state is sealed — even the platform operator cannot inspect what the swordsman is doing. ## Core enclave operations ### Sealed storage Data encrypted to a key that is bound to the specific enclave code and the specific hardware platform. The sealed data can only be decrypted by the same code running on the same hardware (or a platform with the same sealing policy). **Swordsman application.** The signing key's long-term storage. Sealed to the swordsman enclave's measurement (code hash). If anyone modifies the swordsman code, the sealed key becomes inaccessible — the key is bound to the correct code, not just the correct hardware. This prevents supply chain attacks where a compromised swordsman binary tries to unseal keys from a legitimate one. **Sealing policies.** Seal to exact code measurement (MRENCLAVE in SGX): tightest binding, breaks on any code update. Seal to signer identity (MRSIGNER in SGX): allows code updates from the same developer without re-sealing. The choice depends on the threat model — exact measurement for maximum security, signer identity for operational flexibility. ### Remote attestation Cryptographic proof that a specific piece of code is running inside a genuine TEE on genuine hardware. The proof is generated by the hardware itself and can be verified by any remote party. **Swordsman application.** When the Person's swordsman signs an authorisation, the counterparty can verify (via attestation) that the signature came from a genuine swordsman enclave — not from a compromised binary, not from an emulator, not from a debugging environment. The attestation chain: hardware manufacturer → platform → enclave → swordsman code measurement. **Attestation in the dual-agent architecture.** Both swordsman and mage can run in separate enclaves on the same hardware. Cross-attestation verifies the separation: the swordsman's enclave attests that it cannot access the mage's enclave, and vice versa. This is Φ(Σ) enforced at the hardware level — the separation is not just a software convention but a hardware boundary. ### Secure computation Performing operations on sensitive data inside the enclave without the data ever being exposed in cleartext outside the enclave boundary. **Swordsman application.** The boundary enforcement pipeline (6-stage decision) runs inside the enclave. The consent lookup, scope check, and minimum disclosure calculation all happen within hardware protection. Even if the host OS is compromised, the enforcement pipeline's inputs (consent declarations, request details) and outputs (allow/block/transform decisions) remain confidential. **Multi-party enclave computation.** Multiple parties contribute encrypted inputs to an enclave. The enclave decrypts, computes, and returns only the result — no party sees another's input. This is the infrastructure beneath Intel Pools: contributions are decrypted only inside the aggregation enclave, where differential privacy noise is added before results leave the enclave boundary. ## Enclave lifecycle **Provisioning.** The enclave is created with a specific code measurement. The code is auditable (open source, reproducible build). The measurement is published so any verifier can compare their local build against the deployed enclave. **Initialisation.** The enclave generates or unseals its key material. For a fresh deployment, this is the key generation ceremony happening inside the hardware boundary. For a restart, this is unsealing previously sealed keys. **Operation.** The enclave processes requests through its defined interface. No direct memory access from outside. Inputs enter through the enclave's entry points. Outputs leave through the enclave's exit points. Side-channel defences (constant-time operations, oblivious memory access) are implemented to resist information leakage through timing and access patterns. **Migration.** Moving an enclave from one physical machine to another requires re-sealing: unsealing the data on the source platform, transmitting it through an encrypted channel, and re-sealing on the destination platform. During migration, the data is momentarily in cleartext inside the source enclave — this is the most vulnerable moment and must be minimised. **Retirement.** When an enclave is decommissioned, sealed data must be either migrated or destroyed. Key material that is not migrated must be provably deleted — the hardware provides secure erasure guarantees that software deletion cannot match. ## Threat model boundaries TEEs are not omnipotent. The swordsman must understand what enclaves protect against and what they don't: **Protected against:** Software attacks from the host OS or hypervisor. Memory inspection by privileged code. Cold boot attacks (memory encryption). Simple physical probing (encrypted bus). **Partially protected against:** Side-channel attacks (timing, cache, power analysis). TEE vendors have progressively patched side channels, but new ones are regularly discovered. The swordsman implements constant-time code and oblivious memory access as defence-in-depth. **Not protected against:** Hardware supply chain compromise (a backdoored CPU). Physical attacks by a sophisticated adversary with decapping equipment. Bugs in the TEE implementation itself (e.g., SGX has had several vulnerability disclosures). The swordsman treats TEE protection as one layer, not the only layer. **The enclave as trust anchor, not trust omniscience.** The enclave anchors specific guarantees (this code ran, this data was sealed) but does not make the entire system trustworthy. The swordsman uses the enclave for its highest-value operations (key storage, signing, enforcement decisions) while maintaining software-layer defences for everything else. ## Connection to the equation **P — protection.** Hardware enclaves provide the strongest achievable P for the operations they contain. Software P can be undermined by OS compromise. Enclave P requires hardware compromise — a fundamentally higher bar. The P^1.5 superlinear return means that enclave-backed protection compounds more powerfully than software-only protection. **C — verifiability.** Remote attestation IS verifiability. The counterparty can verify that the swordsman's code is genuine, unmodified, and running inside real hardware. This cryptographic verifiability — not trust in a vendor's promise — is what C measures. **Φ(Σ) — separation.** Cross-enclave attestation enforces the dual-agent separation at the hardware level. Swordsman enclave ⊥ mage enclave. The hardware guarantees that no software — no matter how privileged — can bridge the gap between them. This is the strongest possible enforcement of det(Σ) ≠ 0. --- **Verify:** [agentprivacy.ai](https://agentprivacy.ai) · [sync.soulbis.com](https://sync.soulbis.com) · [github.com/mitchuski/agentprivacy-docs](https://github.com/mitchuski/agentprivacy-docs)