Conceptual Workflow

FHE for sensitive agent computation

A concrete end-to-end pattern for letting an agent evaluate a policy over sensitive inputs while the computation host sees ciphertext only. This page is an architectural explainer, not a live FHE API or contract.

Privacy boundary. This page describes a workflow; it does not perform FHE or decryption. Raw inputs, intermediate ciphertexts, the final plaintext result, and the FHE secret key never reach the agent host, KAIOS, or the verifier. The authorized data owner may decrypt the returned ciphertext locally; only intentionally published metadata and commitments cross the public boundary.

One Workflow

Eligibility evaluation without disclosure

A data owner wants an agent to decide whether a transaction policy is satisfied. The owner keeps the FHE secret key, while the agent evaluates the policy over encrypted transaction history and an encrypted approval threshold. The agent can return an encrypted decision, but cannot read the history, threshold, intermediate values, or decision.

Conceptual payloads

local_encrypt(...) → ciphertext
evaluate(..., ciphertext) → ciphertext
sign({ ciphertext_hash, policy_version, agent_identity, nonce,
       result_commitment, issued_at }) → signed_receipt

Data Flow

What moves, and what stays hidden

Step	Value crossing boundary	Visibility and purpose
01 · Key setup	Public key + evaluation material	Visible to the client and agent so encrypted evaluation can be prepared; the FHE secret key stays with the authorized decryptor.
02 · Local encode	`C(history)` + `C(threshold)`	Ciphertext only, so the transaction history and approval threshold cross the boundary without plaintext disclosure.
03 · Agent compute	Encrypted intermediate values	Remain ciphertext while the agent homomorphically evaluates eligibility; the agent host cannot inspect the intermediate values.
04 · Return result	`C(policy_result)`	The encrypted result returns to the authorized decryptor for local decryption; its plaintext never reaches the agent host, KAIOS, or verifier.
05 · Publish receipt	`ciphertext_hash`, `policy_version`, `agent_identity`, `nonce`, `result_commitment`, `issued_at`	Signed, non-sensitive metadata binds the computation without disclosing payloads, the secret key, or plaintext output.

Actors & Boundaries

FHE protects computation, not authorization

Data owner / decryptor

Generates the key pair, encrypts transaction history and the approval threshold locally, retains the secret key, and decrypts the result only when its authorization rules permit.

Agent host

Receives ciphertext and public evaluation material, runs the eligibility circuit, and returns ciphertext. It never receives raw values, intermediate plaintext, the final plaintext result, or the secret key.

KAIOS operations

Can carry operational identity, lifecycle, and signed-receipt metadata, but never receives the raw inputs, intermediate ciphertexts, final plaintext result, or FHE secret key.

Verifier

Checks identity, signatures, freshness, ciphertext hashes, commitments, and policy context. Verification does not require the secret key or decryption of the sensitive computation.

For the authorization context, see Agent Identity. For the operational agent and KAIOS context, see KAIOS. Those surfaces establish who may act; FHE keeps the computation payload private.

Verification Boundary

Bind the decision before it is sealed

A verifier should not infer authorization merely because an FHE evaluation completed. The receipt must bind the result to the exact encrypted inputs and the policy context that was authorized. A conceptual receipt can commit to the following values without including their plaintext contents:

ciphertext_hash — a digest of the encrypted input bundle
policy_version — the policy and circuit version evaluated
agent_identity — the authorized agent or capability reference
nonce — freshness material to prevent replay
result_commitment — a commitment to the encrypted result

Verification is separate from decryption. A verifier can validate the signature, identity, freshness, policy_version, ciphertext_hash, and result_commitment while the secret key and plaintext result remain with the authorized decryptor. See KAIOS receipt verification for the existing signed-receipt verification boundary.

Seal

A tamper-evident record, not a disclosure step

Sealing is the final audit action: sign the receipt that binds the ciphertext hash, policy version, agent identity, nonce, and result commitment. The resulting record makes the computation and policy decision tamper-evident without containing the sensitive payload or decrypting the result.

Signed receipt shape

seal({
  ciphertext_hash,
  policy_version,
  agent_identity,
  nonce,
  result_commitment,
  issued_at
}) → signed_receipt

The seal proves what was bound and when; it does not prove that the verifier is entitled to decrypt, and it does not turn ciphertext into plaintext. Keep decryption and key custody with the authorized data owner.

Takeaway

Privacy by construction

In this workflow, the agent does useful computation without receiving the sensitive data it computes over. The public trail is limited to operational metadata, commitments, and a signed seal. The raw inputs, intermediate values, and plaintext output are never exposed to the agent host, KAIOS, or the verifier.

Pair the computation boundary with agent identity, operational context from KAIOS, and the signed-receipt checks in verification docs when designing a production system.