A polished dashboard can keep two customers visually separate while the application behind it treats their records as one large communal cupboard. The tabs look right. The menu hides the right buttons. Then one ordinary request asks for the wrong invoice and the server hands it over.

A useful vibe coding security audit should therefore test a simple commercial promise: Customer A cannot see or change Customer B's information. For an AI-built application, that promise must survive every route to the data, not only the screen used in the demonstration.

This guide describes a narrow, authorised test using fictional customers in an environment you own. It covers object permissions, lists and exports, file links, background work, membership removal and cached sessions. It is not permission to test somebody else's service, and it is not a comprehensive security audit. It is one focused way to discover whether the walls between customers are structural or chiefly decorative.

Why AI-built applications need a customer-boundary test

AI coding tools are excellent at completing local tasks. Ask for a project page, an export button and a document download, and each may arrive looking entirely plausible. The risk is inconsistency: one route checks the signed-in user's organisation, another trusts an organisation identifier supplied by the browser, and a third runs through a powerful background account that can see everything.

This is not a defect unique to generated code. Broken access control has kept human developers occupied for years. AI-assisted development can, however, produce features quickly across several layers, which makes it easier for slightly different permission assumptions to accumulate before anybody writes down the actual rule.

The rule should be plain enough to test: an actor may perform a particular action on a particular resource only within an authorised customer account. The OWASP Authorization Cheat Sheet recommends denying access by default and validating permissions on every request. A hidden button is helpful interface design. It is not a server-side decision.

Build a safe two-customer staging fixture

Run this work only in an approved staging environment using synthetic data. Freeze or record the release being assessed, take a backup if the test can alter data, agree who may run it and keep production integrations disabled or in test mode.

Create two fictional customer accounts, Northstar and Southbank. Give each an owner and an ordinary member. If the product has other meaningful roles, such as billing manager or external collaborator, include those too. Create clearly different test records in each account: projects, invoices, comments, saved searches, exports and uploaded files. Use harmless marker text that makes accidental mixing obvious.

Keep separate browser profiles or private windows open for the two customers. Record which account created every test object and its known identifier. OWASP's guidance for testing insecure direct object references similarly recommends two or more test users with different owned objects. There is no need to guess identifiers or scan unknown routes. You already control both sides of the boundary.

Before testing, write the expected permission rule for each important action. Keep it readable:

• Northstar members may view Northstar projects.
• Northstar members may not view, edit, delete or export Southbank projects.
• Northstar owners may invite or remove Northstar members but may not manage Southbank membership.
• A removed member loses access within the product's defined revocation period.

This small actor-resource-action list becomes the test oracle. Without it, a team can observe surprising behaviour and still spend an afternoon debating whether the surprise was intended.

Test server-side object permissions

Start with individual records. While signed in as a Northstar member, use only documented product flows and requests in the owned staging environment to ask the server for a known Southbank test object. Repeat the check for viewing, editing and deleting where those actions exist.

Do not stop because the Southbank project is absent from Northstar's navigation. Test the underlying request. The server should refuse the action without returning the other customer's content or making any change. It should also avoid revealing unnecessary details about whether the object exists.

Repeat the exercise across each role and object type. A sound check covers both horizontal boundaries, where two ordinary customers must remain separate, and vertical boundaries, where an ordinary member must not acquire an owner's powers. The OWASP Web Security Testing Guide treats both as distinct authorisation tests.

Follow the data into lists, search and exports

Detail pages are only one entrance. List endpoints, search indexes, dashboards, counts, autocomplete, reports and exports often use separate queries. Test them separately.

From Northstar, search for Southbank's unique marker text. Apply filters, sort orders and pagination. Generate a CSV or PDF export and inspect the contents, filename, metadata and any later download route. Check totals as well as rows: a dashboard that says there are 41 clients when Northstar owns four has disclosed something, even if it has kept the names to itself.

Then reverse the test. Customer separation should not depend on which account happened to be created first or which query path received the most attention. Empty filters and unusual combinations deserve particular care because an omitted customer condition can quietly turn “show my records” into “show records”. A computer will not add the missing possessive out of good manners.

Test files at the point of download

An application may protect the page that lists a file while leaving the file itself available through a reusable address. Upload distinct synthetic documents to both accounts. Copy a Northstar download link, then try it in a Southbank session and in a signed-out browser. Repeat after any link-expiry period the product claims to enforce.

The correct result depends on the design. The application might authorise every download, or it might issue a short-lived signed link after checking access. A signed URL is a bearer link: another browser may be able to use it until expiry by design. Judge that behaviour against the intended sharing and revocation rules, and test that only authorised users can obtain the link. Either way, possession of an old URL should not become permanent membership of the customer account. Check previews, thumbnails and transformed versions too; they sometimes travel through a different storage path while wearing the same filename.

Make background jobs prove their customer context

Exports, scheduled reports, imports, notifications and document processing often run after the user's request has finished. The worker may use a privileged service identity, so the original customer's context must be carried, validated and applied to the job.

Queue one job for each fictional customer. Confirm that the Northstar job reads only Northstar inputs, produces only Northstar output, stores it in the right place and notifies the right recipients. Repeat a job and simulate a safe retry. Then inspect the audit trail: it should connect the initiating user, customer, job and resulting artefact without recording secrets or unnecessary personal data.

OWASP's Multi-Tenant Security Cheat Sheet warns that privileged jobs must explicitly constrain their tenant scope. Database row rules cannot rescue a worker that deliberately uses a role allowed to bypass them.

Remove a member while their session is still warm

Revocation is where tidy permission diagrams meet cached reality. Sign in as a Northstar member and keep the session open. In a separate authorised owner session, remove that member from Northstar. Now retry an existing page, a direct request to a known object, a saved file link and any pending export.

Define the expected timing before the test. Some products require immediate revocation; others permit a short, documented delay. The important point is that the server, caches, tokens and workers reach the intended result within that period. Clearing the removed user's menu is not enough if an old session continues to retrieve data.

The OWASP Session Management Cheat Sheet recommends server-side session invalidation and renewing session identifiers after permission changes. Also check application and content-delivery caches: a correctly denied database query is little comfort if a shared cache has already prepared the wrong answer.

Turn each finding into evidence and a regression test

For every check, record the release, environment, actor, role, customer, resource, action, expected result and observed result. Retain the minimum useful evidence, such as a redacted response, screenshot, log reference or test output. Never place live tokens, private customer data or reusable download links in the report.

When a boundary fails, fix the server-side rule and add an automated test that proves both the allowed and denied cases. The OWASP authorisation regression guidance recommends a central, machine-readable access matrix and specifically identifies tenant-boundary failures as candidates for continuous testing.

Run those tests when permission logic, queries, caching, file storage or background work changes. “We tested it before launch” is an historical observation. Customer separation is a property the product must keep.

What this vibe coding security audit does not prove

Passing this exercise means the tested customer boundaries behaved correctly on the identified staging release. It does not establish that the whole application is secure. It does not cover every authentication flaw, injection risk, secret, dependency, privacy obligation, administrative route, infrastructure setting or business-logic failure. Higher-risk products may need source review, configuration review, specialist security testing and a wider assessment.

That limitation is useful rather than embarrassing. A narrow test can produce a precise answer. For guidance on defining broader scope and evidence, see how to commission an AI-built product audit. For the wider commercial evidence investors may examine, see Venturist's vibe coding due-diligence guide.

Customer separation should be demonstrated, not inferred

A founder should not need to trust that every generated feature remembered the same invisible boundary. Two fictional customers, carefully chosen roles and a small set of known objects can turn that assumption into evidence, expose inconsistent routes and leave behind tests that protect the repair.

If your AI-built product has teams, workspaces or customer accounts but nobody has tested the boundaries through records, exports, files, workers and live sessions, show Venturist what you have built. We can arrange a free introductory product review and define the wider audit needed before real customer data is invited in.