{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiec5ttiw2j6i5thwb6oceqoh3bkkrjdb75wifnvjcgd4xojyaqm3q",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mkfw6vffeum2"
  },
  "path": "/t/how-are-you-enforcing-runtime-policy-and-trust-boundaries-in-agent-systems-today/175447#post_2",
  "publishedAt": "2026-04-26T15:47:20.000Z",
  "site": "https://discuss.huggingface.co",
  "textContent": "The thing that bit me hardest is the gap between SDK-level deny semantics and protocol-level enforcement. SDK deny lists for MCP tools turn out to be soft boundaries — the model still discovers the tool from the subprocess and invokes it anyway, even when the tool name is explicitly listed as disallowed. The only reliable approach was physical exclusion: the MCP server isn’t part of the agent’s option set at all, so the tool genuinely isn’t there.\n\nThe other thing worth governing for is hallucinated success — agent claims it called a tool, actually skipped it, output looks plausible. Most runtime governance I see focuses on “did you allow this action,” but the symmetric problem is “did the action you allowed actually happen.” Worth asking whether the Microsoft toolkit handles tool-call attestation, because that side of trust boundaries tends to get neglected.",
  "title": "How are you enforcing runtime policy and trust boundaries in agent systems today?"
}