Secrets

The Secrets tab is where you manage environment variables and sensitive configuration for your project. These secrets are injected into the project’s sandbox at runtime so agents can execute code that depends on external systems, without exposing credentials in source control, logs, or task output.

Secrets are project-scoped. They apply only within the current project and are available only during sandbox execution. They are not written to the repository, not included in diffs, and not stored in plain text after creation.

Teams typically configure Secrets when moving from static analysis to real execution, such as running builds, calling third-party APIs, connecting to databases, or testing authenticated workflows.

Environment Variables (Vault-Backed Storage)

All secrets are stored as environment variables and secured using vault-backed storage with encryption and audit logging.

On the Secrets page, you can:

• View all configured environment variables.
• Filter by environment.
• Sort by name.
• See when each secret was last updated.
• Identify which secrets are marked as Sensitive (values cannot be displayed).

Each secret entry includes:

• Name (e.g., OPENAI_API_KEY, DATABASE_URL)
• Environment scope (e.g., All Environments)
• Last updated timestamp
• Actions (edit or delete)

Sensitive secrets display a lock indicator and explicitly state that their values cannot be displayed.

Example

If your repository includes code that calls a payment gateway API, the API key must be available at runtime. Instead of committing it to .env in GitHub, you add it here as:

STRIPE_API_KEY=sk_live_...

When an agent runs integration tests in the sandbox, that variable is injected automatically, without ever being committed to the repository.

What Secrets Are Used For

Secrets are used to support authenticated and environment-dependent execution inside the sandbox.

Common use cases include:

1. External API Access

Providing credentials such as:

• OPENAI_API_KEY
• STRIPE_SECRET_KEY
• SENDGRID_API_KEY

This allows agents to run integration tests, generate outputs, or validate workflows that depend on real services.

2. Database Connections

Supplying runtime configuration such as:

• DATABASE_URL
• KV_URL
• REDIS_URL

For example, if an agent modifies a migration script and runs tests that require a database connection, the sandbox can access the database securely using these environment variables.

3. Feature Flags & Environment-Specific Config

Defining variables like:

• FEATURE_X_ENABLED=true
• NODE_ENV=production
• API_BASE_URL=https://api.staging.example.com

This allows the same project to behave differently across development, preview, or production execution contexts.

Secrets provide configuration only. They do not grant additional repository permissions or override access controls.

Environment Scoping

Each secret can be scoped to a specific environment.

From the UI, you can assign a secret to:

• All Environments
• (Environment-specific scopes if configured in your project)

This is particularly important when separating development from production.

Example

You may configure:

DATABASE_URL (Development) → points to test database

DATABASE_URL (Production) → points to production database

When an agent runs a preview deployment task, it will receive the preview-scoped value, not the production credential.

This prevents accidental use of live infrastructure during experimentation and supports safe testing workflows.

Adding a Secret

Use the Add button to create a new environment variable.

Each secret requires:

• Name – The environment variable key (e.g., DATABASE_URL)
• Value – The secret value
• Environment scope – Where it should apply
• Sensitive toggle – If enabled, the value cannot be revealed after saving

Sensitive Mode

When Sensitive is enabled:

• The value cannot be viewed after saving.
• It cannot be copied from the UI.
• It is only injected at runtime.

This is recommended for API keys, production credentials, and private tokens.

Example Workflow

If you rotate your OPENAI_API_KEY, you would:

1. Edit the existing secret.
2. Paste the new value.
3. Save.
4. Future sandbox executions automatically use the updated key.

No repository change is required.

Importing from .env

For bulk setup, use the Import button to upload or paste a .env file.

Supported formats include:

• .env
• .env.local
• .env.development
• .env.production
• .env.preview

You can:

• Drag and drop a file, or
• Paste raw .env contents directly into the input field

Each valid key-value pair is parsed and added as a secret.

Example

If your local .env contains:

DATABASE_URL=postgres://...

API_KEY=sk-...

REDIS_URL=redis://...

Importing this file will automatically create three secrets in Origin. You can then review and adjust environment scopes before saving.

This is especially useful when:

• Onboarding an existing project.
• Migrating from local development.
• Setting up multiple services quickly.

Editing and Deleting Secrets

From the main Secrets table, you can:

• Edit a secret (update value or scope).
• Delete a secret entirely.

If a secret is deleted, future executions that depend on it may fail unless the variable is reintroduced.

Teams typically revisit this section when:

• Rotating credentials.
• Migrating infrastructure.
• Adding new third-party integrations.
• Changing environment-specific configuration.

Security and Visibility Model

Secrets follow a strict security model:

• Values are encrypted at rest.
• Sensitive values cannot be revealed after saving.
• Secrets are never committed to the repository.
• They do not appear in diffs or pull requests.
• They are injected only into the sandbox runtime.

Secrets will only appear in logs or output if user-authored code explicitly prints them. Origin does not expose them automatically in task summaries or conversational output.

This ensures that agent execution remains secure even when performing authenticated workflows.

How Secrets Integrate with Project Execution

Secrets work together with:

• Workspace – Defines the runtime environment where secrets are injected.
• Repository – Provides the code that consumes the environment variables.
• Preferences – Determines how agent execution behaves.
• Models – Influence how agents reason, but not what secrets they access.

For example:

1. A task modifies a webhook handler.
2. The agent runs tests inside the sandbox.
3. The webhook signing secret is injected at runtime.
4. The test suite validates the signature logic successfully.

Without properly configured secrets, that execution would fail, even if the code itself is correct.

Best Practices

To maintain secure and predictable execution:

• Use environment scoping to isolate production credentials.
• Enable Sensitive for API keys and private tokens.
• Rotate secrets periodically.
• Avoid printing secret values in logs.
• Use .env import for consistent onboarding.

Secrets enable secure runtime execution without compromising repository integrity. They are essential when moving from code reasoning to real-world, authenticated automation inside Origin.