Automation Needs an Identity, and That's a Credential You Now Own

The first time you automate something privileged — issuing a certificate, calling an API, writing to a database — you hit a question that’s easy to wave away and expensive to get wrong: who is this automation acting as? Code doesn’t get to be anonymous. It runs as some identity, with some set of permissions, holding some credential. If you don’t design that deliberately, you get the default, and the default is almost always “as me” or “as root” with a secret pasted somewhere it shouldn’t be.

Automation always acts as someone

A script that renews certs has to authenticate to the thing that issues certs. A job that updates records has to log in to the database. There’s no version of this where the automation is just trusted ambiently. So the only real choice is whether the identity it uses was chosen on purpose or inherited by accident.

The accidental versions are the ones that bite later. Automation running under a human’s personal account breaks the day that person’s password rotates or they leave. Automation running as root can do anything, so a bug in it can also do anything. Automation carrying a long-lived token in a repo is a leak with a delay timer. Each of those is what you get when “what identity does this use?” never got asked.

A service account is a first-class credential

The deliberate version is a dedicated machine identity — a service account that exists to be the automation, and nothing else. The point isn’t bureaucracy. It’s that a non-human identity can be reasoned about: it has an owner, a defined scope, a place its credential lives, and a plan for rotation. A human account borrowed for the job has none of those properties cleanly, because it’s also doing human things.

A service account isn’t paperwork standing between you and shipping. It’s the difference between automation you can audit and automation you just hope about.

Provision it as its own thing, with its own credential, and you’ve turned an ambient assumption into an asset you can actually manage.

Non-prod and prod are different identities

One pattern I’ve come to treat as non-negotiable: the automation gets a separate identity per environment. The non-production identity and the production identity are distinct accounts, provisioned separately, often with a real approval gate before the production one is allowed to do anything that matters.

This feels like friction until the first time it saves you. A test run that goes sideways is contained to a test-scoped identity that literally cannot reach production resources. Promoting to production becomes an explicit step — a different credential, granted on purpose — rather than the same all-powerful account quietly pointed at the real thing. Separate identities per environment are how you keep “I was just testing” from becoming an incident.

Store it like it matters

A machine identity’s credential belongs in a secret manager or privileged-access vault, fetched at runtime — never committed to a repo, never baked into an image, never sitting in a config file you’ll forget about. The automation pulls it when it runs and the secret store stays the single source of truth.

This is the boring half of the work and the half people skip. It’s also where most of the real-world failures actually come from: not a clever attack, but a token that lived in version control for two years. I’ve written more about keeping secrets out of git and why environment variables are not a vault — both are really about the same instinct as this post: the credential is the crown jewel, so treat it like one.

Scope it to exactly one job

The next question after “what identity?” is “what can that identity touch?” The answer should be: the narrowest thing that lets it do its job, and nothing else. If the automation issues certs in one policy zone, its identity should be able to issue certs in that one zone — not administer the whole platform. Least privilege isn’t a virtue you sprinkle on top; it’s the blast radius if the credential ever leaks, written down in advance.

The test I use: if this identity’s secret showed up in a paste bin tomorrow, what’s the worst it could do? If the answer is “anything,” the scope is wrong. A tightly scoped identity turns a leaked credential from a catastrophe into an incident you can absorb.

Plan the end, not just the beginning

Identities are easy to create and easy to forget, which is how every organization accumulates a graveyard of service accounts nobody remembers, holding permissions nobody audits, on credentials that never rotate. The lifecycle doesn’t end at “provisioned and working.” It includes rotation, expiry, and a clear answer to “who owns this and when does it get retired?”

An identity nobody owns is a liability with no off switch. So when I stand up automation now, I treat the identity as part of the deliverable, the same way a certificate that renews itself treats renewal as part of the design rather than a future emergency. The work isn’t done when the automation runs. It’s done when you can say who it is, what it can reach, where its secret lives, and when it goes away.

This is the same line of thinking as treating access control as a pipeline, not a switch — identity is a thing you design, operate, and eventually decommission. If you’re wiring up automation and want a second set of eyes on the identity story before it ships, my inbox is open.