How it is built

Ability Gate has two layers:

• Leet Guardrails (library/leet-guardrails/, prefix ankgr_ / AnkGR_): the reusable engine. It owns the request store, the SQL-level write recorder, rollback with drift check, the dry-run sandbox, the hash-chained audit trail and the Agent Control screens (Approvals, Activity, Request).
• Ability Gate (includes/, prefix abgate_ / AbGate_): the product. It intercepts ability calls on wp_pre_execute_ability, identifies the agent, scores risk, applies modes, rules and rate limits, and adds the Agents, Rules, Risk, AI Usage and Settings screens.

Several Leet plugins can bundle the library. Each copy registers itself and the newest version boots, so a site has one queue, one undo history and one audit trail.

Response codes for agents#

Situation	Error code	HTTP status
Held for approval	abgate_approval_required (data includes request, the uuid)	409
Denied by mode, rule or risk default	abgate_denied	403
Rate limit reached	abgate_rate_limited	429
Repeat of a rejected, expired, failed or rolled-back request	abgate_request_closed	410
Repeat of an approved request whose result was already collected or is over 24 hours old	abgate_not_collectable	410

MCP clients only show the error message, so every message says what happened and what the agent should do next.

The status ability#

ability-gate/get-request (read-only, never gated) takes request (the uuid from the 409 error) and returns the status: pending, approved, rejected, expired, executed, failed or rolled_back. The result is included only for the calling agent’s own executed request that it has not collected yet.