The Safety Gate: Permissions, Confirmation, and Trust
When Agentao’s model proposes a tool call, the important question is not whether the proposal sounds reasonable. It is whether the call passes a policy decision before it reaches a side effect, and whether the host has a conservative answer when nobody is available to approve it. This chapter follows Agentao’s two-stage safety gate—PermissionEngine first, confirmation second—and shows why rule order, domain scope, unattended operation, and MCP trust all matter.
The decision happens before the side effect
A model sees a tool schema and proposes a name plus arguments. That visible schema is a capability surface, not an authorization decision. Removing a tool from the schema can reduce what the model is likely to attempt, but it does not establish that a tenant is forbidden from using the underlying business operation. The actual authorization must be enforced by the host, the tool implementation, the backend, or a runtime policy that evaluates the call before execution.
Agentao’s PermissionEngine provides the first policy layer. It evaluates a proposed tool and its arguments and produces one of three decisions: ALLOW, DENY, or ASK. ALLOW lets the call proceed. DENY prevents execution and returns a refusal-like result to the model so the model can adapt or explain. ASK routes the edge case to the Transport’s confirmation surface. This order matters: the runtime makes a fast rule decision before it waits for a human or another host process.
The engine offers broad presets—read-only, workspace-write, full-access, and plan-oriented modes—but the useful behavior comes from how rules meet a particular tool. A rule can match a tool name, match argument values with regular expressions, or evaluate a URL domain. For a file write, the host might allow paths under an approved workspace and deny everything else. For shell, it might allow a narrow read-only command pattern, deny known-dangerous forms, and ask about the remainder. For web access, it can allow selected domains, deny local or metadata addresses, and decide what happens to URLs that match neither list.
The rule engine is first-match based. A broad rule placed before a specific rule can make the specific rule unreachable. For example, an ASK rule for every write_file call will match before a later ALLOW rule intended for a safe temporary directory. The result may look conservative because it still asks, but the policy no longer expresses the intended exception. Conversely, a broad ALLOW placed first can erase a later deny. Specific conditions should come before general fallbacks, and a production policy should end with an explicit catch-all rather than depending on a default the host has not reviewed.
Domain matching has a similar precision requirement. The documentation distinguishes an exact host name from a suffix pattern: a leading-dot pattern such as .github.com can cover the base domain and its subdomains, while github.com is exact. A host that assumes every pattern is a suffix can accidentally allow less or more than intended. Domain rules also need to be interpreted as application policy, not as the entire network boundary. Redirects, alternate IP representations, DNS behavior, and infrastructure routing can all change what a request reaches.
A small policy can reveal the difference between visible capability and executable authority. Imagine three rules for writefile: allow paths under a designated workspace, deny the tool for all other paths, and ask about a separate export directory.