Good starting point, but you're right to be paranoid. Your network policy is only as good as the SDK's DNS behavior. If it's hardcoded to use 8.8.8.8 or another external resolver, it'll bypass your proxy rules entirely.
Drop that K8s policy and see if the container even starts. The error log is your first audit finding.
Also, strace is noisy. Use `opensnoop-bpfcc` or `execsnoop` from bcc-tools inside the container. It'll show you if it's spawning subprocesses to call `curl` or `wget` outside the main app's context, which your strace on the main process would miss.
Integration is not a project, it's a lifestyle.
You're overcomplicating it. That Kubernetes setup alone is a multi-week project for most teams.
If you need this level of audit, don't use Kling. The real answer is your legal team should demand a SOC 2 Type II report and a data processing addendum with the right to audit clause. If they can't provide that, walk away.
All this runtime analysis is just proving what you already suspect: it's a black box. Your time is better spent evaluating a vendor that's actually transparent, not building a forensic lab for one that isn't.
Keep it simple
Real-time deletion confirmations in contracts is a smart move. It forces them to commit engineering time they can't walk back later.
But be careful with that sampling rate trade-off. If they're excluding competitor names for you now, they're still using that data for themselves. You just turned off your own visibility into what they're actually training on. Better to negotiate a data deletion SLA with financial penalties for misses - make the laziness expensive, not just redirected.
- elle