How do I add fraud protection to an AI-built app?

Add fraud protection to an AI-built app by connecting Maskbreak's browser collection to a server-side evaluation before the action you want to protect. Keep the API key on your server, handle allow, review and block, and verify the result on your deployed site. Installing a script or producing a successful demo does not establish that signup, login or a valuable benefit is protected.

Maskbreak provides a recommendation, not automatic authentication protection. Your app still verifies credentials, checks permissions and manages sessions. This Maskbreak-authored guide covers implementation and acceptance criteria rather than a particular AI builder. Linked guidance and pricing were checked on 11 September 2026.

What should you ask the AI builder to protect?

Identify the action that releases value and the backend that performs it. For example, an AI-built study app might grant introductory tutoring credits after signup. Protect the server operation that grants those credits, including the path used after a social login. A check on a password form alone would miss that second entry point.

Keep eligibility and duplicate-grant prevention in the application. OWASP's business-logic guidance recommends enforcing workflow state and one-time benefits on the server. A clean visitor can still attempt to redeem a promotion twice.

If your builder has created only a frontend, identify or add an authenticated backend function before integrating the secret API call. Do not move a private key into the browser to make a demonstration work.

Where should the Maskbreak API key go?

Create an account at Maskbreak signup and configure MASKBREAK_API_KEY in your hosting platform's server-side environment or secret store. Configure each environment deliberately; having a key in a local preview does not configure production.

Give the assistant the variable name and public documentation, never the key value. Keep secrets out of prompts, screenshots, source files, browser-exposed environment variables and logs. OWASP's secrets guidance covers restricted access, managed storage and avoiding plaintext logging. If you already exposed a key, revoke or rotate it and update the affected deployment.

What evidence must the actual site send?

The current integration guide explains both ordinary forms and custom submissions. After the SDK loads, window.Sentinel.collect() returns token, fingerprintEventId and optional tz. Ordinary enriched forms use monocle and sentinel_fp for the first two fields. Forward the real values to your backend, which calls POST /v1/evaluate.

Full evidence means checking the returned network and device fields, not merely sending two identifiers. Device resolution can fail; there is no API complete or live boolean to invent. The raw HTTP example forwards timezone; the current server SDK helpers do not. A bare-IP lookup is not a substitute for the live network-and-device check.

What prompt can I copy into my AI coding assistant?

The following is a secret-free implementation prompt, not executable application code. Identify your protected action in the conversation before using it. It asks for evidence the assistant can report without disclosing credentials or raw browser tokens.

Add Maskbreak protection to the action I identified in this app.
Read https://maskbreak.com/integrate.md and the existing action handler first.
If the action or backend is unclear, ask me to identify it.

Keep authentication, authorization, MFA, CSRF protection, validation and rate
limits. Identify every route that can perform the action, including social
login callbacks or alternate submission paths where relevant.

I will configure MASKBREAK_API_KEY in server-side secret storage. Use that
variable name. Do not read secret files, print keys, request keys in chat,
or expose secrets in frontend code, logs, screenshots or test reports.

Collect real token and fingerprintEventId evidence on the actual page.
Forward both through our backend to POST /v1/evaluate; preserve optional tz
when supported. Never replace missing evidence with demo values.

Validate the response against the documented contract. Require the network
and device fields needed by our policy; reject malformed, degraded, test,
sample and sandbox results as authorization for the protected action.
Do not invent live or complete response flags.

Route on decision: allow continues through existing controls; block refuses;
review holds the action for server-verified additional checks. Bind review
completion to the account and action. Never trust a browser passed flag.
Use bounded timeouts and an explicit unavailable state. Preserve duplicate
submission protection. Do not grant benefits on errors or HTTP 429.

Test branches safely in staging. After an authorized deployment, verify the
real page and backend with my test account. Report the deployed URL, action,
routes, dated test results, sanitized evidence of collection and enforcement,
and unresolved limitations. A build, console event or demo is not completion.

How should the generated app handle the result?

For the tutoring-credit example, a usable live allow continues to the existing eligibility check. Review keeps credits pending while your backend verifies the required account check. Block refuses the grant. Missing evidence or an unavailable API leaves it pending with a recovery message. These are application rules you implement, not UI screens the API installs.

A VPN alone yields review in the base policy; account rules and exceptions can change the final decision. Network service names appear when known. The risk score is not a fraud probability, and the legacy isSuspicious flag is not the final policy result.

An allow never authenticates someone or authorizes another user's resources. Keep the layered controls described in OWASP's authentication guidance, including appropriate MFA and login throttling.

What must pass before I accept the work?

• Real collection: on the deployed page, both evidence fields reach your backend and required network/device results resolve. Check the site's content security policy and blocked-script behavior.
• Real enforcement: correlate a controlled live evaluation with the protected action. A Maskbreak console event proves neither route coverage nor that a hold stopped a benefit.
• Failure branches: in staging, test review, block, timeout, malformed responses, HTTP 401/403/429, missing evidence and test/sample/sandbox results. None may silently release the benefit.
• Bypass resistance: try direct endpoint submissions, forged review flags, expired approval and duplicate requests. Verify account checks, permissions and existing rate limits still apply.
• Clear evidence: retain the test date, deployed version, route, expected result and observed outcome without secrets. Separate fixture results from live checks and record unresolved failures.

Use your own test accounts and harmless actions. Fixture success tests decision handling; a live check tests integration. Neither establishes a detection-rate or latency guarantee.

Can I start without a paid plan?

Yes. Maskbreak is free during open beta, with 1,000 visitor checks per hour and no card. Evaluation and authenticated IP lookup share the key's allowance. Budget for repeated protected actions, handle quota exhaustion explicitly, and keep rate limits ahead of the external check.