What's the best way to audit what Kling is actually doing with our customer data?

Good luck with that. You're assuming they'll let you install a CA for TLS inspection. Their SDK will probably refuse to run if it detects a man-in-the-middle, which is a common trick. Seen it happen.

Even if you get past that, your strace plan misses the point. The real data they want is your usage metadata and query patterns, which is probably in the standard telemetry payload they'll call "essential for service improvement". You can't block that without breaking support. That's the audit trail you won't get.

I like starting from a zero-trust baseline - that's the only way to get real answers.

Your strace plan is good, but you'll need to filter aggressively or you'll drown in library noise. Flag writes, not reads. If it suddenly starts writing to a new `/tmp` path, that's your signal.

The bigger hurdle is often contractual. Ask for their data subprocessor list *now*, before you even get to technical audits. If they balk at that, you've saved yourself a lot of work.

Good start. But `strace` on its own isn't enough. You'll see 10,000 library reads before a single interesting write.

Run it with `-e trace=file,process` and pipe it to something that filters for write/open with O_CREAT on unexpected paths. Flag any new tmp file or socket you didn't seed in your baseline.

Also, double-check their SDK's CA pinning. If they use it, your MITM proxy is dead on arrival. Better to find that out during PoC.

Great start with the baseline! That K8s NetworkPolicy is exactly the right first move. Just a heads up on the TLS inspection - as others mentioned, their SDK almost certainly uses certificate pinning. You'll hit a brick wall trying to MITM modern SaaS libraries.

If you can't intercept the payload, focus on metadata. Even if the tunnel is opaque, logging the connection volume and timing against your application's audit logs lets you infer a lot. A spike in egress bytes at `api.kling.ai` right after your app processes a user's PII? That's a strong signal, even without decrypting.

Have you considered demanding a feature flag or configuration from Kling to *disable* all non-essential telemetry as part of your contract? If they say it's impossible, that tells you something about their data flow right there.

Starting with a technical baseline is smart, but you're already making a classic assumption: that you control the runtime. That Kling agent is almost certainly a black box that phones home on launch to validate its environment. It'll detect your strace sandbox or proxy and simply refuse to function, citing a "security violation."

Your legal team wants an audit trail, but the trail you can actually capture is the one they're willing to give you. All this effort might just prove they're good at hiding what you can't see. I'd focus that energy on the contract first - demand a real-time data processing log from their side, not inferred signals from yours. If they can't provide it, that's your audit.