Security model, and what we refuse
HumanOps treats both sides as untrusted: what an agent asks is checked against a published refusal list before it reaches a person, and what a person writes is sanitised and wrapped before it reaches a language model. Every task is scoped by a time-boxed permission naming what the worker may and may not do.
Two threat models, not one
An agent could ask a human to do something it should not do itself.
A model can be talked into a harmful instruction by content it has read. Routing that instruction through a real person makes it worse, not better, so every task is checked against the refusal list below before anyone is offered it — from the API, the MCP server, the web form and the ops console alike.
A human could send something back that manipulates the agent.
Everything a worker writes is stripped of control characters, length-capped and returned inside a typed envelope, so a model consuming it has a structural cue that this is data. Text that reads like an instruction to a model is flagged for review before the task can complete.
Every task is scoped
A worker accepting a task receives a server-issued, time-boxed permission that names exactly what is allowed and what is forbidden — photograph and observe, but not purchase, not sign, not access any system, not collect personal data. It expires. The app enforces it and the server checks it again.
TASK HO-7K2M9X Photograph storefront · Barcelona
VALID 13:00 – 16:00 MAX SPEND €0
ALLOWED PHOTO · OBSERVE · ASK_EMPLOYEE
FORBIDDEN PURCHASE · SIGN · ACCESS_SYSTEM · COLLECT_PERSONAL_DATAWhat we always refuse
- Surveilling, following or gathering information about a named private individual
- Anything whose evident purpose is harassment, stalking, doxxing or intimidation
- Impersonating an official, an inspector or an employee of another organisation
- Collecting identity documents or biometric data from third parties
- Regulated professional acts we hold no licence for
- Entering private property without permission
- Anything requiring deception that causes harm
- Circumventing security or access controls
- Purchasing restricted goods
- Any task whose stated purpose we would not be willing to publish — judged by a person, not by a pattern
What we send to a person before accepting
- Anything involving a minor
- A residential address
- A political or religious organisation
- A court or police facility
- An employee's individual conduct
- A price above the review threshold — judged by a person, not by a pattern
What is normal and welcome
- Mystery shopping, disclosed to us and lawful in the jurisdiction
- Photographing publicly visible premises
- Asking a business a question as an ordinary member of the public
- Verifying a company's stated facts
- Accessibility checks
- Retail and compliance audits
- Collecting a public registry document
Found something wrong, or want to report abuse of this service? Write to the address on the legal notice and mark it for HumanOps security.
How the refusal list is enforced
Every brief is checked against the list above before anybody is dispatched, at whichever door it arrives through. The lists on this page are generated from the code that enforces them, so what you read here is what actually runs.
| Door | When the check runs |
|---|---|
| Web | When the order is created — before you are asked to pay, so a refused brief never takes your money first. |
| API | On POST /v1/tasks, after schema validation and before the task exists. A refused brief leaves nothing behind and is not charged. |
| MCP | Identical to the API: the MCP tool calls the same function, so the two cannot diverge. |
| Ops | A brief escalated for review is held, and only a named person can clear it. Clearing one is recorded with the reason. |
The classifier reads words, not intent, so it is tuned to refuse only what is unambiguous and to escalate anything that merely looks risky. It is the first gate and not the only one: the worker also carries a capability token naming what the task does and does not authorise, and a person reviews the result before it reaches you. A refusal returns the rule that fired and, where one exists, a compliant way to ask the same question:
{
"error": "capability_refused",
"rule": "surveil_individual",
"detail": "We do not send people to observe, follow or gather information
about a named private individual.",
"try_instead": "If you need to confirm that a BUSINESS operates from an
address, use human.verify with the company name."
}Data processing, sub-processors and records
Every party below actually holds data of ours; the list is generated from the configuration the system runs on, so it cannot quietly stop being true. No personal data is transferred outside the EEA.
| Sub-processor | What they do | Region | What they hold |
|---|---|---|---|
| Hetzner Online GmbH | Hosting and backups | EU (Germany) | Everything, at rest and in transit. |
| Stripe Payments Europe, Ltd. | Card payments and payouts | EU (Ireland) | Buyer name, email, billing country, VAT number, card token; worker payout account details. We never see a card number. |
| Anthropic (Claude API) | Evidence semantic check | EU endpoint required — see the DPIA | The scrubbed image and the task question. Faces and plates are blurred BEFORE the request is made, never after. |
| The identity provider (not yet contracted) | Worker identity verification | EU | Worker name and identity document, held by the provider. We store the VERDICT and a reference, never a document image. |
| The transactional mail provider | Order confirmations, worker notices | EU | Email address and the message body. |
Article 30 records are kept per capability — 17 of them today, one for each thing we sell — and are generated from the same catalogue, the same evidence requirements and the same retention window the automated sweeper enforces (365 days for evidence files). Adding a capability adds a record; nothing here is typed twice.
- DPIA — DRAFT, not yet signed off. We say so rather than imply otherwise. Systematic location data, imagery of public places, and automated decisions affecting a worker's income each push this over the Article 35 threshold on their own.
- DPA — DRAFT, not yet signed off. We say so rather than imply otherwise. Enterprise buyers ask for the DPA and the sub-processor list in the first procurement email. Not having them costs weeks.
Ask us for the DPIA or the DPA and we will send the current version with its hash, so you can tell whether the copy you are reading is the one that was reviewed.