Compliance Agent

The Compliance Agent is the pre-payment gate. It is invoked by Orchestrators (or any caller over A2A) before a transfer executes. It collects scoring signals from provider connectors, applies the operator’s numeric thresholds server-side, and either auto-approves, auto-blocks, or routes the case to a human reviewer.

It does not move funds. It emits a structured verdict the caller acts on.

The decision

The routing decision is deterministic. Two operator-configured thresholds drive it:

Field	Default	Meaning
block_score_threshold	90	Aggregated score ≥ this → auto-blocked.
review_score_threshold	70	≥ this and < block → human review.

The aggregated score is the max across all provider signals. A single high-risk hit drives the verdict.

The agent calls compliance_decide(signals) which returns {verdict: allow|review|block, aggregated_score, limiting_signal}. The LLM is told via the system prompt to act exactly on the returned verdict — no judgement of its own.

Provider connectors

Compliance does not ship with hardcoded providers. The operator binds connectors to the agent, and each connector contributes tools (compliance_score_address, compliance_score_recipient, compliance_score_transaction):

• compliance_mock — built-in. Deterministic pseudo-random scores seeded by the input. ~75% low / ~15% medium / ~10% high. Use this to exercise the agent end-to-end before real providers come online.
• (planned) Chainalysis KYT, SEON, Sigil’s internal compliance engine.

Adding a new provider is a connector adapter implementation, not a template change.

The report

After scoring, the agent renders a markdown report and uploads it to Drive via the bound google_drive connector. The folder is configured in report_drive_folder_id. If the upload fails (no Drive bound, insufficient scope, …) the report is included inline in the audit trail and the reviewer still sees it.

The report layout is operator-overridable via the system prompt’s “Operator specialization” field but defaults to:

## Request
| amount | currency | from | to | recipient | network | purpose |

## Signals
### compliance_score_address
- score 32 · severity low · verdict allow
- reasons: ...

### compliance_score_recipient
- ...

## Aggregated verdict (after compliance_decide)
- score 78 · severity medium · verdict review

## Recommendation
1. Confirm recipient identity via passport
2. Validate purpose of payment

Human review flow

When compliance_decide returns review, the agent calls request_human_review with {title, report_md, payload}. The run suspends; the case appears in /reviews in the portal.

Reviewer approves or blocks; the agent’s run resumes with the verdict as the synthetic tool_result for that request_human_review call. The agent passes the verdict through to the caller as its final_answer.

See Pause and resume for the cascade semantics when the caller is an Orchestrator.

Calling Compliance from your code

The Compliance Agent is callable over A2A like any other Sigil agent. The recommended pattern from an Orchestrator’s system prompt:

Before delegating any payment, call the Compliance Agent with the transfer details. Wait for its verdict. Only delegate to Payment / Treasury when the verdict is allow.

External callers (your own backend, a Hyperliquid-style protocol) can hit the JSON-RPC A2A endpoint directly — see Architecture · A2A.

Note

Once real provider connectors land, you’ll bind multiple providers to the same Compliance Agent. The agent calls all configured providers and compliance_decide aggregates over their signals.