Encompute

Encompute is a compiler and trust runtime for confidential AI and cross-organization computation.

Organizations can compute, train and collaborate over sensitive data without centralizing the underlying records or surrendering control of their keys. Encompute combines confidential computation with purpose-bound authorization, privacy controls, governed release, lineage and auditable evidence.

The execution layer can use fully homomorphic encryption (FHE), secure aggregation, differential privacy and attested confidential computing, depending on the workload. The security boundary is not the application or the AI model: authorization and release decisions are enforced by Encompute and by organization-controlled key brokers.

Security update: use v0.3.3. The current supported release is v0.3.3. Security advisory GHSA-rm8x-939m-3fgp (medium) covers privacy-budget accounting and governance-state rollback protection in the control plane. Per the advisory, encompute-control >= 0.3.0-rc.1, < 0.3.1 is affected (the supported stable version affected is 0.3.0, and the four 0.3.0 release candidates share the flaws); the fixed version is 0.3.3. v0.3.1 and v0.3.2 were incomplete, unsupported release attempts: they have no completed GitHub release or signed release artifacts, and their container image tags must not be used. Upgrade to v0.3.3.

main is unreleased development (version 0.4.0-rc.1 in the source; there is no v0.4.* tag or release). Its control-plane security work is still in progress and it is not production-ready.

You write ordinary Python and mark which values are secret. Encompute encrypts them, runs the program on a machine that never holds the key, and checks the answer against plain Python.

Who it is for

• AI and application teams that need useful answers from sensitive data without exposing the underlying records to every component in the workflow.
• Security, privacy and compliance teams that need enforceable controls over purpose, authorization, key release, privacy loss and result release.
• Organizations collaborating across trust boundaries that need to compute or train together while retaining ownership, key custody and independent authorization.
• Regulated and sovereign environments that require auditable evidence of what was authorized, computed and released.

What makes Encompute different

Most privacy-preserving computation libraries answer one question: how do I compute on encrypted data? Encompute also answers:

• Who authorized this computation?
• For what purpose?
• Over which exact assets and versions?
• Which organization controls each key?
• What information may be released?
• What privacy budget was consumed?
• What evidence remains afterward?

The cryptographic backend is one part of the system. Encompute's trust runtime connects policy, authorization, confidential execution, controlled release, lineage and evidence.

What it guarantees, and what it does not

It guarantees, for the supported features (support matrix):

• The machine that does the computing never gets the secret key. It sees encrypted values, not your data.
• Unsafe programs are refused when they are compiled: branching on a secret, printing it, or a number that could overflow.
• Encrypted results are checked against plain Python, within a precision you declare.
• Between organizations, rules about who may learn what are checked by the compiler. Keys can be released only to a workload that proves what it is (experimental on Google Confidential Space).

It does not:

• Hide the program. The computing machine sees the operations, public constants, shapes, declared ranges, timing and data sizes.
• Prove that the computing machine did the work honestly. A receipt is a signed claim. Proofs exist only in a research build.
• Protect data after you decrypt it and share it.
• Come with a proof of security for the whole system. The known limitations list the rest. Read them before you use real data.
• Run fast. Encrypted computation costs far more than plain computation (performance).

Terms used here. FHE (fully homomorphic encryption): computing on encrypted data. CKKS: an FHE scheme for real numbers, correct to a declared precision. SecAgg (secure aggregation): parties add their private vectors so that only the sum is revealed. DP (differential privacy): added noise that limits what published results reveal about any one person. TEE (trusted execution environment): hardware that can prove what software it runs.

Try it in five minutes

You need Python 3.11 or later. This installs the released package (macOS on Apple silicon shown; the v0.3.3 release has a wheel for Linux x86_64 too; verify what you download) and runs the starter, example 00. The clone supplies the example script (it is on main; the v0.3.3 tag does not have it); the package you run is the v0.3.3 wheel:

git clone https://github.com/BAder82t/Encompute && cd Encompute
python3 -m venv .hello && . .hello/bin/activate
gh release download v0.3.3 -R BAder82t/Encompute -p 'encompute-0.3.3-cp311-abi3-macosx_11_0_arm64.whl'
pip install ./encompute-0.3.3-cp311-abi3-macosx_11_0_arm64.whl
examples/00_hello_encrypted/run.sh

Real output from that wheel (sizes and timings vary from run to run; the last step, three refusals of unsafe actions, is left out here):

== Score four private test results without revealing them ==
Step 1. The clinic's private data (the evaluator never sees this)
  panel = [0.62, 0.18, 0.91, 0.4]

Step 2. What the risk service is told: the program, not the data
  scheme    CKKS (approximate), 128-bit classical
  the evaluator can see:
    - program structure (operations and their order)
    - public constants (weights, coefficients)
    - input and output shapes
    - declared input ranges
  evaluator receives the secret key: no

Step 3. Encrypt, compute while encrypted, decrypt
  (the sizes below come from a second encrypted run with fresh keys)
  the clinic made a secret key and public keys, and encrypted the panel
  the evaluator received 1,574,609 bytes of ciphertext
    and 18,882,955 bytes of evaluation keys (no secret key)
  the evaluator computed sigmoid(weights . panel + bias) on ciphertext
  it returned 526,087 bytes: one ciphertext only the clinic can open
  the clinic decrypted it (timings in ms: keygen 460, encrypt 21, evaluate 94, decrypt 11)

Step 4. Check the answer against plain Python
  plain result      0.77171
  encrypted result  0.77161
  difference        0.00010  (allowed: 0.00100)

A clinic's four private numbers were encrypted, scored by a service that never saw them in the clear, and decrypted. The scoring side held no secret key. The example's README explains each step and what it does not show.

Pick your path

You are	Read	Then run
Developer	Developer path	01, 02
Security or compliance lead	Security and compliance path	06, 13
Institution deploying it	Institution path	11, 12

Every capability has a runnable example; examples/ has a table by goal. All topics are in the guide: confidentiality policies, secure aggregation, differential privacy, planner, confidential fine-tuning, trust graph, attested key release, verification, remote evaluation and building from source.

Status and support

Stable: v0.3.3, the current supported release. It includes the confidential-computation compiler and runtime, OpenFHE-backed encrypted execution, secure aggregation, differential privacy, trust and evidence machinery, confidential fine-tuning, the documented 0.3 support surface, and the control-plane fixes described in the security advisory GHSA-rm8x-939m-3fgp. The documentation that matches it is at the v0.3.3 tag (for example its deployment guide and release notes). v0.3.0 and the 0.3.0 release candidates are affected by the advisory; v0.3.1 and v0.3.2 are not supported (see the notice at the top).

Development (main, unreleased): additionally contains work in progress for governed cross-organization computation: purpose-bound authorization, organization-controlled governance keys, revocation, multi-owner key custody, governance lineage and event logging, privacy-budget governance, and hardened production deployment infrastructure. None of it is part of v0.3.3. Its security remediation is not finished, so do not treat it as a stable or production-ready release, and do not follow its 0.4 migration material on a 0.3.x deployment. Pages in this repository that describe it say so.

What is supported, what is a subset, and what is experimental, research only or unsupported is in the support matrix, with a short summary. Also: known limitations, release notes for v0.3.3, changelog, threat model, security findings, repository layout and roadmap.

Security: see the advisory GHSA-rm8x-939m-3fgp and SECURITY.md (reporting and supported versions). The advisory credits the maintainers' internal review, which was AI-assisted and is not an independent audit. Internal reviews, assurance suites and test matrices in this repository are not independent external audits. Earlier documents describe a review of 0.3.0-rc.3 as independent or external; those descriptions are kept as history and have not been re-verified. Findings from earlier reviews are kept in docs/security-findings.md. v0.3.3 has documented residual limits: see KNOWN_LIMITATIONS.md and the advisory's "What 0.3.3 does not fix".

License

AGPL-3.0-only, with commercial licenses available: see LICENSING.md. Encompute statically links OpenFHE (BSD 2-Clause); research builds with the research-tfhe-rs feature also link TFHE-rs (BSD-3-Clause-Clear, plus Zama's patent terms); see THIRD_PARTY_NOTICES.md.