01
ALLOW
Clears the reply to continue to the remaining channel and send gates. It does not mean the message was sent or delivered.
Governed automation
Agent Firewall
A runtime policy layer for supported WhatsApp automated replies. It evaluates each proposed reply before autonomous action and returns one of four policy outcomes.
Available today for the supported WhatsApp inbound reply workflow.
01
What Agent Firewall guards
Agent Firewall evaluates proposed automated replies against the configured action mode, autonomy posture, business boundaries, and runtime safety signals. It does not replace channel or transport gates.
02
Supported scope
Today, the live implementation covers supported WhatsApp inbound replies in Agentix. It does not claim protection for every channel, provider, agent action, or integration.
- 01
Proposed WhatsApp automated replies
- 02
Configured action modes and business boundaries
- 03
Runtime pauses, rate limits, daily caps, and human-handoff requests
- 04
Decision visibility for supported evaluations
03
Four policy outcomes
Every core policy evaluation returns exactly one of these outcomes. Operational holds and internal escalation signals are not additional public outcomes.
02
REQUIRE_APPROVAL
Stops autonomous progress and keeps the draft for operator review. An operator may edit, approve, or reject it.
03
BLOCK
Denies the automated action under the configured policy. It does not continue to the send path.
04
HANDOFF
Stops the automated reply when a human-handoff or stop request is detected. The conversation remains for human follow-up; a bounded acknowledgement may be sent where supported.
04
Human approval is a workflow, not a fifth outcome
After REQUIRE_APPROVAL, an operator can review the recorded reason and, where a draft is available, edit, approve, or reject it. Those are operator actions. Internal escalation markers remain review signals, not additional public outcomes.
05
Channel and recipient boundaries
An ALLOW result cannot bypass WhatsApp’s remaining gates. Sending still depends on send enablement, a verified sender, the service window, recipient posture, rate and cap controls, and successful provider delivery. These are channel or transport boundaries, not Firewall outcomes.
06
Reversible controls
Operators can pause or resume a conversation, and authorized roles can disable sending, disable live autonomy, or return recipients to allowlist posture. These controls change the operating posture; they are not Firewall outcomes.
07
Decision records and visibility
Recorded Firewall evaluations can show the outcome, reason codes, risk score, and time. The Console also shows related draft and workflow status where available. This is bounded operational visibility, not a promise of a complete compliance record.
08
How it works
- 01
A supported WhatsApp reply is proposed.
- 02
Agent Firewall evaluates policy, autonomy, boundaries, and runtime signals.
- 03
It returns ALLOW, REQUIRE_APPROVAL, BLOCK, or HANDOFF.
- 04
ALLOW continues to the remaining gates; REQUIRE_APPROVAL waits for an operator; BLOCK stops; HANDOFF leaves the conversation for human follow-up.
09
Example: a WhatsApp reply that needs review
If a customer asks a question outside a configured business boundary, the proposed reply does not continue automatically. The public policy path is REQUIRE_APPROVAL: the draft stays in the operator workflow, where it may be edited, approved, or rejected. An approved reply must still pass the WhatsApp send gates.
10
Manage policies in Console
Use the protected WhatsApp settings area to configure action modes, business boundaries, send posture, recipient posture, and live autonomy. Access and available controls depend on your workspace role.