Skip to main content

Agent identity

Every Automentic agent receives a unique cryptographic identity when it is provisioned — an X.509 certificate or a SPIFFE ID. Before it accesses any system or data, it must prove that identity.

Think of it as a passport rather than a password: it is issued by an authority, it expires, it can be revoked, and presenting it proves who you are without sharing a secret that anyone else could reuse.

Why not a service account​

Most automation authenticates with a shared service account and a long-lived API key. That fails in three specific ways:

  • Attribution collapses. Ten workflows using svc-automation produce ten thousand identical log lines. "Which agent did this?" has no answer.
  • The credential outlives its purpose. A key rotated annually is a key that was valid for a year after the workflow that needed it was decommissioned.
  • Revocation is blunt. Disabling the account stops everything using it, so in practice nobody disables it.

A per-agent identity fixes all three. Revoking one agent stops that agent, mid-run, and nothing else.

The two identity types​

X.509 certificates​

The long-established option, and the one most enterprise infrastructure already understands. Each agent gets a certificate whose subject names it:

CN=invoice-processor,OU=Finance,O=Automentic

Best where the systems being automated already do certificate-based authentication, or where an existing internal CA is the trust anchor.

SPIFFE IDs​

Designed for workloads that are created and destroyed constantly — containers, serverless functions, autoscaled services. A SPIFFE ID is a URI:

spiffe://automentic.example/ns/finance/agent/invoice-processor

The identity survives redeployment because it is tied to the workload's properties rather than to a file someone copied onto a host. Best for cloud-native environments where an agent may exist for ninety seconds.

Both are issued and rotated by the control plane; the choice affects trust anchoring, not how the rest of the model works.

Lifecycle​

  1. Provisioning — the agent is registered and an identity is issued. It is not yet permitted to act.
  2. Active — the agent presents its identity on every connection, over mutual TLS.
  3. Rotation — certificates are reissued before expiry. A short lifetime is a feature: it bounds the damage from a key that leaks.
  4. Suspension — the identity is temporarily refused. Useful during an investigation, and reversible.
  5. Revocation — the identity is permanently refused. Takes effect during a run, not at the next restart.

Where the identity comes from​

Agent identities are issued by Automentic, but the humans who authorise agent behaviour come from your own identity provider over OIDC or SAML. Your groups, your joiner-mover-leaver process, your source of truth.

See Federate your identity provider.