MACHINE IDENTITY

Every service call, from a machine you can actually identify

Service accounts, Kubernetes workloads, and SPIFFE/SPIRE-based identity - issued, scoped, rotated, and debugged from one control plane, not a spreadsheet of shared keys.

Get started See the SPIFFE/SPIRE integration

ATTESTATION PIPELINE - LIVEpending → attested → issued

01 - THE PROBLEM

Shared secrets outlive the people who made them.

KEY SPRAWL

Static, long-lived API keys and shared secrets sprawl across services, get checked into configs, and outlive the people who created them.

TRIBAL KNOWLEDGE

“Which service can call which API, with what role” is usually something a few people remember - not a fact you can query.

NOWHERE TO ASK WHY

When a machine-to-machine call fails, there's rarely one place to ask why - just logs to grep across two or three teams.

02 - HOW IT WORKS

Register, attest, grant, rotate, debug - as five separate operations.

01

Register a service account

Give it a name and a required, accountable human owner - every machine principal must have someone answerable for what it does, including actions with no human in the loop. Then choose how it authenticates: a client secret, a private-key JWT (you supply the JWKS URI, no shared secret to rotate), or Kubernetes/SPIFFE.

02

Mint or federate a SPIFFE identity

Go AuthSec-managed and it mints the SPIFFE ID from your pod's namespace and service-account selectors - or bring your own SPIRE and federate an existing external trust domain by registering its issuer as a trusted Workload Identity Provider.

03

Deploy the identity agent, then attest

Install paths exist for Kubernetes (Helm chart / DaemonSet), Docker Compose (with an SDK for fetching a short-lived SVID and making mutual-TLS calls between services), and bare VMs (a systemd service). Status then moves through a real state machine - attestation pending → attested → token issued - visible on the workload, with explicit failure states instead of a silent hang.

04

Grant access without touching identity

Separately from minting an identity, grant an existing workload a role on a specific Application. Minting identity and granting access are deliberately two different, independently reversible operations. Calls then carry a short-lived certificate or token rather than a long-lived secret - and where a secret is still used, it rotates without changing the client ID every downstream service already trusts.

05

Debug in one place

A named-check debugger walks the same checks the token issuer runs - is the service account active, is the client linked, does the role binding exist, is the SPIFFE issuer configured, does the SVID verify - and produces a shareable failure bundle. A dry-run simulator tells you whether a token would mint before you try it for real.

03 - CAPABILITIES

The full lifecycle, not just a key-issuing endpoint.

Service accounts & machine principals

Every non-human identity carries a mandatory, accountable human owner.

Three real credential types

Client secret, private-key JWT, and SPIFFE/SPIRE SVID - chosen per service account, not forced into one model.

Clean secret rotation

Rotate a compromised or expiring secret without changing the client ID every downstream integration already trusts.

Managed or federated SPIFFE/SPIRE

Mint your own trust domain, or bring an existing SPIRE deployment and federate it.

Real deployment paths

Kubernetes (Helm chart / DaemonSet), Docker Compose with mutual TLS between services, and bare VM via systemd.

Live attestation status

Pending, attested, or token-issued, shown as it happens, with explicit failure states rather than a guess.

Access grants decoupled from identity

Grant a workload a role on an Application without touching how it authenticates - and vice versa.

Named-check debugger

“Why can't this machine reach that API” - walks service-account status, role bindings, issuer configuration, and SVID verification, then hands you a shareable failure bundle.

Dry-run token simulation

Ask whether a token would mint - and why not - before anything is actually issued.

Machine-to-machine activity logs

Token issuance and policy decisions, logged and exportable.

Trust Delegation guardrails

A ceiling on role, permissions, and maximum token lifetime for anything acting without a human in the loop.

Brokered connectors

When a machine identity needs to reach a third-party service - GitHub, for example - the call is brokered: secrets are never returned to the caller, and the acting identity is captured in a full audit trail.

04 - WHO IT'S FOR

Platform & infrastructure engineers

Deploying services on Kubernetes who want real workload identity instead of secrets mounted into every pod.

Security engineers

Who need an inventory of every machine credential, who owns it, and a working rotate/revoke button.

SREs

Debugging a failed service-to-service call who want one screen that names exactly which check failed, instead of grepping logs across teams.

WHY IT'S DIFFERENT

Most “service account” systems stop at issuing a static key and calling it done.

AuthSec treats machine identity as a full lifecycle - mint or federate, attest, grant scoped access, rotate or revoke, debug - with SPIFFE/SPIRE as a real, working option rather than a roadmap slide. Identity and access stay separate operations, so minting a workload's identity never silently changes what it can reach, and granting access never requires touching how it authenticates.

05 - TERMINOLOGY

What these words mean here.

Service account

A non-human identity for server-to-server calls, always with a required, accountable human owner.

Workload

A service-account variant authenticated via SPIFFE/SPIRE instead of a shared secret.

SPIFFE ID / SVID

A verifiable workload identity (the SPIFFE ID) and the short-lived certificate or token that proves it at call time (the SVID).

Trust domain / WIP

The issuer a federated (bring-your-own-SPIRE) workload's SVID is trusted against - registered as a Workload Identity Provider.

Attestation

Verifying a workload's runtime identity - for example its Kubernetes namespace and service account - before issuing it a SPIFFE ID.

Application

The protected resource a machine identity is granted access to - an MCP server, an API, or a custom service.

06 - FAQ

Do we have to run Kubernetes to use this?−

No - Docker Compose and bare-VM (systemd) install paths are supported alongside Kubernetes.

Do we have to adopt SPIFFE/SPIRE to get started?+

We already run our own SPIRE deployment - do we have to replace it?+

What happens to a workload's access if we revoke its identity?+

How do we debug a machine-to-machine call that's failing?+

Talk to us

Get in Touch

Have questions about AuthSec? Want to see how it fits your AI infrastructure? We're happy to help.

Request a live demo
Discuss your use case
Get technical guidance

Send us a message

We typically respond within one business day.

Stop trusting a shared secret to be your identity system.

Get started, or talk to us about migrating existing service accounts.

Get started Talk to us