Overview

Security model

This page describes the protections Valet has today and where each one stops. For how the parts fit together, see How Valet works.

Isolation#

Every agent, every app process and every app build runs in its own isolated runtime: a lightweight virtual machine in the cloud, or its own Fargate task in a dedicated installation. A runtime serves one agent or one app process, and Valet destroys it when it stops, so it never returns to serve another agent or another organization. A build's runtime is destroyed when the build ends.

Inside an agent's runtime:

• The agent runs as an unprivileged user. It can read its instructions and skills but can't change them in place.
• Commands the agent runs can't read secrets from its memory.
• Its connectors run as a separate user, which the agent can't inspect.

An agent can install packages and write to its own files. In a dedicated installation, a runtime has no public address and accepts connections only from Valet's own services.

Credentials#

Model API keys#

Model provider API keys never reach an agent or an app. An agent calls models through Valet's model proxy, which holds the keys, using a Valet token that expires after an hour. An app that uses a model gets a Valet key that works only for that app and that model.

Connector credentials#

A connector's credentials, such as an API key or an OAuth token, stay in Valet, encrypted. When an agent calls one of the connector's tools, Valet adds the credential on the way out and refreshes OAuth tokens as needed. The agent never sees the credential. It holds only a Valet token for that one connector, which expires on its own and stops working when the connector is removed.

A connector that runs as a command inside the agent's runtime gets its secrets in a separate process the agent can't inspect, and runs only the command the connector declares.

An artifact can hold a connector that is an MCP server, so its page can call the connector's tools. Everyone who can open the artifact then has the connector's full reach under the organization's credential, including visitors with the password or a share link. Valet refuses these calls while the artifact is public.

Env vars#

An env var is a named value set on an organization, app or agent. It is either secret or plain.

An agent's secret env vars stay out of its environment; only its connectors receive them. Its plain env vars are in its environment, readable from its shell. This keeps secrets out of the model's reach, but it doesn't limit what an agent can do: an agent allowed to manage connectors can create one that uses any of the organization's secrets.

An app receives every env var, secret or plain, in its environment, the way a platform as a service delivers config. That includes the organization's secrets, and a resource's credentials such as DATABASE_URL. Apps can't hold connectors.

Encryption#

Valet encrypts credentials and secrets before it stores them: env var values, connector credentials and OAuth tokens, channel and share-link tokens, resource credentials, and log drain settings. Valet can rotate its encryption keys without losing access to older values. In a dedicated installation, the keys live in AWS Secrets Manager.

Valet stores the passwords that protect artifacts and apps hashed. It also keeps an encrypted copy of an artifact's password, so members of its organization can see it.

Other data relies on encryption at rest in the storage underneath: conversation history, memories, recent logs, version history and published files. In a dedicated installation, the databases and file storage are encrypted at rest, and storage buckets block public access.

Public endpoints use HTTPS and redirect plain HTTP. In a dedicated installation, the load balancer accepts TLS 1.2 and 1.3, and database connections use TLS.

Access control#

Organization membership is the access boundary. Organizations have no roles: every member can do what any other member can.

A new artifact or app is private. Only signed-in members of the owning organization can open it, and a member can make it public or put it behind a password. Valet passes an app no viewer identity.

Valet checks access on every request. It sends a signed-out visitor through Valet's sign-in, checks membership in the owning organization, and sets a session cookie for that one address. Apps never receive that cookie. Because membership is checked every time, removing a member ends their access at once. Suspending their account does too.

An artifact can be shared with an outside email address. Each share link is for one person and is checked on every request, and revoking it ends access on the next one. Apps have no share links.

The MCP server and the CLI authorize every call by organization membership too. See Organizations.

Supply chain#

When a command connector runs a package through npx or uvx, Valet installs only versions published at least seven days earlier. Command connectors from Valet's catalog come preinstalled. A connector's command must be a program name, not a path. Valet doesn't restrict which packages a connector may run.

An app build installs whatever the app's package.json, requirements.txt or go.mod names, and a lockfile is optional. Valet runs no vulnerability scan, keeps no package allowlist, and applies no age window to app builds.

What governance guides and what Valet enforces#

Your organization's skills, starting with governance, are instructions that coding agents read before they build and publish. Valet's default dependencies skill, for example, tells agents to use exact versions and releases at least seven days old. Valet doesn't check a publish against any skill, so a skill holds only as well as the agent follows it.

Only members of your organization can read its skills, and any member can publish or change one. A change reaches every connected coding agent at its next read, and every hosted agent that follows the skill at its next release. Pin a hosted agent's skills to keep its instructions fixed. See Skill library.

Valet itself enforces everything else on this page: sign-in and membership on every call and request, access settings, isolation, credential handling and encryption. It also enforces a title and description on every MCP publish, a Procfile on every app, size limits and organization caps. See Governance.

Outbound traffic#

Valet doesn't filter outbound traffic. An agent, app or build can open connections to any host. What a workload can reach inside your systems depends on the credentials it holds, through connectors, env vars and resources. See What leaves the installation.

Reporting a security issue#

Email support@valet.dev.