Of course, we can't support Claude or Grok as they are closed source, but there is no incentive for companies that need your data to train the next generation of models to allow for private inference. One day...

>that open models are in the ballpark of the best commercial models

This is basically true for certain tasks. As an example, chat interfaces are not well poised to take advantage of higher model intelligence than what the best open source models already provide. But coding harnesses still benefit from greater model intelligence and even more so, the reinforcement learning that tightly interlinks the provider's coding harness (claude-code, codex) with the model's tool calling interfaces is another reason for discrepancy in effectiveness even when controlled for model intelligence. The opencode founder (open source coding harness that supports different model providers) was recently complaining about the challenges making the harness work well with different providers: https://x.com/thdxr/status/2053290393727324313

A useful framing over “local vs cloud AI” can be split along two axes: does the task touch private data, and does it need frontier intelligence? You can use frontier models for developing the software (doesn’t touch data), but open-source models running locally for ops: maintenance, debugging and monitoring (touches data). If you need to fall back to frontier intelligence at some point for a particularly hard to resolve problem, you can still rely on local models for pre-transforming and filtering input in a way that's privacy-preserving or satisfies some constraint before it’s sent off to the cloud for processing. OpenAI's privacy filter is a good example of a model that can be used to mask PII and secrets and that can run locally: https://openai.com/index/introducing-openai-privacy-filter/, before sending any data externally for processing.

Another framing for local vs frontier closed which the article mentions is whether the task saturates model capability. With certain tasks like PDF processing or voice or summarization, adding more intelligence isn't necessarily useful. Arguably we've approached that point for chat interfaces already with frontier open-source models. But for coding and ops through well structured tool use inside a coding capable harness, we're still a ways away.

Tangentially, a contrarian take here is that AI can actually enable more privacy preserving software if you’re so inclined. You can just build personalized software and it lowers the barrier to entry and the effort required to self host. SaaS complexity often comes from scaling and supporting features for all types of customers, and if you're building software for personal use, you don't need all that additional complexity. Additionally, foundational and infra software that is harder to vibecode with AI is often already open source.

But we created Tinfoil because not everyone has that capability especially when it comes to larger models, and it still doesn’t solve for the situation where you’re building a service for your end user and you want to lock yourself out of accessing their data. In those cases, this is the second best thing you can do.

The technical walkthrough section on this blog that we co-wrote with one of our customers walks through the various attack surfaces: https://www.workshoplabs.ai/blog/private-post-training

We weave in many mitigations against attacks, but it depends on what class of attack it is.

If there are specific attacks you are concerned about, happy to provide an answer if it’s something we can address or not.

We try to add models selectively as we have to be mindful about our compute allocation. Is there a specific reason why you need those two models (and our models such as Kimi K2.6, GLM 5.1, Deepseek V4 Pro, Gemma 4 amongst others) don’t suffice for your use case?

Feel free to email me at tanya@tinfoil.sh and happy to continue the conversation there.

In turn, that attests the model enclaves, for instance, see https://github.com/tinfoilsh/confidential-deepseek-v4-pro. The model repo/release that the model router attests is included in the attestation config, which creates a chain of trust.

Also see https://docs.tinfoil.sh/verification/attestation-architectur...

I wrote a blog about this: https://tanyaverma.sh/2026/03/01/nowhere-to-hide.html

I've been hearing amazing things about Flash, I should give it a try.

Disclaimer I'm the cofounder. This works by running the model inside a secure enclave (using NVIDIA confidential computing) and verifying the open source code running inside the enclave matches the runtime attestation. The docs walk you through the verification process: https://docs.tinfoil.sh/verification/verification-in-tinfoil

Disclaimer I'm the cofounder, only recommending it because it's legitimately the right shape for your problem. The idea is that the model runs inside a secure enclave (using NVIDIA confidential computing), and the enclave code is open source and is verified via remote attestation upon connection: https://docs.tinfoil.sh/verification/verification-in-tinfoil

Comments URL: https://news.ycombinator.com/item?id=47734444

Points: 4

# Comments: 0

This was the first of several articles coming out of Google: https://blog.google/innovation-and-ai/technology/safety-secu...

And the timeline for web migration is 2027 Q1: https://security.googleblog.com/2026/02/cultivating-robust-a...

And this was Sophie Schmieg’s talk at a cryptography conference this month (they lead PQC migration efforts at Google) tracking migration efforts and urging folks to prioritize signature migrations in lieu of accelerated quantum timelines: https://westerbaan.name/~bas/rwpqc2026/sophie.pdf

Also around to answer any questions!

So we do the next best thing. We decide to trust Github and rely on Github Actions to faithfully execute the build pipeline. We also make sure to pin all images and dependencies.

Then, verification involves a three part approach. Disclaimer: I'm the cofounder of Tinfoil: https://tinfoil.sh/, we also run inference inside secure enclaves. So I'll explain this as we do it.

First, you open source the code that's running in the enclave, and pin a commitment to it to a transparency log (in our case, Sigstore).

Then, when a client connects to the server (that's running in the enclave), the enclave computes the measurement of its current state and returns that to the client. This process is called remote attestation.

The client then fetches the pinned measurements from Sigstore and compares it against the fetched measurements from the enclave. This guarantees that the code running in the enclave is the same as the code that was committed to publicly.

So if someone claimed they were only analyzing aggregated metrics, they could not suddenly start analyzing individual request metrics because the code would change -> hash changes -> verification fails.