FHE for sensitive agent computation

• Define the eligibility policy and version used by the example (eligibility-v1), including transaction history (history) and approval threshold (threshold).
• Assign an authorized data owner/decryptor who can generate the FHE key pair, encrypt inputs locally, retain the secret key, and decrypt the returned ciphertext locally.
• Provide an agent-side evaluator that can use the public key and evaluation material to run the policy on ciphertext and return ciphertext. The secret key stays with the owner.
• For the separate receipt path, prepare a signer and verifier plus the receipt context: agent identity, policy version, nonce, ciphertext hash, result commitment, and timestamp (issued_at). See Agent Identity for authorization context. The KAIOS quickstart describes its own signed-receipt flow; the synthetic FHE example is not a drop-in KAIOS envelope. See the full KAIOS receipt contract.

Sealed input

A sensitive value encrypted locally by the authorized owner before computation; this input seal is separate from the later signed receipt.

Encrypted computation

Policy evaluation performed over ciphertext, with intermediate values remaining encrypted.

Encrypted result

The policy output returned as ciphertext for the authorized owner to decrypt locally.

Verification

A separate signed-receipt check of signature, identity, freshness, ciphertext hash, policy version, and result commitment that does not decrypt the result.

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.

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

The request carries locally sealed inputs and policy context; the response returns the encrypted computation result with receipt metadata.

{
  "input_ciphertexts": {
    "history": "opaque:fhe-ciphertext-v1:synthetic-history-ciphertext",
    "threshold": "opaque:fhe-ciphertext-v1:synthetic-threshold-ciphertext"
  },
  "policy_version": "eligibility-v1",
  "agent_identity": "did:example:agent-eligibility-v1",
  "nonce": "example-nonce-01J4FHE7K2M9"
}

{
  "result_ciphertext": "opaque:fhe-ciphertext-v1:synthetic-result-ciphertext",
  "receipt": {
    "ciphertext_hash": "sha256:synthetic-ciphertext-hash",
    "policy_version": "eligibility-v1",
    "agent_identity": "did:example:agent-eligibility-v1",
    "nonce": "example-nonce-01J4FHE7K2M9",
    "result_commitment": "opaque:commitment-v1:synthetic-result-commitment",
    "issued_at": "2026-09-28T12:00:00Z"
  }
}

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.

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

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.

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.

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.