Castle: developer-first account abuse, and where the overlap ends

Castle comes up in evaluations more often than its size suggests because it is the one product in the adjacent space that engineers enjoy using. Its design philosophy is also the closest to Prosopo's, so the difference between the two is worth describing precisely rather than overstating.

What Castle is

A developer-first account abuse and fraud platform. API-driven, aimed at engineering teams, focused on registration, login and in-app user actions. Castle was not evaluated in the Q2 2026 Forrester Wave.

Where it leads

Developer experience, and the account itself. If the problem is fake signups, credential stuffing against your login, or abuse of in-app actions by accounts you can identify, Castle is built exactly around that model and the integration is pleasant.

Castle also promotes a no-code Cloudflare connection, so the deployment story next to an existing CDN is straightforward.

Where the two products diverge

The distinction is what gets scored.

Castle scores users and account events. That works well when there is an account to attach risk to and when the abuse you care about is expressed through user behaviour over time.

Prosopo scores requests, including requests where no account exists and never will. A scraper pulling your product catalogue has no account. An inventory bot hitting a SKU endpoint has no account. An LLM crawler harvesting a face-search free tier has no account. That traffic never reaches a user-risk model because it never becomes a user.

If your abuse is concentrated on login and registration, the overlap is large and Castle is a fair choice. If it is concentrated on catalogue, checkout, search or an unauthenticated API, the overlap is small.

What it costs

Castle has been more open about pricing than the enterprise bot vendors and has offered self-serve entry tiers. Check the current page, since this moves.

Where data is processed

US-based. Prosopo can hold processing to the EU for Enterprise customers, and provision a separate database where a customer needs their visitors kept apart from every other site's.

How a block gets explained

Through Castle's API and console, structured around user risk. That works well for accounts. It is not built to explain why an unauthenticated request to a JSON endpoint was refused.

Who authors the rules

You do. Castle is built for engineers to configure. Prosopo follows the same philosophy.

Which buyers Castle suits

Castle is the stronger fit if account takeover, fake registration and in-app abuse are the whole problem, if the buying team is engineering rather than security, or if you want user-level risk history as a first-class object.

How Prosopo compares

If unauthenticated traffic is the problem: scraping, catalogue harvesting, inventory hoarding, API abuse.

If you need enforcement at the edge in front of your origin rather than a decision your application makes after the request has already cost you a round trip.

If you want a reason on every block and the raw event stream exportable to your SIEM.

Running both is reasonable. They work at different points in the request path.

Side by side

See also account takeover and credential stuffing.