An AI-built internal tool is not ready for real work because its main screen loads and the happy path completes. It is ready for a controlled pilot only after your team has tested who can see each record, who can perform each action, what happens when input or a connection fails, where secrets are kept, what gets logged and how you recover from a bad change.
The standard is evidence. “We have role-based access” is a promise. A test user being denied another role’s record is evidence.
This checklist helps an operations owner decide among three outcomes:
- Keep the tool as a demo with synthetic data.
- Run a limited pilot with named users and low-consequence work.
- Ask for a deeper production and security review before sensitive or consequential use.
It is not a penetration test, security certification or compliance assessment. The depth of review should rise with the consequences of failure. The UK National Cyber Security Centre makes the same distinction in its vibe-coding spectrum: a disposable prototype needs less oversight than authentication code, authorization logic, personal-data processing or software that handles credentials.
Start by writing down the boundary
Before reviewing controls, describe what the tool will actually touch.
Name the records it stores. List every person and system that can send information into it. Identify the actions it can take outside itself, such as sending an email, creating a document, updating another system or initiating paid work. Then state the worst credible result if the wrong person sees a record, if an action runs twice or if the tool is unavailable for a day.
This turns “small internal app” into a risk decision. A lunch-order form and a claims approval queue may have the same number of screens. They do not need the same review.
The NCSC’s guidance for choosing a cloud provider recommends matching the level of confidence you require to the impact of disclosure, corruption and outage. Use that principle here. If exposure, alteration or downtime would materially harm a person or the business, stop treating the app as an informal experiment.
The nine checks to complete before a pilot
For every applicable row, collect the evidence in the middle column. A verbal assurance is not enough for a stop-ship control.
| Control area | Evidence to request or create | Stop-ship condition |
|---|---|---|
| Data boundary | Sign in as users from two roles or workspaces. Try to open each other’s records by changing links, identifiers and requests, not only through the visible menu. | A user can read or alter a record outside the approved boundary. |
| Identity | Create, disable and remove a test user. Retry an old session and a saved link after removal. | A removed or unauthenticated user can still enter or act. |
| Permissions | Build a role-action matrix, then test one allowed and one forbidden action for every role. | The interface hides an action but the server still accepts it. |
| Inputs and files | Submit missing, oversized, duplicated and malformed values. Upload a wrong file type and a file belonging to another record. | Invalid input changes live data, exposes an internal error or attaches to the wrong record. |
| Secrets and connections | Inspect browser requests, delivered source and logs for keys or tokens. Ask where each connection is stored, scoped, rotated and revoked. | A reusable secret is present in browser code, source, chat history or logs. |
| Dependencies | Obtain the dependency list and current audit result. Ask why new packages were added and who reviews updates. | The team cannot identify what third-party code runs or whether known vulnerabilities were checked. |
| Logging | Complete, reject and retry an important action. Confirm the record identifies the action, time, actor and result without recording sensitive content unnecessarily. | A material action cannot be reconstructed, or logs expose credentials or private data. |
| Recovery | Release a harmless change in a working environment, restore the previous version and verify the critical path. Document external actions that rollback cannot reverse. | There is no known previous version, no authorised recovery path or no owner for reconciliation. |
| Ownership | Name the business owner, backup owner, reviewer and person allowed to release. Confirm where the current workflow brief and decision record live. | The app depends on one person’s account or memory. |
These controls follow established guidance rather than a special set of rules invented for AI. The OWASP Authorization Cheat Sheet recommends least privilege, denial by default, authorization checks on every request and tests for authorization logic. The OWASP Secure Code Review Cheat Sheet covers input validation, authentication, authorization, secrets, files, dependencies, error handling, logging and business logic.
AI changes how the code was produced. It does not remove those obligations.
Prove that access is enforced behind the screen
Authentication answers “who are you?” Authorization answers “what may you do here?” A tool can have a polished login screen and still fail the second question.
Begin with a small role matrix. For an approval workflow, it might look like this:
| Action | Requester | Reviewer | Workspace owner |
|---|---|---|---|
| Create a request | Allowed | Allowed if the process requires it | Allowed |
| View own request | Allowed | Allowed when assigned | Allowed |
| Approve a request | Denied | Allowed when assigned | Defined by policy |
| Change roles | Denied | Denied | Allowed |
| Release an app change | Denied | Denied unless explicitly assigned | Allowed if assigned |
Test the denied cells directly. Change a record identifier in the URL. Retry a captured request as the wrong role. Attempt the action after the user has been removed. If the only protection is that a button disappeared, the control is cosmetic.
KasiLabs is built around this distinction. Workspace and project permissions are checked on the server, and building, reviewing and releasing can be assigned separately. New work starts in a private version; it does not become the live app merely because someone changed it. You can review how the process works and the current access and release controls.
That design reduces accidental exposure, but it does not choose your roles for you. A workspace owner still has to decide who needs access, remove people who no longer need it and test the boundary around the real workflow.
Treat AI-generated tests as a starting point
An AI builder may produce a test suite. Do not accept a green result without reading what the tests prove.
The OWASP Secure Coding with AI Cheat Sheet warns against using AI-generated test suites as security evidence by themselves. It recommends independent negative and adversarial cases, including invalid inputs, expired tokens, malformed requests, boundary conditions and concurrent access. It also calls for manual review of security-critical tests covering authentication, authorization, input validation and cryptographic operations.
For an operations team, that means writing failure cases in business language:
- A reviewer tries to approve a request assigned to someone else.
- A requester submits the same action twice after a slow response.
- A user opens a saved link after their access has been removed.
- A connection times out after the remote system accepted the request.
- Two people change the same record at nearly the same time.
- A required document is missing, corrupt or attached to the wrong case.
- A paid action reaches its limit halfway through a broader workflow.
Record the expected result before asking the builder to implement or test it. Otherwise, the same system may define the behaviour, write the code and declare that behaviour correct.
Keep secrets out of the app and out of the conversation
API keys, database credentials, signing keys and access tokens should not sit in a browser bundle, a prompt, a screenshot or a shared document.
OWASP’s secrets-management guidance calls for centralized storage, fine-grained access, rotation, revocation, expiry and auditability. Its AI-coding guidance adds an immediate concern: coding assistants can read more project context than the file a person thinks they are sharing. A .gitignore file does not stop an AI tool from reading a secret on the local filesystem.
Ask for a connection inventory with five fields:
- What service does this connection reach?
- What is the minimum permission it needs?
- Where is the credential stored?
- Who may rotate or revoke it?
- What stops working when it is revoked?
KasiLabs apps use approved managed connections so sensitive account keys do not need to live in browser code or in the app’s own source. Customers choose which capabilities a project may use, and paid requests are checked against set limits. This is useful containment, particularly for an operations team that does not want to manage several provider credentials inside every app.
It is not permission to turn on every available connection. Start with the smallest useful set, test what happens when one connection fails and document which person owns the external account.
Review every dependency and every changed file
AI tools can add a package because it looks plausible, select an outdated version or alter an unrelated build file while working on a feature. A reviewer focused only on the new screen may miss the change with the larger blast radius.
OWASP recommends verifying that every suggested package exists, checking its maintainer and release history, auditing it for known vulnerabilities and pinning updates through the normal dependency process. It also recommends reviewing the complete change, with extra scrutiny for build scripts, package scripts, deployment configuration and agent instruction files.
Ask the builder for:
- The complete list of changed files.
- New and removed dependencies, with a reason for each.
- The dependency and secret-scan result for the release candidate.
- Any changes to build, deployment, permission or AI-agent instruction files.
- The named reviewer who examined those changes independently.
KasiLabs puts a verification step before release and records the reviewed release. That gives a customer a specific version to approve rather than an open-ended promise that “the latest changes” are ready. The approval still has to be informed. A release record is valuable because it anchors the evidence to one version.
Know what the logs prove and what they must not contain
Useful logging lets an owner answer: what happened, when, under whose authority and with what result?
The CISA Secure by Demand Guide encourages software buyers to ask for security logs and software supply-chain evidence as part of the product, rather than accepting security as an unverifiable assertion. Logs can support incident investigation and accountability. They can also create a second data leak if they contain credentials, full private records or unnecessary prompt content.
Test one action from end to end. Create a request, approve or reject it, trigger one allowed connection and retry a failure. Then inspect the record available to the workspace owner. It should contain enough context to reconstruct the decision without copying every sensitive field.
KasiLabs records material access changes, approvals, releases and paid-usage actions. That supports a reviewable operating history. It should not be described as a compliance certificate, and customers still need a retention policy appropriate to their data and jurisdiction.
A rollback plan needs an external-action boundary
Returning to a previous application version can restore earlier behaviour. It cannot unsend an email, reverse a bank transfer, retrieve a file already shared or erase a change already accepted by another system.
Before release, divide actions into two columns:
- Actions restored by returning to the previous app version.
- Actions that require reconciliation in another system.
For the second column, define duplicate protection, retry behaviour and a named recovery owner. If a connection times out, the app must not blindly assume that nothing happened. The external service may have completed the request before the response was lost.
KasiLabs keeps earlier revisions and supports a deliberate rollback path to a previous deployment. It also keeps the approved release and relevant decision record. This makes a way back visible. It does not pretend that application rollback reverses the outside world.
Stop the release when evidence fails
Do not average away a failed authorization test because the interface is good or the app saves time.
Keep the tool private if any of these remains true:
- One user can see another workspace’s or restricted role’s record.
- A protected action succeeds when called directly by the wrong role.
- A removed user or old session still works unexpectedly.
- A credential appears in source, browser code, prompts or logs.
- The dependency list or release change cannot be explained.
- Important actions cannot be reconstructed.
- The team cannot restore a known previous version.
- No business owner and backup owner accept responsibility for the app.
Fix the failure, rerun the exact test and attach the new evidence to the release decision.
Build the evidence into the way the app is released
KasiLabs is designed for teams that want AI-assisted speed without turning every generated draft into live software. Describe the workflow in plain words, including what must never go wrong. Test a private working version with realistic and awkward records. Choose who may use it, which actions they may take and where paid work stops. Review the exact release, then approve it deliberately.
That sequence does not guarantee security. It gives owners and reviewers a practical place to enforce the checklist instead of trying to reconstruct controls after the app is already carrying real work.
Describe one sensitive workflow in KasiLabs and keep it private until its data boundary, roles, failure cases, connections and recovery path have all produced evidence you can accept.
Sources
- OWASP Secure Coding with AI Cheat Sheet, accessed 12 August 2026.
- OWASP Authorization Cheat Sheet, accessed 12 August 2026.
- OWASP Secrets Management Cheat Sheet, accessed 12 August 2026.
- OWASP Secure Code Review Cheat Sheet, accessed 12 August 2026.
- NCSC: Choosing a cloud provider, accessed 12 August 2026.
- NCSC: The vibe-coding spectrum, published 18 June 2026; accessed 12 August 2026.
- CISA Secure by Demand Guide, accessed 12 August 2026.