# Security Model

> Encryption boundaries, zero-disk runtime delivery, and role-based access concepts.

Canonical HTML: /en/docs/architecture/security
Canonical Markdown: /agent-docs/architecture/security.md
Audience: developer, operator
Agent safety: context-only

---

RunEnv protects configuration values through encryption, authorization, and narrowly scoped delivery. The Dashboard, CLI, SDKs, Desktop app, and integrations communicate through the RunEnv API; clients do not connect directly to the database.

## Encryption and delivery

* **At rest:** values are encrypted with envelope encryption. Data-encryption keys are protected by a key-encryption key managed through the configured key-management boundary.
* **In transit:** clients communicate with the RunEnv API over TLS.
* **At runtime:** `runenv run` injects values into the child process environment instead of writing a `.env` file.

> **A workflow can intentionally write to disk**
>
> Download-to-file, offline caching, and snapshot workflows are not zero-disk. Choose runtime injection when a no-file delivery boundary is required.

## Access control

RunEnv authorizes requests at the organization, project, environment, namespace, and action boundary. Organizations commonly assign Owner, Admin, Editor, or Viewer roles, then apply project membership and narrower permissions where required.

| Role   | Typical capability                                                                    |
| ------ | ------------------------------------------------------------------------------------- |
| Owner  | Organization ownership, governance, and administrative control                        |
| Admin  | Organization and project administration within delegated scope                        |
| Editor | Create and update permitted project configuration                                     |
| Viewer | Read permitted metadata; secret-value access depends on the explicit permission grant |

The effective permission is the result of the requester's authenticated identity, organization role, project membership, namespace policy, and the requested action. A role label alone is not proof that a caller can reveal a secret value.

## Safe operating practices

1. Use service tokens only for automation, scope them to the smallest project and environment boundary, and rotate them regularly.
2. Do not put tokens, secret values, authorization codes, or private keys in source code, issues, prompts, logs, artifacts, or documentation examples.
3. Use [Change Requests](/en/docs/core-workflows/change-requests) and audit history for sensitive changes.
4. Use [Hierarchical Namespaces](/en/docs/enterprise/namespaces) for inherited governance boundaries.
5. If a credential is suspected to be exposed, revoke or rotate it before investigating the surrounding logs.