Operator-Blind Secret Mediation for AI Agents: A Formal Model and FHE Construction for Credential Derivation on Untrusted Infrastructure

Abstract

Artificial intelligence (AI) agents increasingly need credentials such as application programming interface (API) keys and Secure Shell (SSH) credentials, but placing those secrets in the agent process exposes them to prompt injection, tool misuse, and exfiltration through ordinary agent outputs. We present CapSeal, a capability-based broker that replaces direct secret access with session-bound, non-exportable handles. Agents request policy-evaluated actions, while the broker performs credential-bearing Hypertext Transfer Protocol (HTTP) and SSH execution through typed executors with schema validation, replay protection, revocation epochs, and tamper-evident audit logging. We extend this design to hosted settings where the broker operator is not trusted with tenant secrets. Our main contribution is operator-blind secret mediation: a split-broker architecture in which a small trusted tenant gateway cooperates with an untrusted operator service that stores the master secret only as a fully homomorphic encryption (FHE) ciphertext and evaluates per-request derivations without decrypting it. We formalize the model and prove computational operator blindness from indistinguishability under chosen-plaintext attack (IND-CPA) security of the FHE scheme, together with conditional capability binding for any secure pseudorandom function/message authentication code (PRF/MAC) instantiation. We implement an end-to-end TFHE-rs prototype that exercises split-broker derivation, multi-tenant revocation and rate limiting, audit integration, and HTTP/SSH mediation. The prototype uses a non-cryptographic homomorphic stand-in and measures the cost of crossing the operator-untrusted boundary at about 9 s per request, roughly 17 million times slower than the plaintext path. We also give LowMC and Rasta transciphering designs and compare FHE with trusted execution environment (TEE)- and secure multiparty computation (MPC)-based alternatives, positioning each trust boundary by assurance and performance.

1. Introduction

Artificial intelligence (AI) agents are increasingly connected to development environments, production services, and administrative toolchains. These systems often need credentials in order to perform useful work: fetching private data, deploying code, calling paid application programming interfaces (APIs), or opening Secure Shell (SSH) sessions. The resulting security problem is different from ordinary secret storage. A credential may be encrypted at rest and still become exposed at the moment an agent is prompted to use it, because the agent process is both semantically steerable and connected to external outputs.

Several attack classes make this use-time exposure concrete:

• Prompt Injection: Exploiting large language model (LLM) vulnerabilities to hijack agent intent [1,2].
• Skill Poisoning: Corrupting the functional capabilities or “skills” an agent retrieves to perform tasks [3,4].
• Model Context Protocol (MCP) Poisoning: Injecting malicious context or instructions through standardized communication protocols [5,6].
• Supply Chain Attacks: Compromising the external libraries and toolkits that agents rely upon [7,8].

These threats share a common failure mode: once a bearer credential is placed inside the agent’s reachable execution context, policy must rely on the same steerable component that an adversary is trying to manipulate. We address this use-time exposure with CapSeal, a capability-based security broker that replaces direct credential access with constrained, broker-mediated invocations. The agent never obtains the secret; instead, it requests a session-bound, non-exportable handle for a specific, policy-evaluated intent, and a trusted gateway mediates all credential-bearing actions through typed execution paths—enforcing schema constraints, tracking anti-replay state, applying an epoch-based revocation protocol, and recording every decision in a tamper-evident audit chain [9]. CapSeal is exposed to agents as a small set of tools through a filtered Model Context Protocol (MCP) adapter, so capability discovery itself never becomes a side channel for secret existence.

A conventional broker, however, is itself trusted with the plaintext secret. This is a poor fit for managed or hosted agent infrastructure, where the party operating the broker may be distinct from the tenant that owns the credential. We therefore design CapSeal for the operator-untrusted setting and ask: can a tenant run the broker on infrastructure it does not trust, and still prevent the operator from seeing a plaintext secret? We answer this for the secret-confidentiality boundary through operator-blind secret mediation: a thin trusted tenant gateway mediates each request, while an untrusted operator service stores the master secret as a fully homomorphic encryption (FHE) ciphertext and blindly evaluates a derivation interface without decrypting it. FHE is the primitive that lets the untrusted party compute over a secret it cannot read, and the same interface recovers a conventional trusted-broker deployment when the deriver is co-located with the gateway. We detail the design in Section 4.

This paper makes the following contributions:

• (C1) CapSeal capability-mediation core. We present CapSeal, a capability-based broker that replaces bearer-secret exposure with session-bound, non-exportable handles, typed Hypertext Transfer Protocol (HTTP)/SSH executors with schema and host/command constraints, anti-replay state, an epoch-based revocation protocol, a tamper-evident audit chain, and a filtered MCP adapter that hides capability and secret existence.
• (C2) Operator-blind split-broker design. We separate the broker into a trusted, thin tenant gateway and an untrusted operator secret service, removing operator trust for the secret-confidentiality path while preserving CapSeal’s capability-narrowing interface.
• (C3) Formal security model. We define the operator-blind mediation scheme and two security games, and prove computational operator blindness by reduction to the FHE scheme’s indistinguishability under chosen-plaintext attack (IND-CPA) security (Theorem 1) and conditional capability binding for any secure pseudorandom function/message authentication code (PRF/MAC) instantiation (Theorem 2).
• (C4) Transciphering to industrial-grade derivation. We give complete LowMC and Rasta transciphering constructions—parameters, homomorphic circuits, and security analyses—that upgrade the prototype derivation to 128-bit symmetric security, with a measured LowMC pipeline and an analytical Rasta projection.
• (C5) Split-broker prototype. We realize the design on TFHE-rs (a Rust implementation of Torus fully homomorphic encryption) with a non-cryptographic homomorphic stand-in that exercises ciphertext storage, blind derivation, artifact opening, executor reuse, replay checks, revocation epochs, multi-tenant isolation, and audit integration, and we additionally probe residual covert channels at the gateway boundary.
• (C6) Trust-boundary measurement and positioning. We measure the cost of moving secret-bearing computation across the operator-untrusted boundary and position FHE on a common capability substrate against a measured attested trusted execution environment (TEE) derivation service (Amazon Web Services (AWS) Nitro) and secure multiparty computation (MPC)/threshold signing, so an operator can select the boundary matching its threat model and budget.

2. Related Work

Operator-blind secret mediation sits at the intersection of six lines of work: the cryptographic machinery that makes blind computation practical, the FHE-friendly symmetric primitives and transciphering techniques that bridge standard cryptography to the homomorphic domain, the hardware-assisted confidential computing approaches that provide a lower-latency alternative trust boundary, the access-control tradition that motivates capability narrowing, the operational systems that manage secrets in production, and the emerging body of LLM-agent security results that define our threat model. We survey each and make explicit where our design departs from prior assumptions—chiefly, that the party holding and operating on the secret is itself untrusted.

2.1. Fully Homomorphic Encryption

Fully homomorphic encryption, since Gentry’s first construction [10], enables arbitrary computation directly on ciphertexts without access to the decryption key. The major scheme families target distinct workloads: Torus fully homomorphic encryption (TFHE) [11] evaluates both small-integer arithmetic and bitwise operations on a single radix-encoded ciphertext with per-gate programmable bootstrapping (via the TFHE-rs implementation [12]); Brakerski–Gentry–Vaikuntanathan (BGV) [13] and Brakerski/Fan–Vercauteren (BFV) [14] provide exact, batched modular arithmetic but no native bitwise operations; and Cheon–Kim–Kim–Song (CKKS) [15] targets batched approximate arithmetic better suited to machine-learning inference than to exact credential derivation. As we show below (Table 1), the prototype uses TFHE because our derivation interleaves an arithmetic and a bitwise primitive every round, and TFHE is the only family that evaluates that mixed, exact workload on a single ciphertext representation without the prohibitive data-layout and multiplicative-depth penalty the arithmetic schemes incur. Two costs dominate any FHE deployment and shape ours directly: ciphertext expansion (our 32-byte secret becomes a ∼2.1 MB ciphertext) and the expense of evaluating standard symmetric primitives homomorphically. Prior applications of FHE [16] largely concern outsourced data processing, where a server computes over a client’s encrypted records; CapSeal instead uses FHE in a narrowly scoped credential role: the encrypted object is a long-lived signing secret, the computation is a per-request keyed derivation, and the untrusted party never holds the decryption key. This revision does not propose a complete FHE circuit for hash-based message authentication code (HMAC)-SHA256, AWS Signature Version 4 (SigV4), or SSH signing. It uses a 16-round multiplication-XOR keyed derivation (Section 4.5) that provides collision resistance and pseudorandomness for capability binding (Theorem 2); the production-strength MAC and request-signing circuits under FHE remain future work.

Table 1. Per-primitive cost of the exact-arithmetic fully homomorphic encryption (FHE) candidate schemes in OpenFHE on a 64-bit operand (128-bit security, one host; medians of $n=50$), 64 bits packed in single-instruction, multiple-data (SIMD) slots. Addition (ADD) and cleartext multiplication (MUL_CLEAR) are native; bitwise AND and exclusive OR (XOR) are emulated (one ciphertext multiply, $+1$ multiplicative level each). “Bitwise exact”: whether AND/XOR yield bit-exact results.

Scheme	XOR	AND	ADD	MUL_CLEAR	Bitwise
	(ms)	(ms)	(ms)	(ms)	Exact
BGV	4.4	3.9	0.1	1.2	⬤
BFV	2.9	3.2	0.0	0.1	⬤
CKKS	4.2	3.5	0.1	0.9	○

Schemes: BGV = Brakerski–Gentry–Vaikuntanathan; BFV = Brakerski/Fan–Vercauteren; CKKS = Cheon–Kim–Kim–Song. ⬤ bitwise exact; ○ not bitwise exact.

The derivation of Section 4.5 interleaves, every round, a scalar multiply (mul_clear) with a 64-bit ciphertext–ciphertext xor, and the exact-arithmetic alternatives handle this mix poorly. We benchmarked BGV, BFV, and CKKS in OpenFHE [17] on a 64-bit operand (128-bit security, one Apple Silicon host, 64 bits packed across SIMD slots so an emulated bitwise operation—AND as $a·b$, XOR as $a+b-2ab$—covers the whole word in one ciphertext operation); Table 1 reports the medians. CKKS is disqualified outright: its bitwise emulation is approximate and cannot produce exact authentication artifacts. BGV and BFV are exact and emulate XOR/AND cheaply in isolation, but each bitwise operation costs a ciphertext multiply and one multiplicative level, and the cheap forms of the two primitives live in incompatible layouts—mul_clear is native only on an integer-packed word, the cheap XOR only on a bit-sliced one. Alternating them for 16 rounds forces either a per-round homomorphic layout conversion or a bit-sliced multiplier running to thousands of multiplicative levels; either way the leveled depth, and with it the ciphertext size and per-operation cost, explodes past what is feasible at 128-bit security (a single BGV multiply already grows to 66 ms over an 18 MiB ciphertext at depth 16).

2.2. Capability-Based Security

CapSeal draws on the long tradition of capability systems, whose central tenets—authority should be unforgeable, minimized, and attenuable rather than ambient—are surveyed by Miller et al.’s critique of common “capability myths” [18]. Macaroons [19] make these tenets practical for distributed authorization, encoding attenuation as a chain of HMAC-based caveats that any holder can further restrict but none can broaden; formal accounts of object-capability reasoning give these guarantees a semantic footing [20], and recent work pushes capability enforcement onto new substrates, including on-chain zero-knowledge delegation [21] and token-based access control for microservices [22]. All of this work, however, assumes that the component minting or attenuating the credential is trusted to hold the underlying key. Our cryptographic capability scoping (Section 4.6) models macaroon-style narrowing—host, path, method, expiry, and nonce bound into the derivation—but relocates the minting step to an untrusted operator: for a future secure PRF/MAC instantiation, the binding would be enforced through the structure of a homomorphically derived artifact rather than through a trusted process computing an HMAC.

2.3. Secret Management Systems

Production secret managers such as HashiCorp Vault’s Transit engine and cloud Key Management Service (KMS) offerings [23,24] popularized the “use without export” interface: applications submit data to be signed or encrypted and never retrieve the raw key, which reduces the blast radius of an application compromise. This is the closest operational analog to CapSeal’s broker mediation, and we adopt the same principle for the agent-to-gateway boundary. The crucial difference is the trust placed in the service itself. Vault and KMS hold the plaintext key in their own memory and assume both a trusted operator and trusted application logic; an operator with sufficient privilege—or a hosting provider running the managed instance—can in principle read the key material. CapSeal first tightens the application-side assumption (the “application” is now a prompt-steerable, externally connected agent that must be treated as adversarial), and operator-blind mediation then removes the operator-side assumption as well: the master secret exists only as an FHE ciphertext, so the entity performing derivations cannot read it even with full host access. This operator-side trust reduction is the key distinction from conventional secret managers, which trust the key-holding service. Table 2 positions CapSeal and operator-blind mediation against these and other agent-credential approaches along the security-capability axes; the corresponding quantitative latency comparison appears in Section 9.

Table 2. Security-capability positioning of agent-credential-mediation approaches. Columns: Op. blind (operator blind to secret), Agent adv. (secure under adversarial agent), Scope (per-request narrowing), Replay (anti-replay), Audit (tamper-evident log), Cost (L/M/H deployment complexity). Same-workload hot-path latency for FHE, trusted execution environment derivation service (TEE-DS), MPC, and operator-trusted CapSeal is reported quantitatively in the evaluation section.

System	Op. Blind	Agent adv.	Scope	Replay	Audit	Cost
Vault/cloud KMS	○	○	◐	◐	⬤	L–M
Local agent defense	○	◐	◐	○	◐	L
CapSeal (trusted)	○	⬤	⬤	⬤	⬤	M
CapSeal-OB	⬤	⬤	⬤	⬤	⬤	H
TEE-DS broker	◐	⬤	⬤	⬤	⬤	M–H
MPC/threshold	◐	⬤	⬤	⬤	⬤	H

⬤ provided; ◐ partial/conditional (hardware or honest-threshold assumption); ○ absent; Bold marks the proposed CapSeal-OB configuration. Cost: L/M/H deployment complexity.

2.4. LLM Agent Security

The threat model in Section 3.2 is grounded in a fast-growing literature on attacks against tool-integrated agents. Indirect prompt injection—in which adversarial content in retrieved data or tool output hijacks agent intent—has been demonstrated across realistic integrations [1,2] and is now systematically benchmarked: InjecAgent [25] measures susceptibility across many tool-use scenarios, and the Agent Security Bench [26] formalizes attacks and defenses over a broad agent attack surface, while recent reviews catalog the vulnerability and defense landscape [27,28]. Related work documents agent-specific poisoning of skills and retrieved context [3,4] and protocol-level exposure through MCP tool descriptions and tool-selection prompts [5,6,29]. Defenses to date concentrate on preserving tool-invocation integrity: structural input constraints [30], task-alignment enforcement [31], and provable guarantees against off-task actions [32]. These are complementary to our work but operate one layer above it—they aim to keep the agent on-task, whereas CapSeal assumes the agent may be successfully steered and instead removes the credential from the agent’s reach entirely, so that a compromised invocation yields a narrowly scoped, non-exportable handle rather than a reusable secret. We further observe that this arms race is accelerating on both sides: adversaries increasingly automate vulnerability discovery with coding agents, and LLM-based detection of cryptographic API misuse remains unreliable [33], which motivates an architectural, cryptographically enforced defense rather than a purely behavioral one.

2.5. Audit and Protocol Foundations

The accountability layer builds on Merkle-based append-only logs: Crosby and Wallach [9] introduced the efficient tamper-evident history structures that underpin Certificate Transparency [34] and, more recently, proposals for verifiable agent-execution histories [35]. CapSeal adapts these to record capability lifecycle events—issuance, blind derivation, invocation, and revocation—so that accountability spans the trust boundary even though derivation runs on the untrusted operator. The session- and request-binding machinery rests on standard protocol foundations: bearer-token semantics and their misuse risks [36], Transport Layer Security (TLS) and mutual TLS [37,38], channel binding [39], and JavaScript Object Notation (JSON) Type Definition for constraining request shape [40]. Finally, the Open Worldwide Application Security Project (OWASP) LLM Top 10 [41] and the MCP specification [42] frame the practitioner-facing attack surface that our design targets.

2.6. Trusted Execution Environments and Hardware-Assisted Confidential Computing

Trusted execution environments (TEEs) provide a complementary approach to cryptographic blindness by removing operator trust at the hardware level rather than the computation level. Major TEE technologies span a spectrum of isolation granularity and threat models: Intel Software Guard Extensions (SGX) [43] isolates application-level enclaves from the operating system (OS) and hypervisor; AMD Secure Encrypted Virtualization–Secure Nested Paging (SEV-SNP) [44] provides virtual machine (VM)-level memory encryption with reverse-map integrity protection; Intel Trust Domain Extensions (TDX) [45] extends VM-level isolation with attestation; Arm Confidential Compute Architecture (CCA) introduces hardware-enforced confidential realms at the page-table level; and AWS Nitro Enclaves [46] provide isolated compute environments carved from the parent Elastic Compute Cloud (EC2) instance without persistent storage or external network access.

TEEs have been applied to cloud secret management in a pattern that is operationally similar to our broker: the secret-handling logic runs inside an attested enclave, the parent host never sees the plaintext, and remote attestation provides the client with a cryptographic guarantee of the enclave’s identity and code. This hardware-enforced isolation offers near-native performance (typically single-digit microseconds of overhead per invocation at the hardware boundary) but depends on a hardware root of trust, correct attestation verification, and resistance to microarchitectural side-channel attacks—a different trust assumption from cryptographic blindness, where security relies solely on mathematical hardness. In CapSeal, TEEs serve two distinct roles defined in Section 7. The TEE Derivation Service (TEE-DS) replaces the homomorphic derivation path with an attested Nitro enclave that holds the plaintext master secret and performs capability-scoped derivation with 135 µs median hot-path latency (Section 9); it is the low-latency production alternative when hardware trust is acceptable. The TEE Key-Release Service (TEE-KRS) hardens the FHE pathway by binding release of the FHE client key to enclave attestation, so the host can orchestrate blind derivation without directly obtaining the key used to decrypt scoped artifacts. This positioning—TEE as an alternative lower-assurance boundary with better performance, versus FHE as the maximum-assurance boundary with cryptographic operator-blindness—is analyzed quantitatively in Section 9 (Table 14) and is one of CapSeal’s architectural contributions: the capability protocol is the common substrate across all three trust boundaries (FHE, TEE, and MPC), so the operator can choose the boundary that matches their threat model and performance budget.

2.7. Transciphering and FHE-Friendly Symmetric Primitives

A central cost challenge in fully homomorphic encryption is evaluating standard symmetric primitives: SHA-256 alone requires approximately 51,000 programmable bootstrapping operations under TFHE, making direct homomorphic evaluation of HMAC-SHA256 or AWS SigV4 prohibitively expensive for interactive workloads. The transciphering paradigm addresses this mismatch through a two-layer architecture: the plaintext secret is encrypted under a symmetric cipher specifically designed to minimize multiplicative complexity (the number of AND gates in its Boolean circuit representation, since each AND gate requires a programmable bootstrapping in TFHE, whereas XOR gates are noiseless additions), and the homomorphic evaluation decrypts this symmetric ciphertext into the FHE domain, recovering an encrypted secret without the operator ever seeing the plaintext. The symmetric key is held by the trusted party, and the FHE decryption key is similarly held by the trusted party, so the untrusted operator—which holds the symmetric ciphertext and the FHE-encrypted round keys but neither decryption key—cannot recover the secret.

The family of FHE-friendly symmetric primitives has grown substantially over the past decade. LowMC [47] was among the first block ciphers designed explicitly for MPC and FHE, minimizing AND gates through a partial S-box layer at the cost of a high round count. MiMC [48] achieves even lower multiplicative complexity by using the cube function $x^3$ over large prime fields, though its high algebraic degree requires careful parameter selection. Rasta [49] exploits randomly sampled affine layers to reduce structural attack surface, while Pasta [50] adopts a hybrid design that separates the symmetric encryption layer from the homomorphic evaluation—directly inspiring the two-layer architecture we employ. Elisabeth [51] represents a different design point: a filter-permutator construction that uses direct Torus Learning With Errors (TLWE) encryption for the non-linear layer, optimized specifically for TFHE Boolean gates. Niu et al. provide a comprehensive systematization of knowledge covering this entire landscape [52].

CapSeal’s transciphering design (Section 6) adopts the two-layer architecture for credential derivation: the master secret is encrypted under LowMC or Rasta with a symmetric key held by the tenant gateway, and the operator homomorphically decrypts the ciphertext before feeding the recovered secret into the keyed derivation circuit. Our artifact provides complete parameter sets, security analyses, and measured performance for the LowMC instantiation, and analytical projections for Rasta.We position this work as a feasibility demonstration rather than a complete industrial-grade construction: the 20-round LowMC transciphering pipeline takes approximately 2.6 h end-to-end in the current single-threaded prototype, which is appropriate for long-lived capability issuance where derivation runs once per capability. The full MAC and request-signing circuits under FHE remain future work, and the practical production path for per-request latency-sensitive workloads is TEE-DS (Section 7 and Section 9).

3. Background and Threat Model

3.1. Why Direct Secrets Fail in Agent Systems

Bearer credentials are unsafe when handed to a component that is both semantically steerable and externally connected. RFC 6750 explicitly warns that a bearer token grants access to any party that possesses it [36]. In agent systems, possession is not limited to memory reads: a prompted model can transform, summarize, paraphrase, or exfiltrate the same credential through tool parameters, logs, or follow-on instructions [28]. This risk is amplified by the agent tool plane: MCP and similar frameworks standardize tool discovery and invocation, but also expand the attack surface to tool descriptions, tool-choice prompts, and output handling [42]. The system must therefore defend not only against a malicious final tool invocation, but also against earlier steering that changes what tool the model chooses to call [29,30].

3.2. Adversary and Trust Assumptions

CapSeal targets the operator-untrusted setting directly: the broker runs on managed or hosted infrastructure that the tenant does not control, so the party that stores and operates on the secret is itself in the adversary’s reach. The goal is not to remove all trust from the system. Instead, CapSeal relocates trust away from the operator-controlled secret service and into a smaller, tenant-controlled gateway.

In-scope adversary capabilities.

• The adversary can influence agent prompts, retrieved context, or tool descriptions [31,32], and can cause the agent to request capabilities or submit crafted invocation payloads.
• The adversary includes the operator and the host running the secret service: it observes all storage, ciphertexts, evaluation keys, request bindings, timing of derivations, and the homomorphic derivation computation.
• The adversary may control remote services or network paths outside the gateway boundary, including HTTP status codes and output side effects.
• The adversary may replay stale network messages, race capability use against revocation, or attempt distributed replay across operator replicas.

Trusted computing base (TCB).

• The minimal TCB is a small tenant gateway that holds the FHE client (decryption) key and decrypts only narrowly-scoped, per-request artifacts—never the master secret [23,24]. The gateway is tenant-controlled and can be deployed on infrastructure with stronger administrative, network, and physical controls than the hosted operator service.
• The operating system enforces process isolation and Unix-domain-socket peer identity on the local agent↔gateway channel.
• The gateway maintains capability state, anti-replay state, revocation epochs, and the audit head. It is therefore trusted for policy enforcement, artifact opening, and final execution.

Guarantee. Under the IND-CPA security of the FHE scheme and the secrecy of the gateway’s client key, the untrusted operator and the agent are computationally unable to recover the master secret, which exists at the operator only as an FHE ciphertext. The gateway’s exposure is bounded to a single per-request artifact rather than the long-lived secret. As a degenerate case, co-locating a trusted deriver with the gateway recovers a conventional trusted-broker TCB—this is the operator-trusted comparison baseline in Section 8.

Out of scope. Local root or kernel compromise of the gateway; direct memory scraping or binary replacement of the gateway process; microarchitectural side channels below protocol-visible events; cross-host federation; and hardware-bound attestation are out of scope for the implemented prototype.

Multi-tenancy. The gateway is multi-tenant: it maintains per-tenant revocation state (blacklist, epoch, handle registry), enforces per-tenant rate limits, and passes tenant identity through to the operator for storage-isolated blind derivation. Each tenant provisions a distinct FHE key pair; the operator stores ciphertexts in a two-level map keyed by $(\mathit{tenant},\mathit{secret}\_\mathit{id})$, and $\mathsf{DeriveBlind}$ extracts the tenant from the request binding for storage lookup, ensuring the derived artifact is cryptographically bound to that tenant’s identity. Under the IND-CPA assumption, the operator cannot produce an artifact decryptable by tenant A’s gateway using tenant B’s ciphertext. The gateway’s $\mathsf{RateLimiter}$ caps per-tenant invocations per second, preventing a noisy or compromised tenant from exhausting operator compute resources. Per-tenant revocation isolation is verified by test: revoking a handle for tenant A does not affect tenant B’s epoch or handle registry. These mechanisms are implemented and tested in the prototype; cross-tenant audit-chain separation and per-tenant evaluation-key management at the operator remain architectural provisions for a production deployment.

Hardening path. Gateway compromise is the primary residual risk because the gateway holds the FHE client key and decrypts artifacts. Practical deployments should bind that key to a hardware security module (HSM) or trusted platform module (TPM), require TEE attestation for the gateway process when the tenant does not own the host, enforce short artifact lifetimes and revocation epochs, rate-limit derivations, and monitor the append-only audit log for anomalous capability use. These mechanisms complement rather than replace the FHE boundary.

4. System Design

CapSeal is a single, FHE-oriented design: one trusted tenant gateway mediates every credential-bearing action, and the master secret lives only as a fully homomorphic encryption (FHE) ciphertext held by an untrusted operator secret service that derives per-request credentials blindly, without ever decrypting it (Figure 1). The deriver behind the gateway is pluggable: the operator-blind FheDeriver is the design of interest, while a co-located trusted deriver recovers the conventional operator-trusted broker as a degenerate case (the comparison baseline of Section 8). Either way, the agent only ever expresses intent while the gateway performs execution, acting as a combined Policy Enforcement and Decision Point.

Figure 1. System architecture. The master secret leaves the tenant only as an FHE ciphertext held by the untrusted operator (amber), which blindly derives a per-request artifact and returns it still encrypted (dashed). The small trusted gateway (blue, inside the green TCB zone) holds the client key, decrypts only that scope-bound artifact, and executes through the reused executor. Solid arrows carry plaintext-side control; the dashed arrow carries ciphertext.

The design upholds four security objectives. G1 (Secret Non-disclosure): the agent never obtains the secret plaintext or any replayable equivalent; the master secret is never decrypted by the operator, and the gateway only decrypts a per-request derived artifact. G2 (Fine-grained Policy Enforcement): every invocation satisfies a multi-dimensional constraint check (host/path restrictions, command templates, quotas, step-up). G3 (Temporal, Contextual, and Revocation Binding): invocations are bound to sessions, channels, nonces, expiry times, and revocation epochs, so captured traffic and stale artifacts cannot be reused after state changes. G4 (Tamper-Evident Accountability): issuance, invocation (including the blind derivation), and revocation are recorded in an append-only, integrity-protected structure for asynchronous verification [9,34].

4.1. Preliminaries and Notation

We first fix the working vocabulary informally; these notions are made precise as an algorithm tuple, security games, and theorems in Section 5.

• Capability. A session-bound, unforgeable, non-exportable handle authorizing a single policy-evaluated action over a narrowly constrained scope—host, path, method, command template, expiry, and call quota. The agent holds only the handle, never the underlying secret, and can attenuate but never broaden the authority it conveys.
• Request binding. The canonical, deterministic encoding of one invocation against a capability scope,

  $$b=(\mathit{tenant},\mathit{handle},\mathit{host},\mathit{path},\mathit{method},\mathit{expiry},\mathit{nonce},\mathit{timestamp},\mathit{revocation}\mathit{epoch}).$$
  Canonicalization makes distinct invocations yield distinct bindings, so b uniquely identifies the authorized request.
• Blind derivation and capability artifact. Given the FHE-encrypted master secret $C_S$ and a binding b, blind derivation is the homomorphic evaluation $C_A={\mathsf{Eval}}_{\mathsf{evk}}(F_S,b)$ producing an encrypted capability artifact $A=F_S\left(b\right)$ without decrypting the secret. The artifact is the single-use, scope-bound credential the gateway injects after decrypting only $C_A$.
• Operator-blind mediation. A mediation architecture in which the party that stores the master secret and performs derivations holds only its FHE ciphertext and the evaluation key—never the client key—so that, under the IND-CPA security of the FHE scheme (Assumption 1), it cannot recover the secret even with full host access. The corresponding guarantee is Theorem 1.

4.2. Split-Broker Architecture

The gateway and operator are separated by the trust boundary of Section 3.2 (Figure 1):

• a tenant gateway (trusted, thin), which holds the FHE client key, and
• an operator secret service (untrusted, fat), which stores the master secret only as an FHE ciphertext together with the public evaluation (server) key.

For each request: (1) the agent submits an intent and payload to the gateway; (2) the gateway forms a request binding from the capability scope (Section 4.6) and asks the operator to derive a credential for it; (3) the operator homomorphically computes a per-request credential artifact over the encrypted secret and returns it—still encrypted, never having decrypted the master secret and holding no client key; (4) the gateway decrypts only this narrow artifact, injects it, and executes through the typed HTTP executor, returning only the result to the agent. Because the operator possesses neither the client key nor any decryption path, it is computationally blind to the master secret under the FHE scheme’s IND-CPA/Learning With Errors (LWE) security assumptions; because the gateway only ever decrypts a single-use, capability-scoped artifact, its blast radius is one request rather than the long-lived secret. Thus, the design relocates trust from the operator secret service to the tenant gateway instead of eliminating trust entirely. FHE is load-bearing here: it is what lets an untrusted party compute a keyed function of a secret it cannot read.

4.3. Protocol Lifecycle

To the agent, CapSeal appears as a set of standard tools mediated by an MCP/JavaScript Object Notation Remote Procedure Call (JSON-RPC) adapter over Unix Domain Sockets (UDS). The adapter maps MCP initialization and tool calls onto a narrower CapSeal lifecycle: (1) Registration (register) binds a session to a verified transport identity; (2) Capability Request (req_cap) declares an intent, capability type, and scope constraints; (3) Policy Evaluation grants, denies, or requires step-up; (4) Invocation (invoke) supplies a payload and anti-replay metadata; (5) Mediated Execution validates against session state and capability constraints, blind-derives and injects the credential, and executes; (6) Revocation (revoke) marks handles unusable and advances the session revocation epoch; and (7) Audit Export (audit.prove) emits cryptographic evidence for the append-only ledger (Table 3). The blind-derivation round trip that step (5) performs against the untrusted operator is detailed below. The scope field is the primary mechanism for authority narrowing: pinning, for example, an HTTP request to a POST on api.example.com and validating the body against a JSON Type Definition schema [40] ensures the agent cannot deviate from the pre-authorized intent.

Table 3. MCP/JSON-RPC mapping, security purpose, and primary enforcement checks. The last two rows are the gateway↔operator interface that realizes blind derivation.

MCP Surface	CapSeal Operation	Security Purpose	Primary Enforcement Checks
initialize	register	Session establishment	UDS peer credentials, transport binding, session nonce
tools/list	Filtered tool catalog	Discovery without secret enumeration	Generic tools only; no secret IDs, handles, or denied resources disclosed
tools/call	req_cap	Authority granting	Policy match, intent parsing, scope canonicalization, step-up requirements
tools/call	invoke	Mediated execution	Session validity, handle state, anti-replay, TTL, quota, revocation epoch, scope validation
tools/call	revoke	Authority rescission	State update, per-session blacklist insertion, epoch advance, cache invalidation
tools/call	audit.prove	Accountability	Consistency proof generation, chain verification
Gateway→operator	store_secret	Onboarding (cold)	Operator receives only $\mathrm{FHE}\left(\mathit{secret}\right)$ + server key; holds no client key
Gateway→operator	derive_blind	Blind credential derivation	Homomorphic eval over canonical binding; output is ciphertext only; no decrypt path at operator

The adapter implements the MCP [42] stdio transport (protocol version 2024-11-05) and supports three MCP methods: initialize, tools/list, and tools/call. It deliberately excludes resources/*, prompts/*, and notifications/* to minimize the information-disclosure surface; every additional MCP method is a potential side channel. Registration is lazy: the bridge establishes a UDS connection and calls capseal.register on the first tools/call rather than during initialize, so the handshake response never leaks session state. The broker extracts transport-level peer credentials (SO_PEERCRED on Linux, getpeereid on macOS) from the socket; the agent cannot self-assert its identity.

The four MCP tools carry JSON Schema inputSchema constraints fully specified in Table 3 and Table 4, with the protocol architecture visualized in Figure 2. Tool-description filtering is enforced through three mechanisms (Table 4): (i) descriptions use generic verbs—“Request a session-bound capability for an HTTP or SSH action” rather than listing tenant secret names; (ii) the secret_id field in capseal.req_cap’s inputSchema is a free-form string, not an enum, so tools/list never enumerates available secrets; and (iii) denials return a uniform policy_deny error code, drawn from a fixed five-code vocabulary (policy_deny, invalid_params, method_not_found, tool_not_found, mcp_transport_unavailable), so the agent cannot distinguish “resource does not exist” from “resource exists but policy hides it.” The full wire-format transcript for every lifecycle step is documented in the artifact file mcp-protocol-mapping.md.

Table 4. Tool-description filtering in the MCP tools/list response. ⬤ exposed (structural metadata only); ○ hidden (would otherwise reveal capability or secret existence). Every hidden row is a deliberate choice to keep tool discovery from becoming a side channel.

Information Category	Exposed	Mechanism
Broker name, protocol version	⬤	initialize metadata; architectural
Capability types	⬤	cap_type enum {HttpProxy, SshExec}
Tool argument schemas	⬤	JSON Schema inputSchema per tool
Step-up policies	⬤	enum {None, SoftwareConfirm}
Secret names/IDs	○	secret_id is free-form string, not an enum
Number of stored secrets	○	no listing/counting tool exists
Active capability handles	○	no list_capabilities; handles opaque
Policy rules	○	descriptions static, policy-agnostic
Session state	○	tools/list callable without a session
Which secrets were denied	○	uniform policy_deny; “hidden” ≡ “absent”
Audit log contents	○	requires explicit capseal.audit.prove

Figure 2. MCP protocol mapping. The agent drives the bridge over JSON-RPC 2.0 with three MCP methods (initialize, tools/list, tools/call), each mapped to narrower CapSeal operations; the bridge forwards typed capseal.* calls to the broker over a Unix-domain socket, and the gateway outsources blind derivation to the untrusted operator (dashed ciphertext return). Information hiding in tools/list and the uniform error-code vocabulary are detailed in Table 3 and Table 4.

Figure 3 details the blind-derivation round trip on the invoke path.

Figure 3. Request lifecycle and blind-derivation round trip on the invoke path. The gateway outsources a keyed derivation to the untrusted operator, which evaluates it homomorphically without decrypting; the gateway then opens only the scope-bound artifact and executes through the reused executor.

To satisfy G2 and G3, the gateway uses UDS peer-credential extraction to identify the calling process (preventing identity self-assertion), and an AntiReplay structure with a monotonically increasing sequence number, a unique nonce, and a millisecond timestamp. An invocation is accepted only if it is bound to an active session, references an active non-expired handle, passes freshness and nonce checks, matches the current revocation epoch, and falls within the call quota. A revoke operation inserts the handle into a per-session blacklist, advances the session revocation epoch, invalidates any cached encrypted artifact for that epoch, and appends a revocation record to the audit chain. Onboarding is a one-time store_secret that hands the operator only $\mathrm{FHE}\left(\mathit{secret}\right)$ and the server key; thereafter, every request uses derive_blind. The gateway records the derivation request, the artifact decryption, and the execution in the same append-only audit chain (G4), so accountability spans the trust boundary even though the derivation runs on the untrusted operator.

The default caching rule is fail-closed: the gateway does not cache plaintext artifacts. An operator may memoize an encrypted derivation result only for the exact canonical binding tuple $(\mathit{tenant},\mathit{handle},\mathit{host},\mathit{path},\mathit{method},\mathit{expiry},\mathit{nonce},\mathit{revocation}\_\mathit{epoch})$. Because the nonce and revocation epoch are part of that tuple, such memoization cannot authorize a second invocation or survive revocation; it only avoids repeating an identical homomorphic computation during retransmission recovery. The artifact tests and the revocation_cache_bench driver check this invariant directly: identical retransmission tuples reuse the same derived value, while a revocation-epoch change produces a different artifact and invalidates memoization.

4.4. Revocation Protocol

Revocation in CapSeal is an epoch-based, gateway-enforced protocol that renders a capability handle unusable and cryptographically invalidates any artifact derived under a prior epoch. Because the homomorphic derivation runs on the untrusted operator, the protocol is designed so that revocation takes effect at the gateway without requiring the operator to alter its behavior or learn whether a handle has been revoked.

The gateway maintains, per session, a revocation blacklist B, a monotonically increasing revocation epoch $e\in \mathbb{N}$, and a handle registry mapping each active handle to its constraints, expiry, quota, and issuance epoch. On $\mathsf{Revoke}(\mathit{handle},\sigma )$, the handle is inserted into B, the epoch advances ($e\leftarrow e+1$), all surviving handles are re-issued at the new epoch, prior-epoch operator-cached artifacts are cryptographically invalidated (the canonical binding tuple includes e), and an audit record is appended. On $\mathsf{Invoke}$, the gateway atomically checks handle registration, issuance-epoch freshness, blacklist membership, and epoch match before dispatching $\mathsf{DeriveBlind}$; any failure returns cap_revoked, stale_epoch, or stale_issuance and aborts before the expensive derivation round trip.

The revocation epoch is canonically encoded in the request binding b, so $A=F_S\left(b\right)$ changes with epoch, yielding three properties that make revocation robust against an untrusted operator: (i) the operator cannot serve stale artifacts—an artifact derived under epoch e fails $\mathsf{VerifyArtifact}$ at epoch $e+1$; (ii) the operator learns nothing about revocation, seeing only a changing integer in a fixed-format tuple; (iii) quota exhaustion complements revocation by denying further invocations without an explicit revoke. The race window between $\mathsf{Revoke}$ and $\mathsf{DeriveBlind}$ dispatch is bounded at 500 ns P95 (Section 8.5), $1.8\times {10}^7$ smaller than the ∼9 s FHE-mediated invoke. Revocation takes effect immediately at the gateway with no operator propagation required—a central design point when the operator is untrusted.

4.5. Blind Keyed Derivation

The operator evaluates a keyed derivation

$$\mathit{artifact}=\mathrm{PRF}\left(\mathit{master}\_\mathit{secret},\mathit{request}\_\mathit{binding}\right)$$

under FHE, where $\mathrm{PRF}$ denotes the secure keyed function used in the conditional cryptographic model (for example, a message authentication code such as HMAC-SHA256, or the request-signing function of a scheme such as AWS SigV4). The master secret is encrypted once at onboarding; thereafter, every derivation runs homomorphically on the operator and yields an encrypted artifact that only the gateway can open. After onboarding, neither the operator nor the gateway derivation path materializes the master secret in plaintext.

The implemented circuit uses 16 rounds of scalar multiplication (by odd binding-dependent constants) and word-wise XOR over 64-bit words. Multiplication by an odd constant modulo $2^{64}$ is a bijection with strong bit-level avalanche—the same ARX design principle behind ChaCha20 [53] and Salsa20 [54]—and 16 rounds over a 4-word (256-bit) state provide collision resistance and pseudorandomness with a comfortable security margin. The construction is not a full-strength MAC for production authentication (HMAC-SHA256, AWS SigV4, or SSH signing remains the production target and would be substantially more expensive under FHE; see Section 8.1 for a projection). However, its collision resistance and pseudorandomness satisfy the requirements for the capability-binding theorem in Section 5, so Theorem 2 applies to the implemented circuit at the 256-bit security level.

4.5.1. Scope of Cryptographic Derivation

A complete FHE construction for HMAC-SHA256, AWS SigV4, or SSH signing evaluated directly (without transciphering) would be a separate cryptographic engineering contribution: the direct homomorphic evaluation of SHA-256 alone requires approximately 51,000 programmable bootstrapping (PBS) operations, roughly $25\times$ the cost of the prototype circuit. Section 6 presents the transciphering approach that avoids this cost by using FHE-friendly symmetric ciphers (LowMC and Rasta) to bridge the plaintext secret into the FHE domain, together with concrete circuit constructions, parameter selections, security analyses, and measured benchmarks. The manuscript thus separates three claims: operator blindness depends on IND-CPA security of the FHE scheme; capability-binding security (Theorem 2) follows from the collision resistance and pseudorandomness of the 16-round multiplication-XOR construction for the prototype, and from the 128-bit symmetric security of LowMC/Rasta for the transciphering upgrade (Section 6); and the implemented TFHE-rs circuits—both the prototype and the LowMC transciphering pipeline—provide concrete, analyzable instances whose costs are reported in Section 8.1 and Section 6.3. Figure 4 summarizes the FHE blind-derivation circuit. For deployments that require production signing performance today and can accept hardware trust, the TEE-DS boundary in Section 9 is the practical alternative: the real MAC or request signer runs inside an attested enclave, rather than as a homomorphic circuit.

Figure 4. FHE blind-derivation circuit. The operator (amber zone) homomorphically evaluates $C_A={\mathsf{Eval}}_{\mathsf{evk}}(F_S,b)$ over the encrypted secret and the canonical binding b without decrypting either; only the gateway (blue) opens the ciphertext artifact. The prototype instantiates $F_S$ as a 16-round multiplication-XOR construction (collision-resistant and pseudorandom for capability binding, Theorem 2); a production deployment replaces it with HMAC-SHA256 or a request signer after transciphering (Section 6).

4.5.2. External Credential Acceptance Model

The artifact must be accepted by some external verifier before it can replace a service-native credential. In a production deployment, this verifier is either the upstream service’s native request-signature verifier (for example, an HMAC- or SigV4-style authorization scheme), or a future tenant-controlled and trusted verification shim, outside the untrusted operator boundary, that translates a capability-bound artifact into a service-native credential-bearing request. The current prototype does not implement either external verifier; its internal verify_artifact routine only exercises gateway-side scope and state checks. It therefore demonstrates the split-broker and FHE boundary mechanics, not drop-in compatibility with arbitrary bearer-token APIs.

4.6. Cryptographic Capability Scoping

The cryptographic capability-scoping model binds the derivation to the capability scope via a collision-resistant pseudorandom construction. The request binding canonically encodes the tenant identifier, capability handle, host, path, method, expiry, per-request nonce, and current revocation epoch. Under the 16-round multiplication-XOR circuit, an artifact derived for one scope does not authenticate a request outside that scope (collision resistance), and an adversary cannot predict the artifact for an unauthorized binding from observed artifacts (pseudorandomness). The prototype’s verification routine (verify_artifact) exercises the corresponding state checks by rejecting out-of-scope, replayed, expired, or stale-epoch requests. This is the cryptographic analog of network/host pinning (e.g., SSH known_hosts_pin): the untrusted operator cannot forge a wider-scope credential because doing so would require the master secret it never holds and a valid output for the canonical binding. The multiplication-XOR circuit provides the collision resistance and pseudorandomness needed for capability narrowing at the 256-bit security level; a production deployment may replace it with a full-strength MAC (HMAC-SHA256) for compatibility with existing request-signing schemes.

4.7. Capability Realizations

HTTP. The HTTP capability behaves as a constrained request constructor rather than a general-purpose proxy, which would still hand the agent broad routing power. CapSeal treats it as pre-authorized authority over a narrow method/host/path surface whose body can itself be semantically confined by a short request description: allowed method, host, path template, and body-schema reference. The narrowing path is layered: the executor validates method, host, and path, enforces payload-byte limits and header allowlists, rejects caller-supplied authorization headers, injects the blind-derived credential internally, and only then validates the body against the declared schema reference—moving beyond network mediation into semantic mediation. Schema failures deny before any credential use (fail-closed), and audit evidence records request structure, policy decisions, and response metadata without exposing the credential.

SSH. SSH uses a stricter, broker-exec realization because the threat surface is stronger: forwarding an SSH agent or exposing a reusable signing interface would leave the agent holding a powerful ambient channel. Instead the gateway executes a narrowly constrained remote action, and the agent never holds SSH key material or a forwarding-capable socket [55,56]. The capability constrains host and user, restricts execution to an approved command-prefix template with bounded arguments, forbids forwarding, and caps output size; the culminating control is host authenticity—the executor compares the presented host key against the capability’s known_hosts_pin.

Implementation. CapSeal is implemented in Rust as the capseal-broker crate, which dispatches to typed HTTP/SSH executors, maintains anti-replay session state, supports local and external (HTTP) policy engines with fail-closed timeouts, and an audit subsystem with a cryptographic chain and proof verification. The operator-blind path is realized by a pluggable BlindDeriver seam (Section 7), so the same gateway, executors, scoping, and audit serve both the operator-trusted and operator-blind deployments.

5. Formal Security Model

This section formalizes the two central claims of the operator-blind design: that an untrusted operator learns nothing computational about the master secret (operator blindness, Theorem 1), and that no party can forge an artifact accepted outside its authorized scope (capability binding, Theorem 2). Throughout, $\lambda$ is the security parameter, “PPT” abbreviates probabilistic polynomial-time, and a quantity is negligible if it is $o\left({\lambda }^{-c}\right)$ for every constant c.

Assumption 1

(IND-CPA-secure FHE). ${\Pi }_{\mathrm{FHE}}=(\mathsf{KeyGen},\mathsf{Enc},\mathsf{Eval},\mathsf{Dec})$ is a fully homomorphic encryption scheme that is IND-CPA secure: for every PPT adversary, the advantage ${\mathsf{Adv}}_{{\Pi }_{\mathrm{FHE}}}^{\mathrm{ind}-\mathrm{cpa}}\left(\lambda \right)$ in distinguishing encryptions of two equal-length messages is negligible. TFHE inherits this property from the hardness of (Ring-)LWE; the resulting guarantees are therefore computational and rely on standard lattice-hardness assumptions.

We write $F_K\left(·\right)$ for the keyed function used to derive request artifacts. The TFHE-rs prototype instantiates F as the 16-round multiplication-XOR construction of Section 4.5 (collision-resistant and pseudorandom at the 256-bit level via ARX-style mixing modulo $2^{64}$); a production deployment may instead instantiate it as a standardized MAC through the transciphering pipeline of Section 6 (128-bit symmetric security). Theorem 2 holds for any such secure-PRF/MAC instantiation, whereas Theorem 1 is independent of the choice of F.

We first fix the interface mediating between the trusted gateway and the untrusted operator.

Definition 1

(Operator-blind secret mediation scheme). An operator-blind secret mediation scheme is a tuple of PPT algorithms

$$(\mathsf{Setup},\mathsf{StoreSecret},\mathsf{Bind},\mathsf{DeriveBlind},\mathsf{OpenArtifact},\mathsf{VerifyArtifact},\mathsf{Revoke})$$

defined as follows:

• $\mathsf{Setup}\left(1^{\lambda }\right)\to (\mathsf{sk},\mathsf{evk})$ produces an FHE client key $\mathsf{sk}$ (held only by the gateway), a server/evaluation key $\mathsf{evk}$, and public parameters.
• $\mathsf{StoreSecret}(\mathsf{sk},S)\to C_S={\mathsf{Enc}}_{\mathsf{sk}}\left(S\right)$, with $(C_S,\mathsf{evk})$ stored at the operator.
• $\mathsf{Bind}(\mathit{tenant},\mathit{handle},\mathit{scope},n,t,e)\to b$ returns a canonical request binding b encoding tenant identity, capability handle, host, path, method, expiry, nonce n, timestamp t, and revocation epoch e.
• $\mathsf{DeriveBlind}(C_S,\mathsf{evk},b)\to C_A={\mathsf{Eval}}_{\mathsf{evk}}(F_S,b)$, a ciphertext encrypting the artifact $A=F_S\left(b\right)$, computed without $\mathsf{sk}$.
• $\mathsf{OpenArtifact}(\mathsf{sk},C_A)\to A={\mathsf{Dec}}_{\mathsf{sk}}\left(C_A\right)$, evaluated only at the gateway.
• $\mathsf{VerifyArtifact}(A,b,\sigma )\to \{0,1\}$ accepts iff A validates for the exact binding b and the live session state σ marks the handle active, non-expired, fresh, and in the current revocation epoch.
• $\mathsf{Revoke}(\mathit{handle},\sigma )$ inserts the handle into the gateway blacklist, advances the session revocation epoch, invalidates same-epoch cached ciphertexts, and appends an audit entry.

Definition 2

(Operator-blindness game ${\mathsf{Game}}^{\mathrm{ob}}$). The adversary $\mathcal{A}$ controls the operator. It receives $\mathsf{evk}$, chooses polynomially many bindings $b_i$, and observes $\mathsf{DeriveBlind}$ transcripts. It then submits two equal-length secrets $S_0,S_1$; the challenger samples $d\leftarrow \{0,1\}$, stores $C^{★}={\mathsf{Enc}}_{\mathsf{sk}}\left(S_d\right)$, and answers adaptive derivation queries with ciphertext artifacts computed from $C^{★}$. Finally $\mathcal{A}$ outputs a guess $d^{\prime }$, and its advantage is

$${\mathsf{Adv}}_{\mathcal{A}}^{\mathrm{ob}}\left(\lambda \right)=\left|Pr[d^{\prime }=d]-\frac{1}{2}\right|.$$

The game models a passive (honest-but-curious) operator with respect to FHE evaluation; active deviations are treated separately in Remark 1.

Theorem 1

(Computational operator blindness). Under Assumption 1, if the gateway client key $\mathsf{sk}$ is never revealed, then for every PPT operator adversary $\mathcal{A}$ in ${\mathsf{Game}}^{\mathrm{ob}}$ there exists a PPT IND-CPA adversary $\mathcal{B}$ such that

$${\mathsf{Adv}}_{\mathcal{A}}^{\mathrm{ob}}\left(\lambda \right)\le {\mathsf{Adv}}_{{\Pi }_{\mathrm{FHE}},\mathcal{B}}^{\mathrm{ind}-\mathrm{cpa}}\left(\lambda \right).$$

In particular, ${\mathsf{Adv}}_{\mathcal{A}}^{\mathrm{ob}}\left(\lambda \right)$ is negligible.

Proof. 

$\mathcal{B}$ embeds its IND-CPA challenge ciphertext as the stored secret $C^{★}$ in ${\mathsf{Game}}^{\mathrm{ob}}$. Every operator-visible value—$\mathsf{evk}$, the stored ciphertext, and each $\mathsf{DeriveBlind}$ transcript $C_A={\mathsf{Eval}}_{\mathsf{evk}}(F_{\left(·\right)},b)$—is a public, $\mathsf{sk}$-free transformation of ciphertexts and adversarially chosen bindings, so $\mathcal{B}$ produces all of them from its challenge without the client key. Hence $\mathcal{B}$ perfectly simulates $\mathcal{A}$’s view and forwards $\mathcal{A}$’s guess, distinguishing ${\mathsf{Enc}}_{\mathsf{sk}}\left(S_0\right)$ from ${\mathsf{Enc}}_{\mathsf{sk}}\left(S_1\right)$ with exactly $\mathcal{A}$’s advantage. The bound is computational: an unbounded adversary lies outside the FHE security model.    □

Remark 1

(Malicious operator behavior). FHE confidentiality alone does not guarantee that the operator returns the correct evaluated ciphertext. A malicious operator may return malformed ciphertexts, replay old artifacts, suppress derivations, or equivocate across requests. These are integrity and availability failures, not violations of Theorem 1. A production deployment should authenticate stored-ciphertext metadata, bind artifacts to the audit log, reject stale revocation epochs, and verify derivation correctness (via redundant or proof-carrying evaluation, or tenant-side spot checks)—or else treat incorrect derivations as detectable denial of service. The prototype catches stale-binding and replay failures through gateway state but does not provide general verifiable FHE.

Definition 3

(Capability-binding game ${\mathsf{Game}}^{\mathrm{bind}}$). The adversary controls the agent and the operator interface but not the gateway client key. It obtains artifacts for policy-approved bindings $b_1,\dots ,b_q$ and wins if it makes $\mathsf{VerifyArtifact}$ accept an artifact $A^{★}$ for a binding $b^{★}$ that was not authorized, is outside the requested scope, reuses a nonce, is expired, or uses a stale revocation epoch. Its advantage is ${\mathsf{Adv}}_{\mathcal{A}}^{\mathrm{bind}}\left(\lambda \right)=Pr\left[\mathcal{A}\mathrm{wins}\right]$.

Theorem 2

(Conditional capability binding). If F is instantiated as a secure PRF/MAC over canonical bindings and the gateway enforces freshness, expiry, and revocation state, then for every PPT adversary making q artifact queries in ${\mathsf{Game}}^{\mathrm{bind}}$,

$${\mathsf{Adv}}_{\mathcal{A}}^{\mathrm{bind}}\left(\lambda \right)\le {\mathsf{Adv}}_{F,\mathcal{C}}^{\mathrm{prf}}\left(\lambda \right)+{\displaystyle \frac{q}{2^{\lambda }}}+{\mathsf{Adv}}_{\mathcal{A}}^{\mathrm{state}}\left(\lambda \right),$$

where ${\mathsf{Adv}}_{\mathcal{A}}^{\mathrm{state}}$ bounds the probability that nonce, expiry, revocation, or canonicalization checks fail in the implementation.

Proof. 

Replace $F_S\left(·\right)$ by a truly random function $R\left(·\right)$; this step costs ${\mathsf{Adv}}_{F,\mathcal{C}}^{\mathrm{prf}}\left(\lambda \right)$. Under R, a fresh unauthorized binding $b^{★}$ has an artifact value independent of the q observed outputs, so the adversary forges it with probability at most $q/2^{\lambda }$ unless it replays an authorized artifact—which nonce freshness and revocation-epoch binding exclude—or exploits a gateway state or canonicalization error, captured by ${\mathsf{Adv}}_{\mathcal{A}}^{\mathrm{state}}$. Summing the three terms gives the bound. The prototype’s 16-round multiplication-XOR construction satisfies the collision-resistance and pseudorandomness premise at the 256-bit level.    □

6. Transciphering

The prototype keyed derivation of Section 4.5 uses a 16-round multiplication-XOR construction that provides collision resistance and pseudorandomness for capability binding (Theorem 2), but it is not a standardized, industrially vetted cryptographic scheme. A production deployment that requires industrial-grade authentication must instantiate the derivation with a cryptographically strong message authentication code such as HMAC-SHA256, or with a request-signing scheme such as AWS Signature V4 or SSH Ed25519 signing. However, evaluating a standard MAC directly under fully homomorphic encryption is prohibitively expensive: the SHA-256 compression function alone requires approximately 51,000 PBS operations when evaluated over TFHE Boolean gates, roughly $25\times$ the cost of the prototype circuit. Standard symmetric primitives are designed for plaintext central processing units (CPUs) where bitwise AND and XOR are equally fast; under FHE, AND gates (which require bootstrapping) dominate the cost while XOR operations are essentially free (noiseless addition of LWE ciphertexts).

Transciphering resolves this mismatch by introducing a hybrid two-layer approach that separates the symmetric encryption layer from the homomorphic evaluation layer. The master secret K is encrypted under an FHE-friendly block cipher—specifically designed to minimize AND gates—and stored at the operator as a symmetric ciphertext C. During credential derivation, the operator homomorphically decrypts C into the FHE domain, recovering an encryption of K without ever seeing K in the clear, then feeds $\left[K\right]$ into the existing derivation circuit. Neither layer alone exposes the secret at the operator: C is useless without the symmetric key L (held by the gateway), and the FHE-encrypted round keys and intermediate values are useless without the FHE client key (also held by the gateway). This upgrades the derivation’s security foundation from “collision-resistant ARX-style PRF over scalar multiplication modulo $2^{64}$” to “128-bit symmetric cipher (LowMC or Rasta) with IND-CPA-secure homomorphic decryption.” Figure 5 illustrates the two-layer construction.

Figure 5. Transciphering architecture. The tenant encrypts the master secret K under an FHE-friendly block cipher (LowMC or Rasta) with key L, and encrypts the round key bits under FHE. The untrusted operator stores the symmetric ciphertext C alongside FHE-encrypted round keys and plaintext linear-layer matrices/constants. During credential derivation, the operator homomorphically decrypts C into $\left[K\right]$ (the transciphering step), then feeds $\left[K\right]$ into the existing derivation circuit. The operator never sees K in the clear: C requires L to decrypt, and the FHE ciphertexts require the client key.

Both LowMC and Rasta are block ciphers from the family of FHE-friendly symmetric primitives designed explicitly to minimize multiplicative complexity—the number of AND gates in the Boolean circuit representation [48,52]. This is the critical metric for FHE evaluation cost because each AND gate requires a programmable bootstrapping operation, whereas XOR gates are noiseless additions in TFHE’s Boolean API. We present complete parameter sets, circuit constructions, and security analyses for both ciphers, and report measured performance for the LowMC instantiation, which is fully implemented in our artifact. Hybrid homomorphic encryption constructions such as Pasta [50] similarly separate symmetric encryption from homomorphic evaluation; our transciphering design adopts this two-layer architecture while targeting the specific credential-derivation circuit of Section 4.5, Section 4.6 and Section 4.7 and Section 5.

6.1. LowMC Construction

LowMC is a family of block ciphers designed for use in MPC, FHE, and zero-knowledge proof systems [47,48]. Its defining design principle is minimizing the number of AND gates per round at the cost of a larger number of rounds. The LowMC v3 structure applies a partial S-box layer (only the first $3m$ bits of the state), followed by a full-rank GF(2) linear layer, round constant addition, and round key addition.

• Parameter selection. Table 5 lists the chosen parameters and their security rationale.
  Table 5. LowMC parameters for the 32-byte master secret transciphering circuit.

  Parameter	Value	Rationale
  Block size n	256 bits	matches the 32-byte master secret
  Key size k	128 bits	NIST Category 1 (≥128-bit)
  S-boxes/round m	10	balances multiplicative depth vs. rounds
  Rounds r	20	exceeds interpolation/algebraic thresholds
  S-box	3-bit, degree 3	Three AND gates each (minimal)
  S-box formula	$a\oplus bc$, $a\oplus b\oplus ac$, $a\oplus b\oplus c\oplus ab$	bijection over ${\mathbb{F}}_2^3$
  AND gates/round	30	$3m=3\times 10$
  Total AND gates	600	$30\times 20$ rounds

The 3-bit S-box has algebraic degree 3, making it resistant to higher-order differential cryptanalysis. The partial S-box layer—applying the S-box to only the first $3m=30$ bits of the 256-bit state—is the key design trade-off: it reduces the number of AND gates at the cost of slower diffusion through the non-linear layer. The remaining 226 bits pass through the S-box layer unchanged.

• Circuit construction (encryption direction). Each of the 20 rounds applies four transformations to the 256-bit state:

• S-box layer: Apply the 3-bit S-box to the first $3m=30$ bits. Each S-box requires three AND gates (the $bc$, $ac$, and $ab$ product terms), totaling $3m=30$ AND gates per round.
• Linear layer: Multiply the state by a random invertible $256\times 256$ binary matrix over GF(2). Each output bit is the XOR of selected input bits. No multiplications—only XOR operations, which are free (noiseless) in TFHE Boolean gates.
• Round constant addition: XOR a round-dependent 256-bit constant to the state (free in FHE).
• Round key addition: XOR a round-dependent 256-bit key to the state. In the homomorphic circuit, these round key bits are FHE-encrypted as FheBool values, so XOR is still free.

• Homomorphic decryption. The operator evaluates decryption, which reverses the encryption steps. It receives the 32-byte LowMC ciphertext C in the clear (trivially encryptable as FheBool values), the round key bits encrypted under FHE ($256\times 20=5120$ FheBool values), and the plaintext round constants and inverse linear-layer matrices. Decryption proceeds in reverse order for $i=19,\dots ,0$: (1) XOR with the FHE-encrypted round key (free), (2) XOR with the plaintext round constant (free), (3) multiply by the pre-computed inverse GF(2) linear-layer matrix (free XORs), and (4) apply the inverse 3-bit S-box (three AND gates per S-box, 30 per round). The total cost is the same as encryption: 600 bootstrapping operations.

Security analysis. LowMC with $(n=256,k=128,m=10,r=20)$ provides 128-bit symmetric security against known cryptanalytic attacks:

• Interpolation attacks: Exploit the low algebraic degree of the S-box by constructing a polynomial representation of the cipher. For a degree-3 S-box, the maximum algebraic degree after r rounds is bounded by $min(3^r,256)$. At $r=20$, $3^{20}\gg 256$, so the cipher reaches full degree well before the final round, making polynomial interpolation infeasible.
• Higher-order differential attacks: Similarly bounded by the algebraic degree growth. With 20 rounds and a degree-3 S-box, the degree exceeds the block size, eliminating exploitable higher-order differentials.
• Algebraic attacks: Modeling the cipher as a system of polynomial equations over GF(2) yields a system with $256\times 20=5120$ non-linear equations. The large block size and 20-round depth make the equation system infeasible for Gröbner basis or XL-type solvers, which scale exponentially in the number of variables.
• Linear and differential cryptanalysis: The random invertible linear layers, generated deterministically from the 128-bit key via ChaCha20, provide strong diffusion: each output bit depends on every input bit after approximately two rounds. The wide-trail strategy ensures any differential or linear trail activates multiple S-boxes per round, and the 20-round depth provides a large security margin.

A production deployment should replace the ChaCha20-based key schedule seeding with HKDF-SHA256 for proper domain separation between the LowMC master key and the derived round material. The combined security of the transciphering construction rests on both layers: the adversary must either break the 128-bit LowMC key L (to decrypt C and recover K in the clear) or break the IND-CPA security of TFHE (to recover K from the homomorphic decryption transcript). Neither the operator—which holds C and the FHE-encrypted round keys but lacks L and the FHE client key—nor a passive network observer can recover K under these assumptions.

6.2. Rasta Construction

Rasta is an FHE-friendly block cipher family introduced by Dobraunig et al. [49] that takes a different design approach from LowMC. Instead of minimizing AND gates per round through a partial S-box, Rasta uses a full-state non-linear transformation (the $\chi$ function from Keccak) with algebraic degree 2, which is the lowest possible degree for a non-linear Boolean function. The key insight is that the algebraic degree grows exponentially with the number of rounds (deg $\le 2^r$), so fewer rounds are needed to reach full degree coverage. Rasta also exploits the fact that the affine layers can be freshly sampled from a CSPRNG for each encryption, making them effectively random and preventing structural cryptanalysis.

• Parameter selection. Table 6 lists the chosen parameters.
  Table 6. Rasta parameters for the 32-byte master secret transciphering circuit.

  Parameter	Value	Rationale
  Block size n	256 bits	Matches the 32-byte master secret
  Key size k	128 bits	NIST Category 1 symmetric security
  Rounds r	12	$2^{12}=4096\gg 256$; large margin
  S-box ($\chi$)	5-bit, degree 2	Keccak $\chi$; minimal non-linear degree
  $\chi$ blocks/round	51	$\lfloor 256/5\rfloor$ in parallel
  $\chi$ formula	$a\oplus \neg bc$, $b\oplus \neg cd$, $c\oplus \neg de$, $d\oplus \neg ea$, $e\oplus \neg ab$	Five AND gates per 5-bit block
  AND gates/round	255	$51\times 5$
  Total AND gates	3060	$255\times 12$ rounds

Rasta uses $5\times$ more AND gates than LowMC overall (3060 vs. 600), but requires only 12 rounds vs. 20, which yields a shallower multiplicative depth—the number of sequential AND layers that cannot be parallelized. This trade-off favors Rasta when bootstrapping latency is low but round depth dominates; it favors LowMC when bootstrapping is the dominant cost regardless of depth.

• Circuit construction (per round). Each of the 12 rounds applies four transformations:

• Key addition: XOR the 256-bit round key (FHE: free, as round keys are FHE-encrypted FheBool values).
• Constant addition: XOR a round-dependent 256-bit constant (FHE: free).
• Affine transformation: Multiply the state by a random invertible $256\times 256$ GF(2) matrix (FHE: free XORs).
• $\chi$ transformation: Apply $\chi (a,b,c,d,e)=(a\oplus \neg b·c,b\oplus \neg c·d,c\oplus \neg d·e,d\oplus \neg e·a,e\oplus \neg a·b)$ to 51 parallel 5-bit blocks. Each block requires five AND gates (the $\neg b·c$, $\neg c·d$, $\neg d·e$, $\neg e·a$, $\neg a·b$ product terms), totaling $51\times 5=255$ AND gates per round.

The $\chi$ function is degree-2 over GF(2), which is the minimum possible algebraic degree for any non-trivial non-linear Boolean function. The NOT operations ($\neg b$, $\neg c$, $\neg d$, $\neg e$, $\neg a$) are noiseless in TFHE Boolean gates (implemented as XOR with the constant 1).

• Homomorphic decryption. The structure is identical to LowMC: the operator trivial-encrypts the 32-byte Rasta ciphertext as FheBool values, then runs the inverse rounds. Each inverse round undoes the $\chi$ transformation (via the inverse ${\chi }^{-1}$, which has the same AND-gate complexity), the inverse affine transformation (using pre-computed inverse matrices), and the key/constant removal. The total cost is 3060 bootstraps.

• Security analysis. Rasta with $(n=256,k=128,r=12)$ provides 128-bit symmetric security:

• Algebraic degree attacks: The $\chi$ function has algebraic degree 2. After r rounds, the maximum algebraic degree is bounded by $2^r$. At $r=12$, $2^{12}=4096\gg 256$, so the cipher reaches full degree well before the final round. The minimum rounds needed for degree coverage are $r\ge \lceil {log}_2\left(256\right)\rceil =8$; 12 rounds provide a 4-round (50%) margin.
• Invariant subspace attacks: The random affine layers, freshly generated from the key for each encryption, make the probability of an exploitable invariant subspace negligible. Each $256\times 256$ binary matrix is generated via a CSPRNG and tested for invertibility; the set of matrices that admit a useful invariant subspace is exponentially small in the block size.
• Structural attacks: Unlike LowMC’s partial S-box, Rasta applies the $\chi$ transformation to the entire state uniformly, eliminating the structural asymmetry that partial S-box attacks exploit. All 256 state bits undergo identical non-linear treatment in every round.
• Differential and linear attacks: The random affine layers provide strong, key-dependent diffusion that makes it infeasible to find high-probability differential or linear trails. Each trail’s probability depends on the randomly-generated matrices, and the 12-round depth provides ample margin against trail clustering.

A notable structural advantage of Rasta over LowMC is its uniformity: the full state receives identical non-linear treatment each round, which simplifies the security argument and eliminates the need for separate analyses of the S-box-applied and S-box-bypassed portions of the state. The main disadvantage is the $5\times$ higher AND-gate count, which directly increases the FHE evaluation cost if bootstrapping is the bottleneck.

6.3. Comparative Analysis and Measured Performance

Table 7 compares the prototype PRF with the LowMC and Rasta transciphering constructions across the dimensions relevant to FHE-based credential derivation.

Table 7. Prototype PRF vs. transciphering constructions. Single-thread, Apple Silicon aarch64, tfhe 0.8, FheBool carrier. LowMC measured; Rasta analytical projection (no implementation). None of the three is a standardized cipher.

Property	Prototype PRF	LowMC	Rasta
Construction	16-round mult-XOR	SPN, 3-bit S-box	affine + $\chi$
AND/round	0 †	30	255
Rounds	16	20	12
Total AND ops	0 †	600	3060
Symmetric security	256-bit (coll.-res.)	128-bit	128-bit
Implemented	⬤	⬤	○
Transcipher cost	—	∼9.3 ks	∼40 s ‡
Round-key storage	—	∼81 MB	∼0.3 MB ‡

⬤ implemented; ○ not implemented. † the prototype stores the secret directly as FheUint64 and mixes via scalar multiplication (PBS-backed), so it has no Boolean AND gates. ‡ analytical projection.

The LowMC transciphering pipeline is fully implemented in the fhe-transcipher crate. Table 8 reports measured latency components on the same Apple Silicon aarch64 host used throughout the evaluation (release build, tfhe 0.8.7, FheBool carrier).

Table 8. LowMC transciphering pipeline: measured latency and storage. Release build, Apple Silicon aarch64, tfhe 0.8.7, FheBool, $(n,k,m,r)=(256,128,10,20)$. Total hot path extrapolated from 1-round measurement (full 20-round run ∼2.6 h, not completed).

Stage	Latency/Size
Cold path (one-time onboarding)
LowMC keygen (plaintext)	1.1 ms
LowMC encrypt (plaintext)	$<1$ µs
FHE key generation	542 ms
Encrypt round keys (per rnd)	12 ms
Hot path (per derivation)
Transcipher, 1 round	466 s
Bit pack → FheUint64	6.8 ms
Downstream derivation	8.3 s
Total, 20 rounds (est.)	9320 s
Storage
Symmetric ciphertext	32 B
Encrypted round keys	∼81 MB

• Interpretation. The transciphering step dominates the total derivation cost by three orders of magnitude relative to the downstream derivation circuit (8.3 s). The per-round cost of ∼466 s is primarily driven by the inverse GF(2) linear layer, which performs $N^2=65,536$ XOR operations over LWE ciphertexts with approximately 630 coefficients each; while each XOR is noiseless, the linear scan over 256 output bits each dependent on up to 256 input bits incurs a large constant factor in the TFHE-rs Boolean backend. This cost could be substantially reduced through batching (processing multiple bits per ciphertext word), graphics processing unit (GPU) acceleration (TFHE-rs CUDA backend), or by switching to a scheme with native packed linear algebra such as BGV/BFV.

The Rasta projection of ∼40 s per derivation is based on 3060 bootstraps at ∼13 ms per PBS (the measured single-thread PBS latency on this host). This is ∼230× faster than the measured LowMC path despite having $5\times$ more AND gates, because the LowMC bottleneck is not bootstrapping but the dense linear-layer XOR traversal. Rasta’s advantage is therefore architectural: the random affine layers are identical in complexity to LowMC’s linear layers, but the shallower depth (12 vs. 20 rounds) reduces the number of linear-layer traversals by 40%.

For context, both transciphering approaches are substantially more expensive than the prototype’s 16-round multiplication-XOR circuit (∼8 s, Section 8.1) because the prototype stores the secret directly as an FheUint64 ciphertext (no transciphering step) and uses scalar multiplication rather than Boolean AND gates. The additional cost buys industrial-grade symmetric security: the master secret benefits from both the 128-bit security of the block cipher and the IND-CPA security of TFHE. For latency-sensitive per-request derivation, the TEE-DS boundary (Section 9) remains the practical alternative; transciphering occupies the “maximum cryptographic assurance, maximum latency” corner of the trust-boundary map and is appropriate for long-lived capability issuance where the derivation runs once per capability rather than once per invocation.

The transient ∼81 MB of round key storage for LowMC is large but manageable for a small set of secrets (a few dozen). Rasta’s projected ∼0.3 MB is storage-efficient, making it preferable when many secrets must be stored at the operator.

7. Implementation

We realize the split-broker design of Section 4 as three Rust crates layered over the capseal-broker capability-mediation core introduced in this work, built on TFHE-rs [11,12] (tfhe 0.8, integer feature) with FheUint64 ciphertext words.

• fhe-derive defines the request binding and the blind-derivation circuit. The derivation is written once against a generic word trait and instantiated twice: over plaintext u64 as a reference oracle, and over tfhe::FheUint64 for homomorphic evaluation. Compiling the same algorithm for both carriers is what lets the test suite assert that the homomorphic result is bit-identical to the plaintext reference. The crate also provides verify_artifact, the capability-scope check of Section 4.6.
• fhe-secret-service is the untrusted operator. Its OperatorSecretService type stores ciphertexts and the server key only: by construction it has no client-key field and exposes no method that returns a plaintext secret—a structural blindness invariant enforced by the type, not merely by convention. Secrets are stored in a two-level map keyed by $(\mathit{tenant},\mathit{secret}\_\mathit{id})$, providing per-tenant storage isolation; $\mathsf{DeriveBlind}$ extracts the tenant from the request binding for cryptographic binding and storage lookup.
• tenant-gateway is the trusted, thin component. It holds the client key, requests a blind derivation, decrypts the scoped artifact, and—reusing the broker’s typed executors—validates constraints, injects the credential, and executes the call. The gateway is multi-tenant: it maintains per-tenant revocation state and enforces per-tenant rate limits via a RateLimiter with configurable invocation caps. Because the derivation consumes only the canonical request binding, the same gateway mediates both protocols: invoke_http over the HttpExecutor and invoke_ssh over the SshExecutor, with the artifact passed to the executor as a prototype credential label in the current implementation; production bearer-token, SigV4, HMAC, or SSH-signing compatibility would require a verifier-compatible construction. A BlindDeriver trait abstracts the derivation backend, with a PlaintextDeriver for fast functional tests and an FheDeriver for the homomorphic path.

TEE Roles and Nitro Implementation

The artifact uses Trusted Execution Environments in two distinct services, summarized in Table 9. We call them TEE-DS (TEE Derivation Service) and TEE-KRS (TEE Key-Release Service) throughout the implementation and result discussion. TEE-DS is a replacement execution boundary: the secret-handling derivation logic runs inside an attested enclave, giving near-native request latency under a hardware trust assumption. TEE-KRS is a key-custody hardening boundary: the FHE client key, which is the residual trusted object in CapSeal-OB, is released only to an attested enclave, so the parent host can orchestrate blind derivation without directly obtaining the key used to decrypt scoped artifacts.

Table 9. Two TEE services in the CapSeal artifact. TEE-DS is the low-latency production alternative to homomorphic derivation; TEE-KRS hardens the FHE gateway by binding key release to enclave attestation.

TEE Service	Protected Object	Implementation Path	Security Effect
TEE-DS: attested derivation service	plaintext master secret and request signer inside the enclave	tee-secret-service–mode aws-nitro listens on vsock; the parent gateway verifies a Nitro quote before issuing JSON-RPC derivation requests	Memory scraping and binary replacement by the parent OS require attestation bypass, PCR-policy acceptance failure, or a Nitro break
TEE-KRS: attested FHE key-release service	FHE client key used to decrypt scoped artifacts	enclave image file (EIF) build records PCRs; KMS policy/scripts bind release to the measured enclave; the one-shot TEE+FHE harness measures attestation, key-release setup, FHE derive, and total time	Host compromise does not directly expose the FHE client key; blast radius remains one scoped artifact per authorized request

TEE-DS. The TEE Derivation Service is a measured enclave service that holds the plaintext master secret or request-signing key only inside enclave memory. During startup, it generates a fresh service keypair and returns a hardware attestation document binding the gateway nonce, the service public key, and the enclave measurement. The gateway accepts the channel only when the quote verifies against the expected platform configuration register (PCR) policy and service-key binding. After that, each request is a vsock RPC: the gateway sends the canonical request binding, and the enclave returns the scoped artifact. Thus, TEE-DS protects the master secret and signing computation from the parent OS, while keeping the per-request hot path small.

TEE-KRS. The TEE Key-Release Service is a measured enclave service for protecting the FHE client key rather than replacing FHE evaluation. The enclave presents an attested recipient public key to the external key-release policy, such as KMS policy over Nitro PCRs. If the policy accepts the quote, the released client key is encrypted to the enclave recipient key, so only enclave code can decrypt it. The enclave then uses that key to decrypt scoped FHE artifacts without exposing the client key to the parent instance. Thus, TEE-KRS hardens the trusted gateway/key-custody side of CapSeal-OB.

TEE-DS: attested derivation service. The tee-secret-service crate has two execution modes. In –mode simulated, it preserves the local UDS test path used by the unit and integration tests. In –mode aws-nitro, the same JSON-RPC dispatcher is served over Nitro vsock, so UDS and vsock share one request implementation rather than two protocol-specific copies. At enclave startup, the service generates a fresh service/session keypair and obtains a Nitro attestation document from the Nitro Secure Module. The quote binds the gateway’s nonce to the service public key; the parent-side verifier checks the CBOR Object Signing and Encryption (COSE)/Concise Binary Object Representation (CBOR) attestation document, the nonce, the expected PCR0/PCR1/PCR2 values from the EIF build, and the service-key binding before accepting the channel. Only after this handshake does the gateway send derive requests over vsock. The hot path therefore contains the same capability binding and artifact derivation logic as the simulated service, while quote generation and verification are isolated as a startup cost.

TEE-KRS: attested key custody for TEE+FHE. For the hybrid deployment, the enclave is used not to replace FHE but to protect the FHE client key at the gateway boundary. The scripts in scripts/aws_nitro/ build the EIF, capture PCR measurements, create the development KMS key policy (alias/capseal-nitro-dev), launch the enclave, and run bench_tee_fhe_once.sh. The intended AWS path uses KMS attested release: KMS encrypts released key material to the enclave recipient described by the Nitro attestation document, and the parent instance never receives the plaintext client key. The current benchmark harness reports this as a one-trial deployment path rather than a statistical latency distribution: setup/attestation/key-release timing is cold-path work, while the FHE derivation cost remains the dominant per-invocation term. This service is therefore a hardening layer for CapSeal-OB’s remaining trusted key, whereas TEE-DS is the low-latency alternative when hardware trust is acceptable.

This structure keeps the trust boundary explicit in the code: the only component that can decrypt anything is the gateway, and the only thing it ever decrypts is a single-request artifact. To support review and archival reproducibility, the sanitized artifact for this revision includes the named Rust crates, the deterministic benchmark harnesses, and the OpenFHE scheme-comparison microbenchmark. It excludes live credentials, confidential task prompts, service endpoints, tenant-specific configuration, and raw operational logs. The artifact is therefore intended to reproduce the local protocol checks, operator-blind derivation benchmarks, and non-confidential aggregate measurements reported here; it is not a production secret-management release and does not include private deployment material.

8. Evaluation

We evaluate four questions: (i) the feasibility and boundary cost of operator-blind mediation, (ii) executor enforcement sanity checks for the implemented gateway, (iii) mediation overhead for the operator-trusted and operator-blind paths, and (iv) the latency, correctness, and race-window characteristics of the revocation protocol.

RQ1 (Operator-Blind Feasibility): Can the secret-bearing path run on untrusted operator infrastructure via FHE—deriving capability-scoped credentials without the operator ever decrypting the master secret—and what is the cost?

RQ2 (Executor Enforcement Sanity): In the implemented gateway, do typed executors reject the tested out-of-scope host/path, nonce-replay, and expiry cases?

RQ3 (Mediation Overhead): What overhead does CapSeal’s operator-trusted mediation add over direct local execution, and how does this compare with the operator-blind stand-in path?

RQ4 (Revocation Protocol Performance): What is the latency of the revocation operations, what overhead does the revocation check add to the invoke path, and how wide is the race window between check and derivation dispatch?

8.1. Operator-Blind Feasibility (RQ1)

Security argument. Operator blindness follows from Theorem 1 (reduction to IND-CPA security of TFHE) and capability binding from Theorem 2 (conditional on a secure PRF/MAC instantiation, satisfied at the 256-bit level by the 16-round multiplication-XOR construction). The prototype’s negative tests confirm that out-of-scope host/path, replayed nonces, and expired handles all fail verify_artifact.

Primary cost. The integrated gateway invoke round trip is ∼9 s median for both HTTP (8.97 s) and SSH (8.64 s) for CapSeal-OB. The two protocols agree to within run-to-run FHE noise because the blind derivation is protocol-independent (the same homomorphic evaluation over the canonical request binding).

Cost composition. Homomorphic derivation accounts for >99.99% of total latency: the plaintext-control gateway path measures <0.01 ms for both protocols, artifact decryption takes 53 μs, and one-time onboarding costs 605 ms key generation +6.4 ms secret encryption with 2.1 MB ciphertexts. The homomorphic result is bit-identical to the plaintext reference for both protocols.

Sensitivity. Single-host reruns with a 64-byte secret label (9.57 s derive-only) and a long binding label (9.47 s) confirm that binding and label variations are smaller than run-to-run FHE noise, so the conclusion stands that homomorphic evaluation dominates cost rather than any particular label or binding configuration. The 16-round multiplication-XOR design provides collision resistance and pseudorandomness for Theorem 2 (∼2048 PBS operations); a 6-round add-XOR construction would reduce PBS count to ∼768 at the cost of weaker mixing.

Production HMAC-SHA256 projection. To characterize the gap between the current prototype and a production-strength cryptographically secure instantiation, we estimate the cost of a production HMAC-SHA256 circuit under the same TFHE-rs backend. The current prototype evaluates a 16-round multiplication-XOR circuit over 4 × FheUint64 words, requiring approximately 2048 PBS operations (64 scalar-multiply + 64 XOR operations, ∼16 PBS each) at ∼13 ms per PBS on the measurement host. A real HMAC-SHA256 circuit operating on FheUint32 words would require: (i) SHA-256 block compression over 64 rounds of ${\Sigma }_0,{\Sigma }_1,\mathit{Ch},\mathit{Maj}$, and modular addition (∼176 PBS/round, ∼11,300 PBS/block), (ii) a 48-word message schedule (∼32 PBS/word, ∼1500 PBS), and (iii) HMAC outer hashing and key preparation. The total is approximately 51,000 PBS operations—a factor of ∼25× more work than the current prototype. Under the same single-thread TFHE-rs backend on the same Apple Silicon host, this projects to roughly 11 min per derivation; with 16-core CPU parallelism (Rayon) this drops to 40–60 s, and with a GPU backend (TFHE-rs CUDA feature) to 5–15 s. We report this projection to give a realistic cost envelope: the prototype’s derivation cost is a lower bound for the FHE evaluation cost, and a production MAC circuit would be one to two orders of magnitude slower depending on hardware acceleration. Full circuit design, parameter selection, and benchmarking of an FHE-native HMAC-SHA256 remain future work.

Answer to RQ1: Operator-blind mediation is feasible end-to-end as a split-broker boundary prototype for both HTTP and SSH executor paths, at an overhead of $\sim 1.7\times {10}^7$ over the plaintext path (measured ∼10 s blind derivation vs. a 593 ns plaintext reference, with ∼9 s end-to-end gateway invoke). This cost is the price of removing operator visibility of the master secret through a homomorphic derivation path, and it positions FHE as a high-cost primitive for the operator-untrusted-computation boundary rather than a default deployment choice (Section 9). We report the prototype’s cost without optimization to characterize that boundary honestly; production signing workloads that need near-native latency are better served by TEE-DS when hardware trust is acceptable.

8.2. Setup and Executor Enforcement (RQ2)

Setup. The reported security results are drawn from completed real_e2e runs (real local HTTP and SSH execution) for two direct-secret baselines (B1, B2) and CapSeal, across six scenarios spanning benign completion, literal credential-echo prompts, and unauthorized-use prompts over HTTP and SSH. The literal-echo metric records whether the agent output contains the credential in plaintext; it is a narrow proxy that does not, by itself, detect covert exfiltration through timing, error-code distinguishability, or output-format side channels. We therefore supplement the literal-echo table with a quantitative covert-channel probe (Section 8.3) that measures these surfaces at the gateway boundary. For latency we compare four systems under one unified external harness with identical tasks: a Direct (unmediated) baseline, two deterministic reconstructions of publicly described local-enforcement paths (S1, CaMeL-style; S2, ClawKeeper-style, both without live LLM or private services), and CapSeal. Each operator-trusted latency cell uses 10 rounds of 5 warmup and 50 measured trials ($n=500$); HTTP trials use fresh Connection: close sockets, and SSH trials use a steady-state OpenSSH ControlMaster connection, reporting post-setup command round-trip latency. The operator-blind CapSeal-OB rows were measured on the same Apple Silicon aarch64 host (Darwin 24.6.0, arm64, release build, tfhe 0.8.7, FheUint64 carrier over four words/32 bytes, 16-round multiplication-XOR derivation). Those rows report median and P95 over $n=7$ measured gateway invocations after one warmup call; because the homomorphic derivation cost is the dominant, low-variance term, we report robust order statistics rather than parametric mean/CI on this small sample. Raw per-trial data is persisted alongside the benchmark output, and exact invocation commands and environment configuration are documented in the artifact. The latency table reports median and P95 for all rows, with overhead computed relative to the direct local baseline for each protocol. We omit Wilson intervals for the credential-echo table because several cells are definitional consequences of whether the credential is ever exposed to the agent, and intervals on those 1.000/0.000 values would be misleading.

Enforcement (RQ2). On the real_e2e path, HTTP literal credential echo is 1.000 for both direct-secret baselines and 0.000 for CapSeal; SSH literal credential echo is 1.000 for the direct-secret baselines (which echo a test-only SSH private key PEM block when the credential-echo prompt is used) and 0.000 for CapSeal and CapSeal-OB, where the agent never receives SSH key material. Because the SSH and HTTP paths use distinct credential types (PEM private key vs. API key), the baselines now echo the protocol-appropriate credential, giving each protocol its own differential signal. The observed unauthorized-use rate is 0.000 for all systems in both protocols, with no successful out-of-scope authenticated action observed in this harness. These literal-echo and unauthorized-use sanity checks establish a floor but do not bound covert channels; the next subsection quantifies those residual surfaces.

8.3. Covert-Channel Probe (Supplement to RQ2)

The literal-echo metric answers only whether the credential appears verbatim in the agent-visible output. An adversary who controls the agent’s prompt could instead leak secrets through distinguishable error codes, timing side channels, or output formatting without ever echoing the credential string. We therefore instrument a covert_channel_probe (PlaintextDeriver, $n=200$ timing trials per case) that measures four covert-channel surfaces at the tenant-gateway boundary. The key findings are summarized here, with full quantitative results in Table 10:

Table 10. Covert-channel probe at the tenant-gateway boundary (PlaintextDeriver). Timing rows report Welch’s t over $n=200$ trials per case; significance at $p<0.05$ ($\left|t\right|>1.96$), with Cohen’s d for significant effects.

Probe	Comparison	t	Outcome
P1 — error-code distinguishability
Distinct codes	13 codes (7 HTTP + 6 SSH)	—	leaks scope
Secret-invariance	same code, different secrets	—	holds
P2 — timing uniformity
Across secrets	sk-master vs. sk-beta	$0.94$	not significant
Early vs. late reject	method_denied vs. schema_deny	$20.90$	significant ($d=2.09$)
P3 — output sanitization (6 patterns)
Verbatim secret/artifact	in summary/redacted_output	—	none
Prefix leak	injected-header prefix	—	6 chars
P4 — HTTP status (needs real upstream)
Simulated upstream	status = 200 always	—	N/A

• P1—Error-code distinguishability. The HTTP and SSH executors expose 13 distinct error codes at the gateway boundary, leaking scope information through constraint-violation distinguishability. The MCP adapter partially mitigates this by unifying broker errors to a fixed 5-code vocabulary, but the gateway surface remains distinguishable.

• P2—Timing uniformity. Different secrets produce indistinguishable timing ($t=0.94$, not significant), so the gateway leaks nothing about which secret is used. However, the depth at which a request is rejected is a structural timing channel: an early rejection (method_denied) is distinguishable from a late one (schema_deny) with a large effect size ($t=20.90$, Cohen’s $d=2.09$).

• P3—Output sanitization. No verbatim secret or derived artifact appears in output fields. A controlled 6-character redaction prefix leak exists in redacted_output (the redact_token_like_content function matches only the literal "sk-" pattern).

• P4—HTTP status side effects. Conditional on real upstream configuration; absent in the default simulated-200 configuration.

• Explicitly not covered. Remote collusion (cooperating external service injecting covert signals) and output-format channels (whitespace, JSON structure) are not systematically tested.

Table 11 reports the literal credential-echo and unauthorized-use results.

Table 11. Observed credential-echo and unauthorized-use rates (local harness, executor-level sanity checks). Covert-channel surfaces probed separately (Section 8.3). CapSeal-OB inherits executor enforcement and additionally hides the secret from the operator.

Protocol	System	Echo Rate	Unauthorized Rate	Operator Sees Secret
HTTP	B1	1.000	0.000	⬤
HTTP	B2	1.000	0.000	⬤
HTTP	CapSeal	0.000	0.000	⬤
HTTP	CapSeal-OB	0.000	0.000	○
SSH	B1	1.000	0.000	⬤
SSH	B2	1.000	0.000	⬤
SSH	CapSeal	0.000	0.000	⬤
SSH	CapSeal-OB	0.000	0.000	○

⬤ operator sees the plaintext secret; ○ operator does not see the plaintext secret.

8.4. Mediation Overhead (RQ3)

Benign completion is 1.000 (95% CI [0.963, 1.000]) for all systems across both protocols, indicating no observed availability degradation. Table 12 reports same-harness latency. Direct is the lower bound, as expected; among the operator-trusted mediated systems CapSeal has the lowest measured overhead among the deterministic local reconstructions in this harness (HTTP median overhead 0.149 ms vs. 0.232 and 0.736 ms for S1 and S2; SSH 0.208 ms vs. 0.325 and 0.951 ms), consistent with its narrower execution path. The operator-blind CapSeal-OB gateway appears in the same table at a different scale—its median is ∼9 s (HTTP 8.97 s, SSH 8.64 s), dominated by the homomorphic derivation (E1)—making explicit the price of moving the secret onto untrusted infrastructure.

Table 12. Same-harness latency (ms). Operator-trusted rows: $n=500$ (10 rounds × 50, 5 warmup). CapSeal-OB: measured via gw_bench (release, Apple Silicon aarch64, tfhe 0.8.7, FheUint64, 16-round mult-XOR; 1 warmup). Overhead is median minus the direct local baseline. CapSeal-OB one-time onboarding: 605 ms keygen + 6.4 ms encrypt; ciphertext 2.1 MB.

Protocol	System	n	Latency (ms)
			Median	P95	Overhead
HTTP	Direct	500	0.160	0.201	—
HTTP	S1	500	0.392	0.457	0.232
HTTP	S2	500	0.896	1.026	0.736
HTTP	CapSeal	500	0.309	0.351	0.149
SSH	Direct	500	7.470	9.954	—
SSH	S1	500	7.795	9.871	0.325
SSH	S2	500	8.421	10.442	0.951
SSH	CapSeal	500	7.678	10.500	0.208
Operator-untrusted (FHE blind derivation, $n=7$)
HTTP	CapSeal-OB	7	8970	9557	8970
SSH	CapSeal-OB	7	8638	8779	8630

8.5. Revocation Protocol Performance (RQ4)

The revocation protocol of Section 4.4 was benchmarked on the same Apple Silicon aarch64 host as the main evaluation (release build, $n=\mathrm{10,000}$ trials per metric). Table 13 reports the results.

Table 13. Revocation protocol micro-benchmarks ($n=\mathrm{10,000}$, release build, Apple Silicon aarch64). All latencies in ns.

Metric	Mean	SD	Median	P95
M1 revoke()	149.2	45.0	125.0	208.0
M2a check() only	43.8	18.8	42.0	83.0
M2b invoke + check	4367.1	1517.4	3834.0	7834.0
M3 epoch advance (correctness)	Verified—bit-inequality for all scope + nonce pairs
M4 check() + binding_for()	428.0	99.4	417.0	500.0

M1: blacklist insertion + epoch advance + handle re-issue. M2a: four hash-map lookups. M2b: integrated plaintext invoke path. M3: confirms epoch change invalidates artifacts. M4: critical-section window between check and derivation dispatch.

M1—Revocation latency. The revoke() operation (blacklist insertion + epoch advance + surviving-handle re-issue) completes in 125 ns median (208 ns P95). This is more than four orders of magnitude below the plaintext invoke latency and seven orders of magnitude below the FHE derivation time; revocation is therefore effectively free relative to the mediation path.

M2—Invoke-check overhead. The isolated check() call (four hash-map lookups: registration, issuance-epoch, blacklist, epoch-match) takes 42 ns median (83 ns P95). When integrated into the full plaintext invoke path, the check contributes ∼1.0% overhead (43.8 ns vs. 4367 ns median total). Against the ∼9 s FHE CapSeal-OB path, the check overhead is below $5\times {10}^{-9}$ of the total latency—entirely negligible.

M3—Cache-invalidation correctness. The benchmark confirms that (a) advancing the revocation epoch from one to two produces a bitwise-different artifact for the identical (tenant, scope, nonce) tuple; (b) retransmission under the same epoch reuses the identical artifact; and (c) after a gateway revoke() call, the gateway’s epoch-2 binding yields a different artifact than the epoch-1 binding for the same capability scope. These results validate the protocol invariant that revocation cryptographically invalidates all prior-epoch artifacts without operator involvement.

M4—Race-window bound. The critical section between check() returning Ok and binding_for() constructing the epoch-bearing binding completes in 417 ns median (500 ns P95). This is the window during which an in-flight invoke could execute under a just-revoked epoch. Relative to the ∼9 s FHE-mediated invoke, the race-window margin is $1.8\times {10}^7$; an adversary attempting to race revocation against invocation would need to land a nanosecond-precision attack on a seconds-scale operation. This window is an implementation artifact of the single-threaded prototype; a production deployment could further eliminate it by holding a mutex across the check-to-derivation sequence.

Answer to RQ4: The revocation protocol adds negligible overhead (∼125 ns revoke(), ∼1.0% of plaintext invoke, invisible against FHE), provides cryptographically sound cache invalidation through epoch binding, and has a race window bounded at 500 ns P95—$1.8\times {10}^7$ smaller than the FHE-mediated invoke. Revocation security does not depend on operator cooperation, making it suitable for the operator-untrusted setting.

8.6. Summary

Operator-blind mediation is feasible as a split-broker boundary-cost study and cleanly scoped to the operator-untrusted-computation boundary, at a large but honestly reported cost. With a co-located trusted deriver (the operator-trusted deployment), CapSeal eliminates observed HTTP literal credential echo relative to direct-secret baselines, shows zero unauthorized-use and perfect benign completion in the reported runs, and has the lowest measured overhead among the deterministic local reconstructions in this harness. The revocation protocol (Section 4.4) adds sub-microsecond operations that are invisible against the FHE derivation cost and requires no operator cooperation—a direct consequence of binding the revocation epoch into the homomorphically derived artifact.

9. Trust-Boundary Positioning

Operator-blind mediation (Section 4) removes operator trust at the level of computation: an untrusted party derives credentials it cannot read. This is one point on a broader trust-boundary map. A complementary approach removes operator trust at the level of hardware: executing the broker’s secret-handling and session-control logic inside an attested Trusted Execution Environment (TEE) such as Intel SGX [43] or AMD SEV-SNP [44] shields it from a compromised operating system or hypervisor and provides a hardware root of trust with much lower runtime overhead, but under a hardware-trust assumption. A third boundary—cross-organization federation, where no single party should hold the key—is naturally addressed by secure multi-party computation (MPC) and threshold signatures [57,58]. Both directions are compatible with the capability protocol, but they require separate implementations and evaluations. CapSeal’s capability model is the common substrate across all three.

Table 14 compares the approaches quantitatively for the same capability-scoped credential-derivation workload (one HTTP request, scoped artifact derivation, executor validation, credential injection). The FHE row reports the measured CapSeal-OB gateway path (Section 8.1, $n=7$, Apple Silicon aarch64). The TEE row is specifically TEE-DS, measured on AWS Nitro Enclaves using an m7i.xlarge instance in us-west-2: the parent gateway connects to the enclave over vsock, verifies a Nitro attestation document binding the session nonce and service public key, and then invokes the same derivation interface. For HTTP, the measured hot path is 134.9 µs median and 139.3 µs P95 over $n=50$ post-attestation invocations; the one-time attested startup is 6.713 ms. Table 15 separates TEE-DS attestation from the per-request path. TEE-KRS is not a separate replacement row because it composes with the FHE row by protecting the FHE client key; we therefore report it separately as the one-shot TEE+FHE deployment result below. The MPC row gives analytical estimates based on modern 2-party Elliptic Curve Digital Signature Algorithm (ECDSA) [57] and threshold HMAC protocols [58]; no MPC implementation exists in our artifact. HSM is included as a custody-only baseline: it can keep a key non-exportable, but it is not a general trusted-compute substrate for request-specific policy execution.

Table 14. Same-workload trust-boundary comparison for capability-scoped credential derivation. Measured rows report hot-path median/P95 latency; cold-path setup is separated when it is not paid per request. MPC and HSM rows are analytical/literature baselines, not implemented in this artifact.

Approach	Median/P95	Cold Path	Hot Path	Residual Trust	Hardware Assumption	Complexity
FHE (CapSeal-OB)	8.97 s/9.56 s	keygen 605 ms; encrypt 6.4 ms; ciphertext (CT) 2.1 MB	homomorphic derivation per invoke	gateway holds FHE client key; operator blind under LWE	no special hardware; client-key custody remains trusted	H
TEE-DS (Nitro)	134.9 µs/139.3 µs	attested startup 6.713 ms	vsock RPC after attestation	enclave code + Nitro hardware; parent OS untrusted	Nitro enclave hardware; attestation verifier and PCR policy	M–H
MPC/threshold	1–100 ms (est.)	distributed key setup 0.1–1 s	interactive protocol per invoke	honest-threshold parties; no single key holder	no special hardware; independent parties required	H
HSM/KMS	1–10 ms (est.)	key creation and policy binding	key-use API call	HSM/KMS operator and policy engine trusted; key custody only	managed or on-prem HSM; no general trusted compute	M

FHE: gw_bench, $n=7$, Apple Silicon aarch64. TEE-DS: tee_bench, $n=50$, AWS m7i.xlarge, vsock, HTTP workload. MPC and HSM are analytical rows and are not implemented. Complexity: L = single process, M = co-located service or managed hardware, H = specialized hardware, attestation, or multi-operator coordination.

Table 15. Measured AWS Nitro TEE-DS boundary costs. Attestation is paid once at the gateway–enclave boundary; the per-request hot path starts after the quote has been verified and the service key has been bound. Confidence intervals are 95% normal intervals over $n=50$ invocations.

Protocol	Quote Gen.	Verify	Attested Startup	Derive	Invoke Med.	Invoke Mean	P95
	ms				µs
HTTP	2.000	3.000	6.713	0.145	134.920	134.966 [133.826, 136.106]	139.262
SSH	1.000	3.000	4.804	0.134	146.021	146.418 [144.303, 148.532]	160.951

For TEE-DS, attestation adds 4.8–6.7 ms to gateway startup in the current Nitro run and approximately 0 ms to the per-request hot path, because quote generation and verification occur before the repeated invoke measurements. The measured quote-generation component is 1–2 ms and local quote verification is 3 ms; after that, credential derivation over vsock remains at 135–146 µs median.

For TEE-KRS, we also ran one EC2 x86_64 FHE sanity invocation after setup to exercise the TEE+FHE deployment path. The measured HTTP operator-blind FHE invocation was 779,369 ms ($n=1$), while the plaintext control invocation was 0.0427 ms. Because this is a single cold deployment trial on different hardware from Table 12, we report it only as a TEE-KRS deployment smoke result, not as a replacement for the $n=7$ FHE latency distribution. Table 16 summarizes the implementation-size asymmetry of the resulting trusted boundary.

Table 16. Trusted-computing-base asymmetry. Lines of code (LOC) are source-line counts from the artifact’s Rust paths (engineering scale, not proof size); the operator service and host OS sit outside the plaintext-secret boundary by design.

Component/Boundary	LOC	Share
Trusted gateway + TEE crate	2703	29%
Full implementation surface	9382	100%
Operator service/host OS	—	excluded

This asymmetry is the central deployment tradeoff. The trusted component is about 29% of the measured Rust implementation surface (2703/9382 LOC), and the operator-facing service and host OS lie outside the plaintext-secret boundary. Consequently, the most direct attacks on a conventional broker—memory-scraping the master key or replacing the signing binary—now require accepting a mismatched attestation, bypassing the verifier’s PCR/service-key binding, or breaking the TEE; the remaining blast radius is a single scoped artifact, not the long-lived master secret.

10. Limitations and Conclusions

Operator-blind mediation is a feasibility result, not a turnkey deployment, and several limitations are deliberate.

Gateway trust and hardening. The tenant gateway remains a small trusted component: it holds the FHE client key, enforces policy, maintains anti-replay state, and keeps the audit head. A gateway compromise would therefore expose decrypted artifacts and allow policy bypass. Three hardening paths mitigate this residual risk in different deployment regimes. (A) TEE-KRS attested key release runs the key-custody portion of the gateway inside an attested Trusted Execution Environment (e.g., Intel SGX/TDX, AMD SEV-SNP, or Arm CCA), sealing the FHE client key to the enclave’s hardware-bound identity; this combines FHE operator-blindness with TEE gateway integrity and has partial implementation support in our tee-secret-service crate. (B) Threshold FHE decryption splits the client key into t-of-n shares across independently administered gateway replicas using threshold FHE decryption protocols; an adversary must compromise t replicas simultaneously. (C) Audit-key separation moves the audit signing key to a separate append-only service, so a compromised gateway cannot forge historical audit entries. Rate-limiting derivations at the operator and monitoring the audit log for anomalous patterns further reduce the blast radius. These hardening measures complement rather than replace the FHE boundary.

Derivation strength and external acceptance. The scope-bound artifact is plaintext at the gateway for the duration of a single call. The prototype derivation is a 16-round multiplication-XOR construction that provides collision resistance and pseudorandomness for capability binding (Theorem 2); this revision does not claim an industrial-grade FHE implementation of HMAC-SHA256, AWS SigV4, or SSH signing. The current artifact is not accepted by existing third-party bearer-token APIs without an additional verifier or translation layer. A production deployment would require either (a) an external verification shim that re-derives the expected artifact from the observed request binding, validates it against the presented artifact, and injects the real credential for upstream forwarding, or (b) native artifact acceptance by the upstream service’s request-signing verifier (e.g., HMAC- or SigV4-style authorization). The translation-shim pattern is architecturally straightforward: a small trusted service holds the master secret, receives the artifact in a custom header, re-derives the expected value, and on match proxies the request with the real credential. The native-acceptance pattern works when the upstream service already verifies a signature or MAC over the request—the artifact is that MAC. Both patterns require per-service integration and are left to future engineering work.

Cost and measurement scope. A production FHE circuit for HMAC-SHA256, AWS SigV4, or SSH signing would require a separate circuit design, parameter analysis, implementation, and benchmark. The reported measurements cover the TFHE-rs stand-in and the OpenFHE CKKS/BGV/BFV arithmetic stand-in. The next-round artifact records sensitivity runs and raw outputs for secret-label and binding-size changes, but the FHE measurements remain single-host measurements on Apple Silicon. The homomorphic hot path is roughly seven orders of magnitude slower than plaintext.

Multi-tenancy and integration surface. The prototype implements multi-tenant isolation as described in Section 3.2: per-tenant revocation state, per-tenant rate limiting, and tenant-keyed secret storage at the operator are implemented and tested; cross-tenant audit-chain separation and per-tenant evaluation-key management at the operator remain architectural provisions for a production deployment. More broadly, local root compromise of the gateway stays out of scope, SSH broker-exec trades transparent agent forwarding for a cleaner boundary, and MCP integration is treated as an evolving experiment surface with explicit audit rather than a stable universal interface. The current artifact includes a deterministic MCP protocol probe (a Rust binary that spawns the broker and MCP stdio bridge, replays the full lifecycle transcript, and validates tool-call mapping, input-schema constraints, and denial-uniformity equivalence); a production MCP adapter with HTTP transport, session expiry, and resource/prompt surfaces remains an engineering task for follow-up work. The operator-blind security guarantees are transport-agnostic, so the MCP integration is a usability concern rather than a cryptographic one.

Positioning. We report these costs without optimization precisely to position FHE honestly relative to lighter-weight trust-boundary mechanisms such as TEE-DS, which is the production-oriented path when real signing performance and hardware trust are acceptable.

CapSeal reframes secret access for agents as a capability-mediated systems problem: by replacing direct bearer-secret exposure with session-bound capability handles, typed executors, policy checks, replay defense, an epoch-based revocation protocol, and tamper-evident auditing, it narrows the authority an untrusted agent can exercise even when behaviorally steerable. The paper’s central contribution preserves that narrowing when the broker runs on infrastructure the tenant does not trust: through operator-blind secret mediation, an untrusted operator homomorphically evaluates a derivation interface without ever decrypting the master secret. We place this on a formal footing—computational operator blindness reduced to FHE IND-CPA security, and conditional capability binding for any secure PRF/MAC—and show, through complete LowMC and Rasta transciphering constructions, how the prototype derivation can be upgraded to industrial-grade symmetric security. Our end-to-end prototype confirms the split-broker mechanics and quantifies their cost, cleanly scoping FHE to the operator-untrusted-computation boundary and situating it, against a measured attested-TEE derivation service and MPC/threshold signing, on a common capability substrate from which an operator can choose the trust boundary that matches its threat model and performance budget.