Stop shipping secrets. Start using a vault.

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.

By Platform Super Admin • April 21, 2026 • Security

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:

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-..."

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

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:

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)

# Or via the NEXUS AI dashboard:
# Settings → Access Tokens → New Token

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.

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

Rotate before expiry:

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

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)"

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

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

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=...

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:

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": "[email protected]",
  "token_id": null,
  "target": "DATABASE_URL",
  "deployment": "api-prod",
  "timestamp": "2026-04-21T09:14:22Z",
  "ip": "203.0.113.45"
}

{
  "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"
}

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)

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:

• How NEXUS AI deploys your app in under 5 minutes
• RBAC deep dive: roles, scopes, and least privilege
• MCP integration: 37 tools for Claude and AI agents
• Audit logs and compliance: what gets recorded and why

Ship what matters. Lock down the rest.