No access-control bypass
CAPTCHA, 2FA, Passkeys, and identity verification always require a person.
Security boundaries
Automatic Where It Is Safe. Human Where It Matters.
Vibe Launch Master runs directory submissions through a dedicated Chrome profile, keeps directory passwords in Chrome Password Manager, keeps AI keys in the operating system credential store, limits browser actions to audited targets, and stops for CAPTCHA, 2FA, Passkeys, payment, identity verification, or unknown high-risk terms.
Automatic browser execution
The browser follows an approved path and stops at every high-risk boundary.
Submissions run through a dedicated Chrome profile controlled by the local app. Directory passwords remain in Chrome Password Manager.
[✓] Open only the active target allowlisted host
[✓] Use the dedicated Chrome profile and normal website session
[✓] Perform inspection, navigation, fill, select, and upload as allowed
[✓] Pause for CAPTCHA, 2FA, Passkey, identity, payment, or unknown terms
[✓] Verify the final destination state before recording a result
[✓] Never repeat a final submit when the outcome is unknown
Status: Controlled workflow ready
No automatic payment
Card entry, paid placement, renewal, and paid-only submission remain blocked.
No unknown high-risk legal action
Ownership transfer, exclusive licensing, or unclear commitments stop for review.
No repeat submit when uncertain
The app records an unknown outcome and does not assume that the first action failed.
Credential and data location
Passwords, AI keys, working material, cloud metadata, and registry data have different boundaries.
The design avoids treating every piece of campaign data as one cloud record or one privileged application secret.
Storage boundary
Where the data or credential belongs.
Explicit exclusion
What Vibe Launch Master does not do with it.
Field Storage boundary Explicit exclusion
Directory passwords Chrome Password Manager in the dedicated local profile. Not copied into a Vibe Launch Master cloud password vault.
AI provider keys Operating system credential store. Not placed in prompts, logs, receipts, screenshots, product copy, or website source.
Working material Local source snapshots, Launch Master versions, temporary assets, activity events, and checkpoints. Sensitive evidence must be masked before any optional synchronization.
Cloud metadata Minimal identity, project, signed capability, release, summary, and receipt-index data when required. The released implementation and published retention policy remain authoritative.
Registry release One versioned signed release bound to the campaign. Cannot be silently replaced while the campaign is running.
Trust boundary
Local browser visibility, limited capability, and evidence-aware claims work together.
Security is described through observable architecture and explicit exclusions rather than unsupported certification language.
Browser boundary
Real Chrome, visible handoff
Directory websites run in a dedicated Chrome profile on the user’s computer rather than a privileged app WebView or disguised cloud session.
- Normal website behavior
- One write owner
- User can take over the real window
Capability boundary
Signed and host-scoped actions
Inspection, navigation, click, fill, select, upload, download, and final submit are limited to approved campaign hosts and operations.
- Active target allowlist
- Campaign-scoped capability
- Revocable connections
Claim boundary
No unverified certification claim
The website does not claim zero telemetry, end-to-end encryption, SOC 2, ISO 27001, or another certification without independent verification.
- Visible limitations
- Released behavior is authoritative
- Corrections update shared facts
Where does browser automation run?
Directory websites run in a dedicated Chrome profile on the user’s computer. The desktop app coordinates the workflow through the approved browser bridge and does not load arbitrary third-party directories inside a privileged application WebView.
What data can be stored locally?
Local data can include working documents, source snapshots, Launch Master versions, temporary asset variants, browser artifacts, detailed activity events, campaign checkpoints, and local credentials. Sensitive browser evidence must be masked before any optional synchronization.
What minimal data can be stored in the cloud?
Cloud data can include identity and organization metadata, minimal project metadata, signed capability records, registry-release metadata, release information, minimal campaign summaries, and receipt indexes. The exact released implementation remains authoritative for retention and telemetry fields.
What happens when a submission result is unknown?
The app records an unknown-outcome state and does not click final submit again. The user can inspect the real browser and the app can revalidate the destination state, but it cannot assume failure and create a duplicate listing or account action.
How can a user revoke access?
Users can disconnect the launch inbox, AI provider, dedicated browser profile, or account session. Revocation stops future capability use; durable receipts may remain when required to explain completed actions, subject to the published privacy and retention policy.