Machine Identity Is the New Perimeter

6/17/2026

We spent a decade hardening the human front door. MFA everywhere, SSO, conditional access, phishing-resistant keys. It worked — attackers increasingly don't bother brute-forcing a well-configured human login.

So they walk through the other door. The one nobody put a guard on: machine identity. Service accounts, API keys, OAuth client secrets, CI/CD tokens, cloud workload roles — and now AI agents. In most environments these outnumber human accounts by an order of magnitude, and they're protected far worse.

Why machine identities are the soft target

A human identity has natural defences. A person notices a login they didn't make. A person can be made to tap a hardware key. A person sleeps, so anomalous 3am activity stands out.

A machine identity has none of that:

  • Standing secrets. An API key is a password that never expires, never gets rotated, and works from anywhere on Earth.
  • No MFA. You can't make a cron job tap a YubiKey.
  • Broad scope. "To make the integration work," someone grants it more than it needs — and nobody ever trims it back.
  • Invisible sprawl. Keys get copied into .env files, CI variables, Slack messages, and laptops. Each copy is a new place to leak from.
  • No clear owner. When the engineer who created svc-integration-prod leaves, the account stays — orphaned but fully privileged.

Public breach post-mortems over the last few years repeat the same plot: a leaked token, a long-lived key in a public repo, an over-permissioned CI credential. Rarely a cracked human password.

The four problems to solve

I think about machine-identity hygiene as four questions. Most environments fail at least two.

1. Inventory — do you even know they exist? You can't protect what you can't see. The first exercise is always discovery: every service account, key, token, and workload identity, with its scope and last-used date. The dormant ones are pure liability — delete them.

2. Scope — can it only do its one job? A human gets broad access because they do many things. A machine usually does one. Scope it to that one thing. The integration that reads orders does not need write. The backup job does not need delete. This is least privilege, and it's easier for machines than for people — so there's no excuse.

3. Lifecycle — does the secret rotate and expire? Standing secrets are the core disease. The cure is short lifetimes and rotation. Prefer short-lived, automatically-issued credentials (workload identity federation, OIDC-based CI auth, cloud instance roles) over long-lived keys. When you must use a static key, rotate it on a schedule and store it in a secrets manager — never in source, never in a chat.

4. Accountability — can you trace what it did? Every machine action should be attributable to a distinct identity, logged centrally, and correlated with the rest of your telemetry. Shared accounts (automation, admin-bot) destroy this — if you can't revoke or trace one consumer without affecting all of them, you don't have identity, you have a shared password.

A baseline you can adopt this quarter

  1. One identity per workload. No shared service accounts. Distinct identity → distinct scope, logging, and revocation.
  2. Kill long-lived keys where you can. Move CI/CD and cloud workloads to federated, short-lived credentials. Reserve static keys for systems that genuinely can't do better.
  3. Secrets in a vault, never in code. Scan repos and history for leaked secrets; make the vault the only sanctioned source.
  4. Scope to the task, review on a cadence. Grant the minimum, then re-attest periodically — the same way mature orgs re-certify human access.
  5. Name an owner for every identity. An unowned credential is shadow infrastructure. Tag owner and purpose at creation.
  6. Treat AI agents as machine identities. An agent with an API key is exactly this problem wearing a new hat. Same rules: own it, scope it, rotate it, log it. (I went deeper on the agent-specific angle in Governing AI Agents.)

Where this connects to the frameworks

None of this is exotic — it's the same control objectives the standards already demand, just applied to the non-human half of the directory. NIST CSF Protect (PR.AC / access control) and ISO 27001 Annex A identity and access controls don't say "humans only." PCI DSS Requirement 8 increasingly expects strong authentication and unique IDs for system access too. The frameworks are ahead of most implementations here; the gap is execution.

What I'd do next

  • Run a non-human identity inventory and rank by scope × age × last-used.
  • Pick the top five over-privileged or dormant identities and remediate them this sprint.
  • Stand up (or adopt) a secrets manager as the single source, and add secret-scanning to CI.
  • Migrate one CI pipeline from static keys to OIDC federation as a proof of concept, then template it.

Closing thought

The perimeter didn't disappear — it moved. It used to be the network edge, then it became human identity. Today the least-defended boundary in most organisations is the pile of keys and tokens that quietly hold the place together.

The question worth asking about every machine identity: "If this single secret leaked tomorrow, what could it touch — and would I even notice?"

If the answer is "a lot" and "no," that's where the work is.