Reduce your trusted computing base to a minimum
Your trusted computing base (TCB) is everything that has to behave correctly for your data to stay safe: every piece of hardware and software, and every vendor and person, that could read your data or change what your systems do. If any one of them fails, gets breached, gets subpoenaed or goes rogue, you're exposed.
Security is mostly subtraction. Every party you remove from the TCB is a breach, an insider or a legal demand that can no longer reach you. Yaya Tech's job is to make that list as short as physics allows, and to prove what's left.
What a typical AI-enabled company trusts today
| Party in your TCB | What it can do | How we remove or contain it |
|---|---|---|
| LLM API provider (and its subprocessors) | Read every prompt, document and output, and retain them under its own policy | Open-weight models on your hardware, or models running inside attested enclaves |
| Cloud operator (staff, control plane) | Read VM memory and disks, and snapshot running workloads | Confidential VMs (AMD SEV-SNP, Intel TDX): memory is encrypted with keys the operator never sees |
| Hypervisor and host OS | Inspect or tamper with guests | Same: hardware isolation removes them from the trust path |
| SaaS vendors holding your data | Leak it in their breach and expose it to their admins | Replace the risky ones with small software you own and run |
| Your CI/CD and build pipeline | Ship a backdoored binary nobody wrote | Reproducible builds and signed provenance: the running measurement must match source you can audit |
| Your admins and ours | Read data and change production | No standing access; secrets released only to attested code; every action in an immutable log |
| Logging and observability vendors | See sensitive payloads, and alter or lose history | Zero-retention logging of content, plus tamper-evident logs you verify yourself |
| Third-party dependencies | Run arbitrary code inside your app | Pinned, reviewed, minimal dependencies, and an SBOM checked in CI |
| Us (Yaya Tech) | Anything you give us access to | You keep the keys, our access is scoped and logged, and the exit plan is built in |
What remains, and we'll say so
No system has an empty TCB. After a Yaya Tech deployment, what you still trust is typically:
- The silicon root of trust: the CPU and GPU vendors (AMD, Intel, NVIDIA), their firmware and their attestation keys
- Your own code, now small, audited and reproducibly built
- Your key holders, the people and HSMs that control your root keys
We also document what confidential computing does not protect against, so nobody finds out the hard way:
- Physical attacks on the host by someone with lab equipment and hands on the machine
- Side channels. They're mitigated by keeping firmware up to date and by the attestation policy, but they aren't impossible.
- Availability. A cloud can always switch you off, even if it can't read you. That's why we plan multi-site and on-prem fallbacks.
- GPU relay. Current GPU attestation is checked at boot and isn't bound to the connection between CPU and GPU, so we prefer designs that minimize it or verify it in more than one way.
- Metadata: traffic timing, request sizes and which endpoints you talk to
How we measure progress
Every audit starts with a TCB map: a list of every party with the power to read or change your data, and what each one would take to remove. Every build and managed deployment reports the TCB before and after. That number goes down, and you can check each line.