DEV Community

Cover image for Stop shipping secrets. Start using a vault
Saif Ali
Saif Ali

Posted on

Stop shipping secrets. Start using a vault

#ai #webdev #productivity #security

Stop shipping secrets. Start using a vault.

Published: April 21, 2026

Category: Security · DevOps

Reading time: 12 minutes

Author: NEXUS AI Team

Leaked API keys cost companies an average of $1.2M per incident. Not because engineers are careless — because the tooling makes the wrong thing easy. .env files committed to repos. Hardcoded credentials baked into container images. Production secrets copy-pasted into Slack for "temporary" handoffs that last six months.

NEXUS AI ships a built-in Secrets Vault and a first-class Access Token system. This post covers exactly how both work, how they integrate at deploy time, and how to run a zero-plaintext secret configuration in your production environment — starting today.

The problem with secrets in 2026

Most teams manage secrets in one of three ways:

Approach What goes wrong
.env files in repos One git log away from a breach. "Secret" scans never catch everything.
CI/CD environment variables Visible to anyone with repo access. Rotate one and you're editing 14 pipelines.
Cloud secret managers (AWS Secrets Manager, GCP Secret Manager) Right idea, wrong integration. Requires service accounts, IAM glue, and a custom fetch layer in every app.

The common thread: secrets live somewhere they shouldn't, accessed by code that has more permission than it needs, with no record of who read what.

NEXUS AI eliminates all three failure modes at the platform level.

The NEXUS AI Secrets Vault

Every NEXUS AI project ships with an encrypted Secrets Vault. Secrets are encrypted at rest using AES-256-GCM before they touch the database — the same cipher used by the U.S. Department of Defense for classified data at rest.

How encryption works

When you store a secret, NEXUS AI:

  1. Encrypts the value with AES-256-GCM using a derived key (scoped per organization).
  2. Stores only the ciphertext, the IV (initialization vector), and the auth tag.
  3. Never writes the plaintext to disk, logs, or any observable surface.

The encryption key itself is never stored alongside the ciphertext. It's derived at runtime from SECRETS_ENCRYPTION_KEY — an environment variable you set once at the platform level and never touch again.

# Set via the NEXUS AI CLI
nexus secret set DATABASE_URL "postgres://user:pass@host:5432/db"
nexus secret set STRIPE_SECRET_KEY "sk_live_..."
nexus secret set OPENAI_API_KEY "sk-..."
Enter fullscreen mode Exit fullscreen mode

Secrets are namespaced per deployment. A secret set for api-prod is not visible to api-staging — even if both deployments live in the same project.

What the vault does NOT do

No system is better described by its constraints than its capabilities:

  • The vault does not store secrets in application containers. Secrets are injected at runtime as environment variables, never embedded in the image.
  • The vault does not expose secret values through logs. The observability pipeline redacts known secret patterns automatically.
  • The vault does not allow cross-tenant secret access. Secrets are scoped to an organization ID enforced at the query layer — not just the API layer.

Secure Configuration Injection

When NEXUS AI deploys your application, secrets don't get "loaded" by your app at startup. They're injected into the container's environment by the runtime before the first process starts.

The sequence:

1. Deploy command issued
2. NEXUS AI fetches encrypted secrets for the target deployment
3. Secrets decrypted in the control plane (never on the container host)
4. Injected as environment variables into the container spec
5. Container starts — secrets already present as env vars
6. Plaintext exists only in memory, for the lifetime of the process
Enter fullscreen mode Exit fullscreen mode

Your application code reads process.env.DATABASE_URL exactly as it always has. Zero changes to application code. Zero additional SDK imports. Zero IAM role configuration.

This is what NEXUS AI calls Secure Configuration Injection — vault-backed runtime config by default.

Access Tokens

Secrets protect your application's config. Access Tokens protect access to NEXUS AI itself.

An Access Token is a scoped credential that authenticates API calls to NEXUS AI — including calls from the CLI, CI/CD pipelines, external scripts, or AI agents running via MCP.

Token anatomy

Every NEXUS AI Access Token carries three pieces of information:

Field Purpose
token_id Stable identifier. Visible in audit logs. Safe to display.
token_value The actual secret. Shown once at creation. Never stored in plaintext.
scopes What the token is allowed to do. Read-only? Deploy-only? Full control?

Tokens are hashed with SHA-256 before storage. If an attacker gets your database, they get hashes — not tokens.

Creating a token 

# CLI
nexus token create --name "ci-deploy-prod" --scopes deploy:write,secrets:read

# Output:
# Token ID:    tok_01HX9...
# Token value: nxt_live_...  ← shown once, copy it now
# Scopes:      deploy:write, secrets:read
# Expires:     never (set --expires 90d to add expiry)
Enter fullscreen mode Exit fullscreen mode 
# Or via the NEXUS AI dashboard:
# Settings → Access Tokens → New Token
Enter fullscreen mode Exit fullscreen mode

For CI/CD pipelines, store the token value as a repository secret in your provider (GitHub Actions, GitLab CI, etc.) and inject it as NEXUS_API_KEY.

Token scopes

NEXUS AI uses a least-privilege scope model. Grant exactly what the caller needs — nothing more.

Scope What it allows
deploy:read View deployment status, logs, metadata
deploy:write Create, redeploy, rollback, stop deployments
secrets:read List secret names (never values)
secrets:write Create, update, delete secrets
billing:read View usage and invoices
admin Full organization access

A CI/CD pipeline that only needs to redeploy on merge gets deploy:write. It cannot read secrets, cannot view billing, cannot create new deployments from scratch. One compromised pipeline token does not become a full organization breach.

Token expiry and rotation

Short-lived tokens are better tokens. Set expiry explicitly:

nexus token create --name "github-actions-main" --scopes deploy:write --expires 90d
Enter fullscreen mode Exit fullscreen mode

Rotate before expiry:

nexus token rotate tok_01HX9...
# Old token: revoked immediately
# New token: nxt_live_...  ← 90-day window restarts
Enter fullscreen mode Exit fullscreen mode

Rotation is zero-downtime. The old token stays valid for a 5-minute grace window — long enough for an in-flight deploy to complete, short enough that a leaked token has minimal exposure.

Secrets + Tokens in a real pipeline

Here's what a production-grade deploy pipeline looks like with NEXUS AI:

Step 1: Store secrets once 

# Done once, by a developer with secrets:write scope
nexus secret set DATABASE_URL "$DATABASE_URL"
nexus secret set REDIS_URL "$REDIS_URL"
nexus secret set JWT_SECRET "$(openssl rand -hex 32)"
Enter fullscreen mode Exit fullscreen mode

Step 2: Create a scoped CI token 

# Create a deploy-only token for GitHub Actions
nexus token create --name "github-actions-main" --scopes deploy:write --expires 90d
# → Store the token value in GitHub Actions secrets as NEXUS_API_KEY
Enter fullscreen mode Exit fullscreen mode

Step 3: CI/CD pipeline (GitHub Actions example) 

name: Deploy to production

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to NEXUS AI
        env:
          NEXUS_API_KEY: ${{ secrets.NEXUS_API_KEY }}
        run: |
          npx nexus-cli deploy redeploy --deployment api-prod
Enter fullscreen mode Exit fullscreen mode

No secrets in the pipeline YAML. No secrets in the container image. The pipeline token can trigger a redeploy — it cannot read DATABASE_URL, cannot change secrets, cannot touch other projects.

Step 4: Runtime

When the container starts, it finds:

DATABASE_URL=postgres://...
REDIS_URL=redis://...
JWT_SECRET=...
Enter fullscreen mode Exit fullscreen mode

Ready. No SDK. No fetch-on-startup. No cold-start latency penalty from secret retrieval.

RBAC and the audit trail

Access Tokens operate within NEXUS AI's Role-Based Access Control (RBAC) system. Every token is issued to an organization member with a role:

Role What they can do
Viewer Read logs, status, and deployment metadata
Developer Deploy, redeploy, rollback; read secret names
Admin Full control including secrets, tokens, and billing
Owner Everything Admin can do + delete the organization

A Developer role member creating a token cannot grant that token admin scope. Privilege escalation via token creation is blocked at the model layer.

The audit log

Every secret operation and token use is recorded:

{
  "event": "secret.updated",
  "actor": "saif@example.com",
  "token_id": null,
  "target": "DATABASE_URL",
  "deployment": "api-prod",
  "timestamp": "2026-04-21T09:14:22Z",
  "ip": "203.0.113.45"
}
Enter fullscreen mode Exit fullscreen mode 
{
  "event": "deploy.redeploy",
  "actor": null,
  "token_id": "tok_01HX9...",
  "target": "api-prod",
  "deployment": "api-prod",
  "timestamp": "2026-04-21T09:17:05Z",
  "ip": "140.82.114.3"
}
Enter fullscreen mode Exit fullscreen mode

When a deploy fires at 3 AM, you know it was the CI token. When a secret changes, you know who changed it and from where. Audit logs are append-only, exported to your observability stack, and retained for 90 days on Pro and indefinitely on Enterprise.

MCP: AI agents and your secrets vault

NEXUS AI ships 37 MCP tools for Claude and other AI agents. When an AI agent uses a token to call the NEXUS AI MCP server, it operates under the same scope model as a human caller.

An agent with deploy:read can inspect deployment status and fetch logs. It cannot modify secrets, redeploy, or rollback — unless its token includes deploy:write.

# Agent calls nexusai_deploy_status → allowed (deploy:read)
# Agent calls nexusai_secrets_create → blocked (secrets:write not granted)
# Agent calls nexusai_deploy_redeploy → blocked (deploy:write not granted)
Enter fullscreen mode Exit fullscreen mode

This means you can give Claude read-only access to your production environment for diagnosis — and be certain it cannot modify anything. When you want Claude to act (redeploy, rollback), you issue a deploy:write token explicitly, scoped to exactly that.

AI agents with unconstrained production access are a liability. Scoped tokens make AI-assisted operations safe by default.

Checklist: zero-plaintext secrets in 10 minutes

  • [ ] Store all secrets with nexus secret set — delete any existing .env from your repo
  • [ ] Create deployment-scoped tokens for every CI/CD pipeline — one token per pipeline
  • [ ] Set token expiry to 90 days maximum — calendar reminders for rotation
  • [ ] Assign team members the minimum role they need — Viewers don't need Developer
  • [ ] Enable audit log export to your SIEM or logging stack (Datadog, Grafana, etc.)
  • [ ] Run nexus secret list quarterly — delete secrets that no longer have a deployment

Frequently asked questions

Can I view a secret value after I've stored it?

No. The vault stores only the encrypted ciphertext. The plaintext value is shown once at creation. This is intentional — if you need to verify a secret, rotate it.

What happens to secrets if I delete a deployment?

Secrets are scoped to a deployment. Deleting the deployment marks its secrets as orphaned. Orphaned secrets are purged automatically after 30 days, or immediately if you run nexus secret purge --deployment <name>.

How do I handle secrets that multiple deployments share?

Set the secret on each deployment. NEXUS AI does not support cross-deployment secret references by design — shared access is shared blast radius. Duplication is cheaper than a cross-project breach.

Can a Developer-role member read secret values?

No. secrets:read scope lists secret names (e.g., DATABASE_URL) but never values. Only the NEXUS AI control plane decrypts values — and only at deploy time, into the container environment.

What encryption key does NEXUS AI use?

On NEXUS AI-managed infrastructure, the encryption key is managed by the platform and rotated automatically. On Enterprise On-Prem, you supply SECRETS_ENCRYPTION_KEY and own the key lifecycle entirely.

Can I use NEXUS AI secrets with a non-NEXUS AI host?

Not directly. The vault is tightly integrated with the deployment runtime. If you're running on external infrastructure, use your cloud provider's native secret manager and inject credentials at the infrastructure level.

What's next

Secrets Vault and Access Tokens ship on every NEXUS AI plan — including Starter at $29/mo. No additional configuration, no third-party integrations, no IAM policy documents.

If you're on an Enterprise or regulated workload, RBAC, audit log retention, and on-prem key management are available on Enterprise and Enterprise On-Prem tiers. Talk to the team at nexusai.run.

Related reading:

Ship what matters. Lock down the rest.

Top comments (0)