Your CI/CD Pipeline Has an Identity Problem

Every team eventually has the incident. A deployment breaks at 2am because someone rotated a key and forgot about the CI pipeline that was still using the old one. Or worse — an engineer leaves, and nobody knows which service accounts were tied to their personal tokens.

The problem isn't that teams are careless. It's that the tools they use treat machine credentials as an afterthought.

The identity blind spot

Most secrets managers do a solid job of managing what — the secrets themselves. They encrypt values, control who can read them, and keep an audit trail of changes.

But they're largely silent on who is reading those secrets programmatically.

Think about how machine credentials typically work in a real organisation:

1. Someone creates a personal API token and pastes it into a CI/CD variable. It works. They move on.
2. Six months later, that person changes teams. The token still works. Nobody remembers it exists.
3. The token has full access to production secrets — not because it needs to, but because nobody scoped it when it was created.
4. There's no audit trail distinguishing "Alice read this secret from her laptop" from "the deploy bot read it during a release."

This is the Non-Human Identity (NHI) problem. And it's growing fast.

What is a Non-Human Identity?

A Non-Human Identity is any automated actor that authenticates to your systems: CI/CD pipelines, deployment bots, cron jobs, monitoring services, AI agents, serverless functions, Terraform runs — anything that isn't a person sitting at a keyboard.

According to recent industry research, non-human identities outnumber human users by a ratio of at least 10:1 in most organisations. Yet they're managed with a fraction of the rigour.

Human users get SSO, MFA, role-based access, and automatic deprovisioning when they leave. Machine credentials get a token pasted into an environment variable and forgotten.

How secr approaches NHI

secr treats machine credentials as first-class identities — not just strings to store.

Dedicated machine tokens

Instead of reusing personal CLI tokens for automation, secr has a dedicated machine token type:

secr_mt_prod_a1b2c3d4e5f6...

The environment hint is embedded right in the token prefix. When you see secr_mt_prod_ in a log, you immediately know this is a machine credential scoped to production. No guessing, no cross-referencing.

secr token create deploy-bot --env prod --permission read --expires 90d

Each token has:

• A name — deploy-bot, github-actions-staging, monitoring-service
• An environment hint — which environment it's intended for
• Explicit permissions — read or read_write, not implicit full access
• An owner — the human responsible for this credential
• An expiry — because credentials that live forever are credentials that get forgotten

The brownout pattern

Revoking a machine token in production is nerve-wracking. What if something you didn't know about depends on it?

secr introduces brownout — a soft-disable that returns 403 Forbidden instead of the usual response. The token is still in the system, but it stops working.

# Soft-disable — token returns 403
secr token disable <tokenId>

# Everything still working? Make it permanent.
secr token revoke <tokenId>

# Something broke? Re-enable immediately.
secr token enable <tokenId>

This lets you test the blast radius of revoking a credential before committing to it. Disable on Monday morning, watch your dashboards for a day, then revoke or re-enable with confidence.

Atomic token rotation

When it's time to rotate a credential, you don't want a gap between revoking the old token and deploying the new one. secr's roll operation is atomic:

secr token roll <tokenId>

This creates a new token with the same name, environment, permissions, and scope — then revokes the old one in the same operation. You get the new value immediately. Update your CI/CD variable, and the transition is seamless.

Every action is audited

When a machine token reads a secret, that shows up in the audit log as a distinct identity — not as the human who created it. You can answer questions like:

• "Which machine tokens accessed production secrets last month?"
• "When was the deploy-bot token last used?"
• "Who created the token that's hitting our API from an unknown IP?"

What's coming next

Machine tokens are the foundation. The NHI roadmap includes:

• Token ownership and transfer — assign responsibility for every credential and transfer ownership when people change roles
• NHI discovery and posture scoring — a health score across five dimensions (ownership, staleness, privilege, rotation, expiration) so you can see your exposure at a glance
• Policies — enforce rules like "all production tokens must expire within 90 days" or "no read_write tokens in production" at the organisation level
• Agent identities — purpose-built tokens for AI agents with secret allowlists, mandatory expiry, and kill switches
• OIDC federation — tokenless authentication for GitHub Actions, GitLab CI, and cloud providers

Getting started

Machine tokens are available now on the Pro plan and above.

# Create your first machine token
secr token create github-actions --env prod --permission read --expires 90d

# List all machine tokens in your org
secr token list

# See the full lifecycle
secr token disable <id>
secr token enable <id>
secr token roll <id>
secr token revoke <id>

If you're not sure where to start, run secr token list and look at how many personal CLI tokens are being used for automation. Each one is a candidate for a dedicated machine token with proper scoping and expiry.

For the full technical reference, see the Machine Tokens documentation.

---

Stop using personal tokens for your pipelines. Create your account and issue your first machine token in under a minute.