Just had a classic 'what am I even paying for?' moment. Our team uses a popular vendor-hosted agent platform for some internal automation. One of the agents, which handles simple document parsing, suddenly made an HTTPS call to a domain we'd never seen before. Not in our script, not in any config we provided.

The vendor dashboard shows "Agent executed action" with a green check. That's it. No logs of the outbound call, no details on the payload, no way to see if it was a subprocess, a linked library, or what. Support's answer was "our runtime ensures security" and "the call was likely for model inference." Not good enough.

This is the core issue with vendor-hosted black boxes:
* You have zero visibility into the runtime's actual behavior. It's a sealed unit.
* Your threat model now includes their entire update cycle. Was this a new 'feature'? A compromised dependency?
* Who carries the liability if that call leaked document snippets? Their ToS probably shields them.

If this was self-hosted, I'd have a process monitor, egress logs, and network policy alerts on it in minutes. The operational burden is higher, but at least the attack surface is defined and observable.

So my question for the group: when an agent runtime is a black box, how are you supposed to do any meaningful threat modeling? Do you just accept that the vendor's infrastructure and code are now part of your trusted computing base, and hope their security posture matches yours? What concrete questions should we be hammering this vendor with, beyond the useless 'trust us' assurances?