Action-Level Gating FAQ

What is action-level gating?

Action-level gating is a security model where every discrete action an AI agent attempts is intercepted, evaluated against a policy, and either allowed or denied before execution. SafeClaw implements action-level gating for three action types: file_write, shell_exec, and network. Unlike monitoring, gating happens before the action occurs — it is preventive, not reactive. See also: What Is SafeClaw? FAQ.

How is action-level gating different from monitoring?

Monitoring observes and records actions after they happen. Action-level gating blocks unauthorized actions before they execute. A monitoring tool will tell you that an agent wrote to /etc/passwd after the fact. SafeClaw prevents the write from happening at all. Monitoring is forensic; gating is preventive. SafeClaw provides both — gating via the policy engine and forensics via the tamper-proof audit trail. See also: Audit Trail FAQ.

How is action-level gating different from sandboxing?

Sandboxing isolates an entire process in a restricted environment (e.g., Docker container, VM). Action-level gating is more granular: it evaluates each individual action against a policy. A sandbox says "this process can only access /tmp." SafeClaw says "this agent can write to /tmp/output.json but not /tmp/config.yaml, and it can run npm test but not rm -rf." Gating provides fine-grained control that sandboxing cannot. See also: SafeClaw vs Alternatives FAQ.

What actions can be gated?

SafeClaw gates three categories of actions: file_write (any file creation or modification), shell_exec (any shell command execution), and network (any outbound network request). Each action is described by its type, target (file path, command, or URL), and optional metadata. Policy rules match against these properties to determine whether the action is allowed or denied.

What are the three effects?

SafeClaw policy rules have three possible effects: allow, deny, and audit. Allow permits the action to proceed. Deny blocks the action entirely. Audit allows the action but flags it for review in the audit trail. Every rule must specify exactly one effect. In deny-by-default mode, any action that does not match an explicit allow or audit rule is denied. See also: Policy Engine FAQ.

How are rules evaluated?

Rules are evaluated in order using a first-match-wins model. When an agent requests an action, SafeClaw iterates through the policy rules from top to bottom. The first rule whose conditions match the action determines the outcome. If no rule matches, the deny-by-default fallback blocks the action. This evaluation runs locally and completes in sub-millisecond time. See also: Policy Engine FAQ.

What is first-match-wins evaluation?

First-match-wins means the policy engine stops evaluating as soon as it finds a rule that matches the action. Rule order matters: a broad allow rule placed before a specific deny rule will override the deny. This model is deterministic, predictable, and fast. Users can test rule ordering with SafeClaw's simulation mode before deploying policies to production. See also: Policy Engine FAQ.

Can I gate network requests?

Yes. SafeClaw can gate all outbound network requests made by an AI agent. Policy rules can match on destination URL, domain, port, or protocol. This is critical for preventing data exfiltration and blocking access to cloud metadata endpoints (such as the IMDS at 169.254.169.254) that expose credentials. See also: AI Agent Security Risks FAQ.

Can I gate file writes?

Yes. SafeClaw gates all file write operations. Policy rules can match on file path, directory, extension, or pattern. You can allow writes to a specific output directory while blocking writes to system files, configuration files, or sensitive directories like ~/.ssh/ or ~/.aws/. See also: AI Agent Security Risks FAQ.

Can I gate shell commands?

Yes. SafeClaw gates all shell command executions. Policy rules can match on the command string, executable name, or arguments. You can allow npm test while blocking rm -rf, curl, or any command that modifies system configuration. This prevents agents from executing destructive or unauthorized commands. See also: SafeClaw vs Alternatives FAQ.