---
title: Vibecodr Security Model | Vibecodr
description: Review sandboxing, policy boundaries, and platform guardrails that keep runnable user content safe by default.
canonical: https://vibecodr.space/security
---

# 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.

## Start here

### 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.

### 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.


## How it works in practice

### 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.


## Keep exploring

- [Secrets: Secrets and API calls](https://vibecodr.space/docs/secrets/index.md)
- [Runtime policy: Approved CDNs](https://vibecodr.space/docs/approved-cdns/index.md)
- [Embedding: Embeds guide](https://vibecodr.space/docs/embeds/index.md)
- [Disclosure: Vulnerability disclosure policy](https://vibecodr.space/vulnerability-disclosure-policy/index.md)
- [Private intake: Submit a private security report](https://vibecodr.space/support/bug-report?type=security)
- [Governance: Community rules](https://vibecodr.space/rules)

## FAQ

### 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.

## Closing note

Good security here should feel clear, not spooky: you should know what runs in public, what stays private, and why that line matters.