The authorization boundary is the single place where every agent action is evaluated before any effect happens. Nothing can bypass it. The Faramesh Core Specification v1.0 (DOI: 10.5281/zenodo.18371591) §10.4 requires that a conforming integration MUST NOT execute side effects unless the action has reached approved (or executing if auto-start is used). This document describes where the boundary sits and how it is enforced (including OpenClaw).
What is the authorization boundary?
The boundary is the chokepoint between “agent wants to do X” and “X actually runs.” Before any tool executes—shell, HTTP, payment, file, browser—the request must pass through Faramesh (or a Faramesh-backed guard). The policy engine returns allow, deny, or require approval. Only then does execution proceed or stop.
Inside the boundary: Policy evaluation, canonicalization, hashing, audit, provenance.
Outside the boundary: Your agents, tools, and infrastructure. They send requests in; they get a decision out.
No alternate path (e.g. direct HTTP invoke, or a different plugin) may run the tool without going through this boundary. That is what “non-bypassable” means.
Why a single boundary?
One policy surface — You define rules once; every execution path is checked the same way.
Consistent audit — Every decision is logged with the same schema and provenance.
No “back doors” — If multiple code paths could run tools, one could be forgotten or misconfigured; a single boundary avoids that.
Where is it enforced?
Horizon (API + dashboard)
When you use Faramesh Horizon (or a self-hosted Faramesh server), the boundary is the server:
Agents (or integrations) call POST /v1/actions (or the SDK wrapper).
The server canonicalizes the action, evaluates policy, and returns a decision.
Execution (connectors, shell, etc.) happens only after an allow (or after approval). The executor is invoked by the server, not by the client. So the client cannot “run the tool anyway” without the server’s say-so.
The dashboard and CLI are views into the same system; they don’t create a second execution path.
OpenClaw integration
When OpenClaw is used with Faramesh, the plugin is the execution gate: it calls Faramesh before every tool run. Three execution paths are all gated:
Path | Description | How it’s gated |
|---|---|---|
Agent tool execution | Agent calls a tool (bash, read, write, browser, etc.) via the runtime |
|
HTTP RPC | External or direct HTTP call to invoke a tool | The HTTP gateway (e.g. |
Node-host commands | System run, exec, browser proxy, etc. from the node host | Same authorization layer (e.g. in |
So: one authorization boundary, three code paths that all go through it. There is no “agent path” vs “HTTP path” that skips policy.
Diagram (conceptual)
Fail-closed at the boundary
If the policy engine is unreachable (network, crash, timeout), the integration should fail closed: do not execute the tool. OpenClaw’s Faramesh plugin does this by default (configurable). That keeps the boundary meaningful even when the server is down.
Summary
The authorization boundary is the single chokepoint where every action is allowed, denied, or sent for approval.
In Horizon/self-hosted, the server is the boundary; execution runs only after a positive decision.
In OpenClaw, the plugin enforces the boundary on all three execution paths (agent, HTTP invoke, node-host); no path bypasses it.
Fail-closed when the enforcer is unavailable keeps the guarantee intact.
For the execution flow (canonicalize → policy → outcome), see Execution gate. For how actions are hashed and identified, see Canonical Action Representation.