This is pretty cool, nice project. Can you expand on what threat model this combats?

Also, does the replace op happen only for specific fields in HTTP, or for every matching string in the request? I can imagine the latter if you want to support non-standard authentications methods, though there's always the edge case where the secret string placeholder is not used as a secret and should not be replaced.

▲

neo2006 4 hours ago | parent | next [-]

The main threat model is application leaking secrets: - Internet facing app that could potentially be hacked and bad actor exfiltrating secrets - AI agent that can exfiltrate secrets through prompt injection for example or context poisoning - The general use case where a secret can be for example inject by mistake in logs for instance

▲

__turbobrew__ 3 hours ago | parent [-]

How does this compare with TPUs? Can you not have secrets in the TPU which cannot be accessed directly by apps, solving this threat vector? I get that you want compatibility with popular libraries, but I wonder if the actual solution is to use hardware support to enforce the secret boundaries.

	▲	neo2006 3 hours ago \| parent [-]
		I'm not super familiar with TPUs and Trusted execution environments but my understanding is that it serve a different threat model. TEE aim to protect a certain workload from the host to avoid another workload on the same host from steeling secrets. Kloak aim is to protect the secret from the workload itself not the host.

▲

boistrous 4 hours ago | parent | prev [-]

we currently support rewrites for specific hosts and IPs and we have an open issue for supporting rewrite for specific headers for http/http2