VIRIDISSECURITY
Request assessment

Featured product · Apache-2.0 open source

Fresh work before costly agent requests.

Put a proof-of-work gate in front of HTTP endpoints you operate. Choose the protected requests and their difficulty. Each accepted challenge is consumed, so another acceptance requires fresh work.

Protect agent invocations, HTTP MCP requests, inference triggers or submission endpoints with Python FastAPI, WSGI or Node Express middleware. The reference uses SHA-256 work. The source preparation for 0.2.0 is merged; it is not yet a tagged or published package release.

Inspect the reference sourceRead the integration guide Plan your installationDiscuss your endpoint

For agent and service maintainers

Put the gate where work begins.

Start with an endpoint you own. Keep upstream rate limits before Maxwell, then require authentication and permissions before the request reaches your agent or application.

Live request path

  1. 01Caller and client solver
  2. 02TLS, upstream filtering and rate limits
  3. 03Maxwell checks fresh work and consumes the challenge
  4. 04Authentication, permissions and input validation
  5. 05Your agent or application
Route every protected request through this boundary. A directly reachable origin or alternate path can bypass the gate.
01

Choose the expensive entry point.

Integrate FastAPI/Starlette ASGI middleware, WSGI middleware or Express middleware at the HTTP route that starts costly work. These integrations protect application requests; they do not install a network firewall or automatically cover WebSockets, stdio MCP connections or an agent’s internal tool calls.

02

Set a policy your callers can meet.

Generate a random signing secret of at least 32 bytes and keep it in your environment or secret manager. The default difficulty is fixed at 18. An optional rule can increase difficulty after failed proof submissions; adapting to traffic rate, server load or trusted identities requires your own integration. Legitimate callers also perform the work, so measure their delay before choosing a policy.

03

Connect the client and acceptance state.

The JavaScript client’s fetchWithMaxwell wrapper solves and retries a recognized challenge once. Other clients implement the documented challenge, solve and retry loop. One process can use the default in-memory store; multiple workers or hosts need shared Redis state without live-key eviction and with suitable persistence. Preserve that state across restarts, or rotate the signing secret if accepted-nonce state is lost.

04

Test replay, capacity and caller delay.

Confirm that the first valid solution reaches the application and a replay is refused. Monitor admitted traffic, rejection reasons, store health and legitimate-client completion. A full store rejects new acceptances; size it for peak accepted traffic and challenge lifetime. A consumed proof does not mean the application completed, so application retries need fresh work and their own idempotency policy.

Follow the maintainer quickstart Review deployment requirements

Free interactive illustration

Follow a request through the gate.

Watch the caller search, the gate consume a challenge, and a replay stop before your agent. Play the sequence or inspect each step. This illustration does not send requests or compute real work.

Maxwell / illustrated reference flow

The caller does the work. Your agent stays behind the gate.

Watch challenge A travel out, its solution come back, and one request pass. Replaying A stops at Maxwell; challenge B needs fresh work.

How Maxwell protects an agent or API entry pointA caller sends a request to Maxwell before the protected agent. A signed challenge returns to the caller, which searches locally for a SHA-256 solution. Maxwell checks signature, context, expiry and work, then atomically consumes the nonce before forwarding one request. Reusing solution A is refused and returns new challenge B. Current stage:Request. Illustrated requests admitted: 0.RequestChallenge ANo access01 / CallerRequest without a solutioncandidate 1 → misscandidate 2 → misscandidate N → matchSHA-256 searchMore difficulty → moreexpected trials per solutionILLUSTRATIVE TRIALS · NO TIMING SCALE02 / Maxwell gateChallenge needed○ Signature○ Context○ Expiry○ Work · one checkSingle-use record: not consumed03 / Protected agentYour API or HTTP MCP endpoint0 requests admittedWaiting behind the gate.Fresh work is required foreach further acceptance.→How Maxwell protects an agent or API entry pointA caller sends a request to Maxwell before the protected agent. A signed challenge returns to the caller, which searches locally for a SHA-256 solution. Maxwell checks signature, context, expiry and work, then atomically consumes the nonce before forwarding one request. Reusing solution A is refused and returns new challenge B. Current stage:Request. Illustrated requests admitted: 0.RequestChallenge ANo access01 / CallerRequest without a solutioncandidate 1 → misscandidate 2 → misscandidate N → matchILLUSTRATIVE TRIALS · NO TIMING SCALE02 / Maxwell gateChallenge needed○ Signature○ Context○ Expiry○ Work · one checkSingle-use record: not consumed03 / Protected agentYour API or HTTP MCP endpoint0 requests admitted→

Request

A request without a solution stops at Maxwell. It does not reach the protected agent or API.

Illustration only. This sequence does not contact a service or measure protection. Single-use enforcement needs shared state across workers. Callers who can afford the work can still pass; keep authentication and upstream rate limits.

Real computation · Local preview

Run a real challenge and replay check.

Your browser computes SHA-256 work, then sends the solution to a harmless endpoint in this preview. The server uses the pinned reference SDK to accept it once and refuse its replay.

Starts only when you choose Run.

Difficulty 12; expected search is 4,096 hash attempts under the documented model. Measurements are one run on this device and server, not a benchmark guarantee. This demonstration invokes no agent, tests no external target, and activates no protection for another system.

The real endpoint is disabled here. Follow the maintainer quickstart to run the SDK on your own machine.

Inspect the replay and store tests for the implemented acceptance rule.

Computational cost, stated precisely

Raise the work required for repeated access.

Under the documented classical random-oracle model, a fresh solution takes an expected 2d hash attempts at difficulty d. Each additional bit doubles expected work. This is a search-work model; solve time and deployment cost depend on hardware and implementation.

Maintainer advantage

Fresh work for every acceptance.

At difficulty 20, the model gives approximately one million hash attempts per fresh solution on average. The server checks one candidate hash, authenticates the challenge and checks acceptance state. Single use prevents one solved challenge from buying repeated access during its lifetime.

Read the computational guarantee
Deployment boundary

Keep the surrounding defenses.

Attackers who can afford the work can still submit requests. Maxwell does not classify their intent or guarantee that attacks become uneconomic. Upstream defenses must handle bandwidth floods; authentication, permissions, isolation and input validation remain responsible for what a solved request may do.

Review the control’s scope
01 · Reference SDK

Integrate the open-source control.

Default middleware uses an in-memory nonce store for one process. Multiple workers or hosts need a shared store, such as Redis, to preserve single-use acceptance across the deployment.

Low-level verification without a nonce store is stateless and replayable within the challenge TTL. A full store fails closed; plan capacity, monitor rejection counts, and apply upstream rate limits. These choices belong in your integration review.

Review state and capacity requirements
02 · Separate paid service

Inspect a hosted policy rehearsal.

The MCP catalog offers a paid Maxwell Defense Rehearsal: a policy recommendation, local SHA-256 microbenchmark and endpoint-trial checks. The service describes its price and input requirements.

A rehearsal does not activate managed protection or certify your system. It is separate from this free illustration and from an SDK deployment you operate.

Inspect the rehearsal service

Evidence and scope

Inspect the behavior and its assumptions.

The reference documents its computational protocol and tests. The separate T-IB-09 research model declares one external asymmetry axiom. Read the exact statements and artifacts before extending a claim to your application.

Read the assumptions and artifactsExplore Viridis researchInspect the MCP catalog

Start with your system

Choose a control that fits the boundary.

Bring the endpoint you operate, its traffic patterns, deployment shape and failure constraints. We can assess fit and integration requirements before you enable a gate.

Request an assessment