Use this checklist to inspect a Claude, ChatGPT, Lovable, Replit, Bolt, v0, Cursor, or other AI-assisted prototype before a pilot or public release. It covers ownership, access, data, common security risks, testing, deployment, recovery, and operating responsibility.
How to use this guide
For each item, record what you observed, where the evidence lives, who owns it, and what remains unknown. A setting visible in a dashboard, a test result, an access matrix, a restore exercise, or a deployment record is stronger than “the tool probably handles it.”
Prioritize by consequence. A cosmetic defect may wait. Broken authorization, leaked credentials, unrecoverable data, or a payment workflow that can double-charge a user should not.
This is a readiness and scoping checklist—not a penetration test, compliance certification, legal opinion, or guarantee of security.
12-part checklist
Not every product needs the same depth in every category. The intended users, data, transactions, availability, and regulatory context set the bar.
Name who can access the release, what they must accomplish, what data they will use, and what is explicitly outside version one.
EVIDENCE: one-page release brief, user roles, primary workflow, excluded scopeIdentify who controls the repository, hosting, domain, database, AI provider, email, payments, analytics, and third-party services. Avoid dependence on a contractor's personal account.
EVIDENCE: owner inventory, admin list, transfer plan, license and export notesProduction data and credentials should not be the default environment for experimentation. Document how configuration differs and how a release moves between environments.
EVIDENCE: environment list, deployment path, protected variables, release permissionsAuthentication answers who the user is. Authorization determines what that user may read or change. Hiding a button in the browser is not an access control.
EVIDENCE: role matrix, server-side checks, tenant isolation tests, session behaviorRotate any exposed key. Use server-side secret storage, least-privilege credentials, separate keys by environment, and restrictions where providers support them.
EVIDENCE: secret inventory, rotation record, repository scan, key restrictionsCollect only what the product needs. Identify sensitive fields, where they travel, who can access them, how long they remain, how users can correct or delete them, and what appears in logs.
EVIDENCE: data-flow diagram, field inventory, retention rules, deletion testTreat browser input, uploaded files, webhooks, URLs, model output, and third-party responses as untrusted. Validate on the server and encode output for its destination.
EVIDENCE: validation rules, file restrictions, output encoding, webhook verificationDefine what can enter a model, what the model may influence, when a human must review, how prompt injection or unsafe tool use is limited, and how usage or cost abuse is contained.
EVIDENCE: model data policy, tool permissions, review gates, quotas and alertsKnow which packages, APIs, and services the product relies on, their licenses, support status, limits, timeouts, retry behavior, and the product experience when they fail.
EVIDENCE: dependency inventory, lockfile, API limits, timeout and fallback testsCover account creation, sign-in, permissions, payments if applicable, saving and editing data, duplicate actions, interrupted requests, empty states, and recovery from errors.
EVIDENCE: acceptance cases, automated checks, exploratory notes, defect decisionsCapture useful errors without leaking sensitive data. Define health signals, alerts, release ownership, rollback or forward-fix strategy, and a simple incident path.
EVIDENCE: monitored errors, alert owner, deploy record, rollback exerciseA backup setting is not the same as a tested restore. Define acceptable data loss and recovery time, then exercise the path in proportion to the product's consequence.
EVIDENCE: backup owner, retention, restore result, recovery objectiveThis list is not exhaustive. It is a practical starting point for deciding what needs immediate evidence or specialist review.
| Risk | Why it matters | Evidence to seek |
|---|---|---|
| Secrets exposed to the browser or repository | Keys can be copied, abused, and used to access data or create cost. | Secret scan, rotation record, server-side storage, provider restrictions. |
| Client-only authorization | A user may bypass the interface and request another user's or tenant's data directly. | Server-side policy, role and tenant tests, database access rules. |
| Unvalidated input or unsafe output | Injection, cross-site scripting, malicious files, or corrupt state can cross trust boundaries. | Server validation, encoding, file controls, parameterized data access. |
| Over-privileged service credentials | One leaked or misused credential can expose more systems or data than the task requires. | Scoped roles, separate environments, narrow tokens, access review. |
| Sensitive data in logs or model prompts | Operational tooling and model providers can become unintended data stores. | Data-flow review, log sampling, redaction, retention and provider settings. |
| No abuse or cost controls | Public endpoints, AI calls, email, SMS, or storage can be automated by an attacker. | Rate limits, quotas, verification, anomaly alerts, spend caps where available. |
| Unmaintained or unknown dependencies | Vulnerabilities, licensing issues, or abandoned packages can create product and ownership risk. | Dependency list, lockfile, license review, update and replacement plan. |
| Untested recovery | Deletion, a bad migration, or provider failure can become permanent data loss or extended outage. | Restore exercise, export path, recovery owner, incident procedure. |
A text suggestion has a different risk than a model that can send email, query private data, edit records, run code, or purchase something. Review what context the model receives, which tools it can call, what it can change, what must be confirmed, and how untrusted content could influence it.
Prompt injection cannot be addressed by a prompt alone. Reduce authority, isolate data, validate tool inputs, require confirmation for consequential actions, and monitor outcomes.
Before writing policy language, identify what the product collects, why, where it goes, who receives it, how long it remains, and how a user can exercise relevant choices. A copied policy does not make the implementation accurate.
Use qualified security, privacy, legal, accessibility, or compliance specialists when the product handles regulated or highly sensitive data, high-value transactions, children's data, material safety decisions, or contractual security obligations. A general software review should make that need visible, not pretend to replace it.
Readiness levels
Use a narrower release boundary when the evidence does not yet support a broader one.
Use synthetic or disposable data. No promise of durability, privacy, availability, or account isolation. Access stays controlled.
Critical access and data controls are verified for the pilot. Limits are explicit, usage is observed, and a human recovery path exists.
Abuse, account recovery, privacy, accessibility, monitoring, failure handling, backups where needed, and ownership must be addressed in context.
Security, privacy, compliance, contractual, and operational requirements must be identified and verified by appropriately qualified people.
Prepare a review pack
Do not paste production passwords, private keys, API keys, or full sensitive datasets into email, calendar notes, or chat. Agree on a scoped and appropriate access method after fit and responsibility are clear.
FAQs
No. Security depends on implementation, configuration, data, dependencies, deployment, and operations. AI assistance changes how code may be produced, not the need to verify the result.
There is no universal single check. Identity and authorization, exposed secrets, data boundaries, server-side validation, dependency risk, and operational recovery are common high-impact areas.
No. It is a readiness and scoping tool. Products with higher consequences or obligations may require qualified security, privacy, legal, accessibility, or compliance specialists.
Possibly, if access, data, consequences, support, and limitations are tightly controlled and the unresolved risks are explicit. A pilot boundary is a risk decision, not a substitute for evidence.
A walkthrough, repository access if appropriate, intended user and workflow, data and integration list, ownership inventory, and launch constraints. Do not send secrets through ordinary messages.
Next decisions
AI prototype review
Bring the prototype, intended user, repository if available, data and integrations. The review starts by separating observed evidence from unknowns and ranking what matters before release.
Request a Fit CallDo not send secrets. This is not a penetration test or certification.