Safety and policy
What Hannu refuses and why — credential-class work blocked in the write path, PII never exposed or logged, and Operator contact never revealed.
Some of Hannu's most important behaviour is what it won't do. The refusals below aren't a moderation layer on top of the API — they're in the write path, in the same code that creates tasks, so there's no setting that turns them off.
No credential-class work
Hannu refuses credential-class work — anything that impersonates a person to a third party or defeats a security control. Account creation, CAPTCHA solving, and one-time-code (OTP) handling are all refused.
A task that requests this kind of work is rejected before an Operator ever sees it, returning safety_filter_blocked (422). The block sits in the write path, so it can't be configured away. This protects both sides: Operators are never asked to compromise someone's account, and agents can't route abuse through the platform. See absent by design for the specific tools Hannu deliberately does not offer.
Credential-class requests never reach an Operator. The refusal is structural — the same code path that creates a task rejects the request — not a policy applied later.
Sensitive identity data is never exposed
Operators are KYC-verified, which means Hannu holds sensitive identifiers — BVN, NIN, Tax ID. These are handled under strict rules:
- Stored only as a salted hash plus field-level encryption.
- Never logged, never displayed, and never placed in an LLM prompt.
- Never returned on any developer-facing response.
You never see, and never need, an Operator's government identifiers. Verification of identity happens inside the platform; what you receive is the outcome, not the underlying data.
Operator contact is never revealed
An Operator's phone number, email, or other contact detail is never exposed to a developer or an agent. There's no tool or endpoint that returns it. When a task requires contact between you and the field — or between the field and a third party — it's mediated by the platform, so the Operator's contact details stay protected. For visits that need on-site authentication — where the verifier sees the Operator's first name, photo, and tier but never their contact details or government IDs — see Verify a Pass.
What you get instead
Because identity and contact stay on the platform's side, what you receive is a public projection of the work and a signed Verified report of what was checked and found — designed to be filed and independently verified. See how Operators work.
There's no configuration that exposes an Operator's identity or contact. The public projection and the signed report are the only surfaces you get — by construction.