{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicua3b4pcpvarch2qde4vrmiaxavbdicb7ppdjqj4n2keszjvrsyq",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mkhzcl4uis62"
  },
  "path": "/t/how-are-you-enforcing-runtime-policy-and-trust-boundaries-in-agent-systems-today/175447#post_3",
  "publishedAt": "2026-04-27T10:23:29.000Z",
  "site": "https://discuss.huggingface.co",
  "textContent": "I agree with the point about SDK level deny lists being too soft.\n\nFor agent systems, I think policy needs to be enforced at the runtime boundary, not inside the prompt and not only inside the model SDK.\n\nThe model should never be the authority on whether an action is allowed.\n\nA practical setup is:\n\n  1. Every tool has an explicit capability definition.\n\n  2. Every agent or worker has a scoped permission set.\n\n  3. The runtime checks each requested action before execution.\n\n  4. The tool layer refuses calls that are outside policy, even if the model asks for them.\n\n  5. Tool results are logged with request, caller, input, output, status, and trace id.\n\n  6. Success claims are verified against actual tool execution records.\n\n\n\n\nThe second point matters a lot. It is not enough to ask, “Was this action allowed?”\n\nYou also need to ask, “Did the action actually happen?”\n\nA model can claim it called a tool, skipped a step, or completed a task. The runtime should verify that against the execution trace.\n\nSo my rule is:\n\nPrompts can guide behavior, but runtime policy must enforce behavior.\n\nThe trust boundary belongs around tools, state mutation, credentials, external actions, and persistent memory writes.",
  "title": "How are you enforcing runtime policy and trust boundaries in agent systems today?"
}