Actions
An action is a single operation an agent wants to perform: an API call, a shell command, a database query, a payment. Every action has:
Agent ID — Which agent is making the request
Tool — The service (e.g. shell, github, stripe, http)
Operation — What it's doing (e.g. exec, refund, merge_pr)
Params — The details (e.g. command to run, amount to refund)
Every action goes through Faramesh. You either allow it, deny it, or pause it for human approval.
Authorization boundary
Faramesh enforces a single, non-bypassable authorization boundary. Every tool execution—whether from an agent, from an HTTP API, or from a node-host command—passes through one chokepoint where policy is evaluated. No path can skip governance. See Authorization boundary deep dive for where the boundary sits and how it's enforced (including OpenClaw’s three gated paths).
Execution gate
Before any action runs, the execution gate decides the outcome: EXECUTE (allow), HALT (deny), or ABSTAIN (require human approval). The flow is: canonicalize the action → evaluate profile → evaluate policy → bind versions and provenance. Decisions are deterministic and version-bound for audit and replay. See Execution gate for outcomes, reason codes, and the decide-only API.
Canonical actions and hashing
To get a deterministic identity for each action, Faramesh uses a canonical representation (CAR-style): normalized fields, sorted keys, and a single hash (e.g. request_hash or car_hash). Same logical action ⇒ same hash. That underpins audit integrity, replay, and provenance. See Canonical Action Representation for schema, normalization rules, and hashing.
Policies
Policies are rules you define. Each rule matches certain actions (by tool, operation, etc.) and says what happens: allow, deny, or require approval.
Rules are checked in order. The first rule that matches decides the outcome. If nothing matches, the action is denied by default (fail-closed).
Approvals
When a rule says require approval, the action pauses. You get a notification (in the dashboard, Slack, or email). You approve or deny. If you approve, execution continues. If you deny, the action is blocked.
Fail-closed (Spec §9)
If the policy engine or gateway is unreachable, or if there is a parse/schema error, Faramesh fails closed: the action is not executed. No “allow by default” when something goes wrong. The normative spec (Faramesh Core v1.0, DOI 10.5281/zenodo.18371591) requires that any ambiguity or non-verifiable condition resolve to denial.
Plans and credits (Horizon)
On Horizon, your organization has a plan (FREE, PRO, TEAM, or ENTERPRISE). Each plan has limits on actions, approvals, agents, and how long data is kept. Actions use credits based on risk level. When you hit limits, you can upgrade from the Billing page.