Valet|Docs

Evaluate

Security model

On this page

For how these protections 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 determines access to private artifacts and apps.

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 tells an app who is visiting with a signed token, which the app can verify; see Know who is visiting.

A private app can take webhooks and schedules without becoming public. Valet verifies a webhook's signature before it forwards the request, so an unverified request never reaches the app. See Webhooks and schedules.

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. Valet installs most command connectors from its catalog ahead of time; others download when the agent starts. 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 keeps no package allowlist and applies no age window to app builds. It checks packages for known vulnerabilities only when your organization adds a Dependencies (OSV) release policy, which checks the packages every release pins.

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 whether a publish follows a skill; compliance depends on the agent.

Release policies enforce checks on releases. Secrets scanning and vulnerability checks run only when your organization adds those policies; a blocking policy keeps a failed release from going live.

Only members of your organization can read its skills. See Skill library for how updates reach coding agents and hosted agents.

Valet enforces the access controls, isolation, credential handling and encryption described on this page independently of skills. Publishing also has required files and metadata, 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.

Next steps