Safe vibes
Client code runs in a constrained environment.
Vibes run in a safe browser lane so public code cannot casually reach into platform state, cookies, or other private resources.
Security
People should be able to open a vibe without wondering what it can touch.
Runnable software only works in public if people can trust it. Vibecodr tries to make those safety boundaries visible, understandable, and hard to accidentally cross.
Your code runs in the browser in a safe runtime environment. Anything that needs secrets, private tokens, or trusted server access belongs on the backend side instead of hiding inside the vibe.
Security
Review sandboxing, policy boundaries, and platform guardrails that keep runnable user content safe by default.
Open, not loose
The promise is not that public code becomes harmless by vibes alone. The promise is that dangerous capability is kept behind clearer boundaries.
Trusted Pulses
Private capability lives on the backend side.
Secrets, integrations, and server-side operations belong in Pulses, where access can be controlled and reviewed.
Policy by default
Riskier behavior needs an explicit yes, not a quiet default.
Network access, embedding, and other sensitive paths are constrained on purpose so projects do not wander into unsafe territory by accident.
Response
Safety is not just prevention. It is also detection and follow-through.
Moderation, telemetry, and enforcement exist so the platform can react when something harmful, deceptive, or clearly unsafe shows up.
Where the line is drawn
Browser runtime, Pulse execution, secrets, embeds, moderation, and telemetry each carry different risk. This page keeps those differences visible instead of smoothing them into trust theater.
Capability mediation
The host decides what the vibe can ask for and how those requests are handled.
That keeps the public runtime predictable instead of letting random code negotiate its own rules on the fly.
Secret handling
Secrets should stay off the client.
If a project needs private tokens or protected APIs, the safe pattern is to keep that logic in Pulses instead of pushing it into browser code.
Consistency
The same trust model should hold wherever the project shows up.
Feed pages, player pages, docs, and embeds should not quietly switch to a weaker safety story just because the context changed.
Safety and growth
Permissive creation still needs clear guardrails.
People should be able to experiment freely without having to become security experts before they share what they made.
Read the boundaries
Security has product language here, but the linked docs and policies are where the exact behavior lives.
FAQ
Short answers for the places where marketing copy should stop hand-waving and say the plain thing.
Can vibes directly read platform secrets or storage?
No. Vibes are client-side and constrained. Trusted resources should be accessed through controlled backend paths in Pulses.
Why separate vibes and Pulses instead of blending everything together?
Because that separation keeps the public part easier to trust and makes it much harder to accidentally leak private capability into runnable client code.
Is embedding treated as a different security model?
No. Embedding extends public surfaces but should preserve the same runtime and policy constraints as first-party playback.
How does security relate to social openness?
Strong boundaries make openness safer. When constraints are clear, more creators can share runnable work without hidden risk assumptions.