Omnigent governs each wrapped agent by injecting that agent’s native pre-tool hook, which POSTs the proposed tool call to the server’s /policies/evaluate endpoint and translates the verdict back. Verdicts are ALLOW, DENY, or ASK. The subtle, load-bearing decision is what ALLOW actually sends to the underlying agent:
Emitting
"allow"here would auto-approve the tool and suppress the harness’s native permission prompt … collapsing two independent gates — the deployment’s policy and the human’s consent — into one.
So on ALLOW, the hook returns “no opinion”, not "allow". The org-level policy can forbid an action, but it can never grant it in the user’s place: the human’s own consent prompt still fires. Two gates, kept orthogonal. They compose as an AND — both must pass — and neither can speak for the other.
Two more details make it robust:
- A stray or unresolved
ASKfails closed todeny, not to “defer” — specifically so it can’t be swept up by an agent running inbypassPermissionsauto-approve mode. - Failure handling is phased: the pre-execution
tool_callgate fails closed on a policy-server outage (an unevaluable gate must not let the call through), while advisory post-hoc phases fail open (denying a result only blocks something that already happened).
Why this is non-obvious
It’s tempting to model permission as a single boolean the system computes for the user. But “the organization permits this” and “this particular human consents right now” are different questions with different owners. Merge them and a permissive org policy silently strips the human out of the loop — the exact opposite of oversight.
Sources
-
omnigent/native_policy_hook.py:163✓ verified -
omnigent/policies/types.py:44✓ verified