Does an AI-built app need its own quality standard?
The NIST Secure Software Development Framework 1.1 sets out secure development practices across the whole software lifecycle rather than for a particular language or coding tool.[1] OWASP ASVS 5.0 likewise verifies whether technical controls — authentication, authorization, input, data protection, dependencies, logging — actually work, not which tool wrote the application.[6] The framework is moving to a 1.2 draft[2] and a community profile exists for generative AI and dual-use foundation models,[3] yet the verification practices themselves do not fork by tool.
AI coding does not replace this standard. It surfaces six questions earlier. Can the author explain every behaviour of the code and configuration? Are authentication and authorization applied on the server and not only on screen? Which external packages and APIs were added? Do secrets stay out of the browser, the repository, and the logs? Are failure, retry, and duplicate requests designed alongside the success path? Can a problem be found and undone after deployment?
DORA's 2025 research describes AI as an amplifier of an organization's existing strengths and weaknesses alike.[5] NIST's 2026 discussion of AI-assisted coding proposes supplying non-negotiable constraints and domain rules explicitly.[4] Verification principles do not change because AI was used; the need to state requirements and constraints that were left implicit simply grows.
Draw the failure boundary before the feature list
Before setting scope, attach seven questions to each feature. If any answer crosses a user, tenant, money, or external-system boundary, confirming that it works on screen is not enough.
You have to call the API directly, change identifiers, repeat the same request, and put the external system into a slow or failing state. What sets the verification scope for an AI-built app is not who wrote the code but how many of these boundaries it crosses.
Question to ask | Condition that forces deeper verification |
|---|---|
| Who can run this feature? | There is a boundary between anonymous, ordinary, other-tenant, and admin users |
| Whose data and state does it touch? | It reads or changes personal data, other users' data, per-tenant data, or critical business records |
| Does it produce an external effect? | Payment, refund, messaging, external API updates, file deletion — results land outside the app |
| Is the failure reversible? | Deletion, transfer, dispatch, permission change: automatic cancellation is hard or restoration is unclear |
| What happens if the same request repeats? | Refresh, retry, network timeout, or job re-run can produce duplicate results |
| Would you notice a problem? | No logs or alerts surface failure, misuse, or omission before a user reports it |
| Can you recover? | Backups exist but the restore procedure is unverified, or there is no way back to the prior state |
Verify the paths beyond the happy path — Reconstruct requirements from behavior and exercise exceptions in input, permissions and external calls.
How to split verification depth into three levels
The three levels here are not a release verdict for the whole app. They separate how much evidence each risk area needs.
A release-blocking area cannot pass on the happy path alone. It needs evidence from actually running unauthorized requests, tampered values, duplicate requests, timeouts, partial failures, and the recovery path. "Improve later" does not mean "no verification". It means the risk area does not exist in the feature, or the required controls are already verified and only the remaining improvement can wait.
- Verify before release
- The range that must be confirmed before the feature is exposed at all, because failure means account takeover, privilege escalation, exposure or alteration of others' data, financial loss, secret leakage, or an external effect that cannot be undone.
- Verify further on condition
- The range where baseline controls work but usage or scale widens the scope — multiple tenants, several roles, social login, subscription billing, bulk operations, asynchronous processing, and provider outages are the conditions.
- Improve later
- The case where the minimum safety bar is already met and the remaining improvements do not change access control, data integrity, financial effect, detection, or recovery. It does not mean no verification is needed.
How are the twelve risk areas divided?
The matrix below reorganizes the risk and verification items of OWASP ASVS 5.0, OWASP Top 10:2025, API Security Top 10:2023, and the Web Security Testing Guide 4.2 for pre-release scope decisions.[6][9][10][8] The names of the three levels and the way they are sorted are this article's decision framework, not an official OWASP or NIST scoring scheme.
Risk area | Verify before release | Verify further on condition | Improve later |
|---|---|---|---|
| Authentication | With accounts or protected features, check signup, login, logout, session expiry and revocation, account recovery, auth bypass, and user enumeration. An authenticated API must refuse a direct call with no session. Admin and sensitive functions need re-authentication proportional to risk. | Social login, OIDC, SSO, account linking, multi-device sessions, credential changes, lost recovery factors, and long sessions each add failure and takeover scenarios. | Passkey rollout, session management screens, and login copy come after baseline authentication, recovery, and session control are verified. |
| Authorization | With multiple users, tenants, roles, or private objects, test horizontal and vertical escalation directly. Changing a URL or object id and calling the API must not reach another user's or tenant's data or run admin functions. Authorization is deny-by-default on the server. | Share links, ownership transfer, role delegation, support impersonation, bulk read and edit, and tenant moves require checking permissions across the state transition. | Convenience in the role management screen and clearer permission copy wait until the server authorization model and audit trail are verified. |
| Data read, write, delete | When personal, tenant, or business records are handled or data is changed and deleted, check ownership, tenant isolation, input validation, concurrent edits, partial failure, transaction handling, deletion range, and restorability. Verify read, write, and delete rights separately. | Import and export, bulk edits, retention periods, data migration, consistency between search index or cache and source, and cross-system sync widen the exception and reprocessing range. | Draft history, diff views, and convenient restore screens come after data integrity and a real recovery path exist. |
| Payments and financial effect | With any payment, refund, points or credits, or paid entitlement, verify amount, currency, and order-owner checks, client-side tampering, duplicate submission, retries and timeouts, idempotency, webhook forgery and replay, refunds and compensation, and reconciliation. A success screen is not enough. | Subscription renewal, partial refunds, coupons, tax, proration, payment method change, receivables, and cancellation disputes add state combinations and accounting or entitlement consistency. | Receipt screens, payment analytics, and copy come after transaction integrity, duplicate prevention, and reconciliation are verified. |
| External APIs | When an external API touches authentication, payment, core data, messaging, or external state, check credential scope, request and response validation, timeouts, retries, duplicate handling, webhook verification, internal state on failure, abnormal responses, and partial success. Never decide internal permissions or amounts by trusting an external response. | Provider outages, rate limits, API version changes, sandbox and production separation, and fallback or degraded modes call for extra verification. | For lookups that leave core state untouched on failure, improve user messaging or fallback UI once isolated failure handling is verified. |
| Secrets and credentials | With production API keys, database credentials, signing keys, or admin tokens, check that none leak into source, repository history, browser bundles, error responses, or logs. Separate development, staging, and production, and verify least privilege plus revocation and rotation paths. | Short-lived credentials, automatic rotation, secret inventory, break-glass access, and per-tenant or per-service key separation widen lifecycle verification. | Expiry alerts, rotation automation, and management metadata come after safe injection, separation, and revocation are verified. |
| Dependencies | Verify deeply until resolved when a package on a critical path — authentication, cryptography, payment, file handling — has unclear provenance, when a known critical vulnerability sits on a reachable path, or when an install script does more than it should. Also check build reproducibility and lockfile-to-artifact agreement. | Transitive dependency inventory, SBOM, private registries, update policy, licensing, abandonment, package name confusion, and supply chain changes are the additional checks. | Vulnerability dashboards and update automation come after known critical issues and core dependency provenance are handled. |
| User input | When input reaches a database, HTML, files, commands, external URLs, another user's screen, or an external tool, check server-side validation, context-aware output encoding, query parameterization, upload limits, SSRF, size and resource limits, and abnormal business flows. Never trust browser-side restrictions alone. | Rich text, archive and format conversion, URL fetching, multilingual and Unicode input, bulk input, user-to-user content sharing, and automated repeat requests widen verification. | Help text, instant client-side validation, and input conveniences come after server validation and safe handling are in place. |
| Administrative functions | With an admin screen or an operations API, check server authorization separate from ordinary users, re-authentication for sensitive actions, audit records for role change, bulk edit, and deletion, session and CSRF defences, and break-glass accounts with a recovery path. A hidden URL is not access control. | Role delegation, support acting on behalf, impersonation, bulk export, batch permission change, and approval workflows add actor identity and approval, revocation, and audit scope. | Admin search, filter, and report convenience come after access control and auditability are verified. |
| Background jobs | When a job changes or deletes data, takes payment, grants permissions, sends messages, or syncs externally, check duplicate-run prevention, idempotency, retries and backoff, partial failure, concurrent execution, isolation and reprocessing of failed jobs, execution rights, and result tracking. | Scheduling windows, delayed execution, out-of-order runs, backfill, bulk reprocessing, external quotas, and recovery after a worker restart add scenarios. | Job status screens and operational automation come after failure detection and a safe reprocessing path exist. |
| Logging and monitoring | Authentication failures, authorization denials, admin actions, payments and refunds, data deletion, and critical job results must be traceable. You need identifiers linking requests to jobs, the alerts you actually need, and log protection — and passwords, tokens, and sensitive personal data must not be written. | Retention, anomaly detection, on-call paging, per-tenant audit, correlation with external service status, and log cost at scale are designed next. | Richer dashboards and analytics come after minimum detection, audit, and alerting work. |
| Rollback and recovery | With destructive data changes, incompatible migrations, or critical configuration and credential changes, actually exercise restoring the previous artifact and configuration, backup restore, data consistency checks, forward recovery, and compensation for external effects. "We have backups" is not enough. | Feature flags, canaries, partial rollback, job replay, degraded modes during provider outages, and user communication during recovery widen the scope. | Automating a verified manual recovery or shortening recovery time can wait, provided the current path actually works and limits the damage. |
Turning the matrix into an actual scope
First, write actors and assets rather than features. Instead of screen names such as "membership" or "payments", break each one into actor, data read, state changed, external effect, and impact on failure. Only then does it become visible how authentication, authorization, data, money, external APIs, and background jobs connect inside a single feature.
Second, mark inapplicable areas as N/A explicitly. Not every app has all twelve. A static brochure page with no login and no stored data has N/A for authentication, authorization, and payments. But if it has a contact form, user input, the external mail API, secrets, and abuse prevention still apply. Conversely, calling something a beta does not let you mark an area N/A while real accounts, personal data, and payments exist.
Third, follow the deepest applicable condition in each area. Do not average. Safe payments do not offset a broken admin permission. Editing your own profile looks like a plain data change — but if changing the user id in the request edits someone else's profile, authorization and data isolation both have to be verified deeply.
Fourth, produce evidence for normal, misuse, failure, and recovery separately. Does normal input with normal permissions give the intended result? Are unauthorized users and tampered requests refused? Are timeouts, duplicate requests, external outages, and partial failures handled safely? Can the problem be detected and reprocessed or recovered afterwards? Automated scanners are useful for finding a wide field of candidate problems, but they cannot alone prove business meaning such as order-owner checks, duplicate refunds, cross-tenant isolation, or partial failure in a background job. ASVS works better as the source of requirements to verify and the Web Security Testing Guide as the source of real attack and misuse scenarios.[7][8]
Feature | Actor | Data read | State changed | External effect | Impact on failure |
|---|---|---|---|---|---|
| Order payment | Signed-in user | Product, order, payment state | Order state, paid entitlement | Payment authorization, webhook | Double charge, entitlement not granted, access to another's order |
| Admin refund | Administrator | Customer, order, payment records | Refund and order state | Refund request to the PSP | Unauthorized refund, duplicate refund, internal state mismatch |
| Scheduled notification job | Background worker | Schedules, contacts | Delivery state | Message dispatch | Duplicate sends, omissions, personal data in logs |
Verification that supports a release decision — Verify critical journeys and connect observed results and remaining conditions to the release decision.
If you cannot verify, reduce the feature's impact first
A small team cannot verify every feature at maximum depth from day one. The safe move then is not to keep a high-risk feature public and cut the tests; it is to genuinely limit what that feature can do.
Use a sandbox or manual payment confirmation instead of real payments. Put data-changing features into read-only. Run on synthetic data instead of real personal data. Replace open signup with a server-enforced invite list, and put manual admin approval in front of external dispatch and deletion. Turn off bulk operations and automatic retries, and drop risky admin functions from the first release.
These limits have to be enforced in server and operational configuration, not in on-screen copy. Telling users to be careful because it is still a beta does not substitute for access control or data protection.
Common errors in setting scope
The first is using screen count as test scope. Even a single screen needs deep verification if it deletes data or takes payment with admin rights. Conversely, several read-only screens are a narrow scope.
The second is checking login and believing authorization was checked. Login confirms who the user is. Whether that user may touch a particular order, file, tenant, or admin function is a separate question, and tests that change an object id or tenant id in the API are the ones most often skipped.
The third is only checking the external API's success case. The real risk in an external API shows up in slow responses, duplicate callbacks, ambiguous success states, and partially completed work. For payments, dispatch, and data sync, the internal state after a failure has to be checked too.
The fourth is treating an AI's review of its own code as final evidence. AI explanations and reviews can widen the list of candidates. But self-review resting on the same code and the same assumptions cannot independently prove authorization bypass, real production configuration, duplicate handling in external APIs, or recoverability.
Verification scope starts from failure, not from provenance
Being an AI-built app is no reason to verify every feature at the highest level. Being built quickly is no reason to close out authentication, authorization, data, payments, integrations, and recovery with a short checklist either.
The more boundaries the app crosses, the deeper verification goes. Does it cross another user's or tenant's boundary? Does it read, change, or delete important data? Does it move money or create an external effect that is hard to undo? Does it handle secrets or admin privileges? Can a failure be detected and reversed?
Answering those questions sets the scope. Judging whether to actually release, on the evidence that scope produced, is the next step and belongs to the release decision.
