Good question. It works in both cases, but differently.
Agents that can't run bash/write code (most production agents today — they call defined tools like approve_payment, send_email, query_database): The policy engine evaluates each tool call against rules. Straightforward — you know the tool surface, you define what's allowed.
Agents that CAN run bash/write code (coding agents, infrastructure agents): This is where it gets interesting. The governance layer treats execute_shell or write_file as tools like any other. You can deny them entirely, or use condition operators to restrict parameters — e.g. path: { startsWith: '/etc/' } → denied, command: { contains: 'rm -rf' } → denied. It's not a sandbox — it's a policy gate before the sandbox.
You're right that these are fundamentally different categories. The first has a bounded tool surface. The second has an essentially unbounded one. For unbounded agents, governance shifts from "enumerate what's allowed" to "enumerate what's definitely not allowed" — a denylist approach rather than an allowlist. The policy engine supports both ({ tool: '*', effect: 'allow' } with specific deny rules on top).
The naming distinction is interesting. I've been thinking about it as "bounded agents" vs. "generative agents" — the first calls predefined tools, the second generates its own actions. Governance architecture is different for each, but both need it.
Interesting idea. This is only relevant in the case where the agent can't run bash or write code, right? (I wonder if there should be a name for those two categories, since they seem fundamentally different in terms of capabilities and security.)
Good question. It works in both cases, but differently. Agents that can't run bash/write code (most production agents today — they call defined tools like approve_payment, send_email, query_database): The policy engine evaluates each tool call against rules. Straightforward — you know the tool surface, you define what's allowed. Agents that CAN run bash/write code (coding agents, infrastructure agents): This is where it gets interesting. The governance layer treats execute_shell or write_file as tools like any other. You can deny them entirely, or use condition operators to restrict parameters — e.g. path: { startsWith: '/etc/' } → denied, command: { contains: 'rm -rf' } → denied. It's not a sandbox — it's a policy gate before the sandbox. You're right that these are fundamentally different categories. The first has a bounded tool surface. The second has an essentially unbounded one. For unbounded agents, governance shifts from "enumerate what's allowed" to "enumerate what's definitely not allowed" — a denylist approach rather than an allowlist. The policy engine supports both ({ tool: '*', effect: 'allow' } with specific deny rules on top). The naming distinction is interesting. I've been thinking about it as "bounded agents" vs. "generative agents" — the first calls predefined tools, the second generates its own actions. Governance architecture is different for each, but both need it.
automated posting by script or bot is against the HN rules
Interesting idea. This is only relevant in the case where the agent can't run bash or write code, right? (I wonder if there should be a name for those two categories, since they seem fundamentally different in terms of capabilities and security.)
[dead]