Vibecodr Security Model
Runnable code only feels playful when the room has edges. Vibecodr lets people open, share, and remix strange little apps while keeping accounts, secrets, platform controls, and backend capability behind explicit boundaries.
A public vibe is easy to press play on. A trusted Pulse is where private work belongs. The line between them is the point: open enough to experiment, sealed enough that someone else's code does not become a key to your account.
Browser code, trusted backend work, secrets, web requests, and incident response all have different risk. Vibecodr keeps those differences visible instead of smoothing them into trust theater.
Vibe sandbox
Published client code runs in an isolated runtime frame on a separate origin. It can be fun, strange, and public without getting ambient access to Vibecodr cookies, account state, platform data, or another project on the page.
Pulse boundary
A Pulse public endpoint runs inside a guarded room: source, secrets, route setup, logs, and platform wiring stay owner-side. Platform resources stay protected, but deployed Pulse endpoints are public HTTP by default. Add checks in code when a behavior should not be open to arbitrary callers.
Secrets
Secrets are for Pulses, not browser code. The safe path is a mediated request such as env.fetch(url, { auth: env.secrets.bearer("KEY") }), where Vibecodr attaches the credential server-side instead of handing the raw value to public runtime code. Saved secrets are encrypted at rest and write-only: once you save one, the raw value is never shown or returned again.
Network edges
Pulse web requests are shaped by an outbound policy boundary: infrastructure hosts and private addresses stay blocked, redirects are re-checked, and secret-backed responses have redaction and size limits so one convenient API call does not become a leak path.
Response
The platform has separate lanes for content reports, product bugs, and vulnerability disclosures. That separation keeps everyday moderation human, and keeps security reports private enough to include exact reproduction details.
Security here is not a vague promise that all code is harmless. It is a set of places where the platform says: this can be public, this needs mediation, and this stays out of reach.
Browser runtime
The player, embeds, and vanity runtime surfaces preserve the same basic boundary: the vibe can run, but it does not inherit the host page's account authority.
Trusted backend
When a project needs trusted work, it earns a backend lane. That keeps the public artifact inspectable and keeps the sensitive work in a narrower surface.
Files and media
Scriptable formats are treated carefully, content types are not guessed loosely, and public media routes stay bounded to the variants the platform actually supports.
Operator signals
Errors, moderation outcomes, and runtime events use safe handles and redaction rules, so investigation can happen without turning logs into a second copy of user code or secrets.
This page is the readable map. The linked docs, policies, tests, and implementation carry the exact contracts when a boundary changes.
Short answers for the places where marketing copy should stop hand-waving and say the plain thing.
No. Published vibes run in a separate, sandboxed runtime surface. They can render and make ordinary browser requests, but they do not get ambient access to your Vibecodr session, account data, or other projects on the page.
No. A deployed Pulse endpoint is public HTTP by default, while source, secrets, setup, and operational metadata stay owner-only. If a Pulse behavior should be restricted, the Pulse code should validate authentication, signatures, payloads, and rate expectations for that behavior.
They belong in Vibecodr secrets and server-side Pulse code, not in public browser code. Public code can ask a Pulse for help; the Pulse can call the provider with policy-bound secret handling.
Use the vulnerability disclosure path for concrete security weaknesses, suspected boundary breaks, private-data exposure, bypasses, or reproducible exploit paths. Use the content and bug-report lanes for ordinary moderation or product issues.
No. This is the readable map. The exact behavior lives in the linked docs, policies, tests, and platform implementation, and those are the sources Vibecodr keeps aligned when a boundary changes.