Defakto (formerly SPIRL)
A Mint (SPIFFE workload identity control plane)
Defakto service accounts can skip keys entirely by exchanging a short-lived OIDC token from any issuer the org admin registers, with exact claim matching; the fallback is a non-expiring Ed25519 private key. Mint reaches into your clouds by being an OIDC issuer you trust, so nothing is handed over.
Docs: d.defakto.security · Checked 2026-10-13 · source YAML · dispute via PR
Inbound A
How a workload running anywhere authenticates to this product.
Workload Identity Federation: an org admin registers any HTTPS OIDC issuer (auto-discovered, custom JWKS URL, inline JWKS or uploaded PEM keys for air-gapped IdPs), a WIF Configuration binds a service account to that issuer with exact-match claims, and the caller exchanges its OIDC token for a session that cannot outlive the token; the alternative is an Ed25519 key pair.
- Issuers
- any
- d.defakto.security checked 2026-10-13
“Workload Identity Federation (WIF) — the service account is bound to an external OIDC identity by presenting a short-lived platform-issued OIDC token (from Terraform Cloud, GitHub Actions, etc.) and receiving a session in exchange. No long-lived secret is stored.”
- d.defakto.security checked 2026-10-13
“A WIF issuer is an organization-wide record that registers an external OIDC identity provider (IdP) the organization trusts.”
- d.defakto.security checked 2026-10-13
“PEM ( --jwks-pem-file ) Private or air-gapped IdPs whose JWKS endpoint is unreachable by the control plane You upload PEM-encoded public keys.”
- d.defakto.security checked 2026-10-13
“The control plane fetches the JWKS from the OIDC issuer, verifies the token signature, audience, and expiry. On success, the control plane returns a standard service account session token.”
- d.defakto.security checked 2026-10-13
“The session will always have an expiration less than or equal to the expiration of the OIDC token.”
- d.defakto.security checked 2026-10-13
“Either at least one --claim or --allow-any-bearer is required — they are mutually exclusive. Every listed claim must match exactly.”
- d.defakto.security checked 2026-10-13
“Instead of storing a long-lived private key, the OIDC token is exchanged for a Defakto session token on each login.”
- d.defakto.security checked 2026-10-13
“Kubernetes ServiceAccount token No long-lived private key. Kubernetes issues a fresh, short-lived token at each login. Recommended Deployment key ( tdk-* ) A long-lived private key you generate, store, and ship to the cluster. Supported, not recommended”
Graded A because the issuer list is customer-defined, not a vendor allowlist: any HTTPS OIDC issuer works, and PEM/inline-JWKS modes cover private IdPs. Trust is constrained by issuer plus arbitrary exact-match claims (sub, repository, workspace, etc.); the control plane also checks audience, but the docs do not say which audience value is expected or whether it is configurable. Footgun: --allow-any-bearer skips claim matching, which the docs warn means any GitHub Actions workflow anywhere could log in. WIF is usable from spirlctl (0.36.0+) and the Terraform provider, so arbitrary scripts can use it, not only Terraform. The fallback is an Ed25519 private key held by the caller, which is a long-lived static secret (no expiry). How deployed components authenticate back: self-hosted Trust Domain Servers can log in keylessly with a Kubernetes ServiceAccount token (recommended, but off by default in the Helm chart), or with a long-lived Ed25519 "deployment key" (tdk-*) that remains supported; agents attest to Trust Domain Servers with platform evidence (k8s token, AWS IID, GCP IIT, Azure MSI, TPM, Kerberos, SSH/X.509 PoP, custom JWT), with no static agent token documented. No plan or tier gating for WIF was found in public docs.
Outbound A
How this product reaches into your cloud, repos, or other SaaS.
Mint is itself an OIDC issuer: each trust domain publishes an OIDC discovery document and JWKS, and customers configure AWS IAM OIDC providers, GCP Workload Identity Pools and Azure federated credentials to trust Defakto-issued JWT-SVIDs; no customer secret is handed to Defakto.
- d.defakto.security checked 2026-10-13
“A Defakto-issued JSON Web Token-SPIFFE Verifiable Identity Document (JWT-SVID) can be used to authenticate to Amazon Web Services (AWS) APIs and assume an AWS IAM role. This is done by setting up an AWS Identity Provider that supports OpenID Connect (OIDC).”
- d.defakto.security checked 2026-10-13
“This is done by setting up a Workload Identity Pool that supports OpenID Connect (OIDC). Defakto makes this process easier by automatically providing an OIDC Discovery document endpoint for your trust domain(s).”
- d.defakto.security checked 2026-10-13
“This is done by setting up an Azure User-Assigned Managed Identity with Workload Identity Federation that supports OpenID Connect (OIDC).”
- d.defakto.security checked 2026-10-13
“For other EKS clusters, use IRSA (IAM Roles for Service Accounts) to associate this role with the Trust Domain Server's Kubernetes service account.”
- d.defakto.security checked 2026-10-13
“Setup is a one-time configuration using a single Admin API key with an sk-admin- prefix. Defakto stores this onboarding key encrypted and uses it to scan the OpenAI organization remotely.”
Mint connectors checked: AWS, GCP, Azure, OpenAI and Anthropic federation (all via Mint as an OIDC issuer the customer trusts), CI/CD (GitHub, GitLab, Jenkins), Envoy, Istio, Kubernetes, Venafi Firefly. Cloud KMS key managers and AWS Private CA are called by customer-run Trust Domain Servers using IRSA / pod identity, not by Defakto with a handed-over key. No Mint connector asks the customer for a static secret. The sister product Ledger (secret discovery, same console) is a different story and would grade B on its own: AWS (OIDC provider + IAM role via CloudFormation), Entra/Azure (service principal with federated identity credential + admin consent) and Gemini EAP on GCP (Workload Identity Federation, "no service account key is created") are keyless, but the OpenAI and Anthropic integrations require pasting an organization Admin API key (sk-admin- / sk-ant-admin) that Defakto stores. Okta, Google Workspace, GitHub, Salesforce and Slack connectors are not documented for either product.
Hygiene for any static credential the product still issues
| ✗ Expiry enforceable | Service account keys have no expiry field in the CLI output or docs, and no org policy to force one; rotation is a recommendation only. Deployment keys (tdk-*) are likewise long-lived until disabled.
|
| ✓ Rotation via API | Keys are added, disabled, enabled and removed non-interactively via spirlctl (a service account can itself log in to do it). No public REST/gRPC API reference was found, but the CLI and Terraform provider cover automation.
|
| ✓ Scoped keys | Keys belong to a purpose-built service account with its own role (Auditor through Owner) and realm assignments. Roles are coarse and hierarchical; there are no per-key scopes.
|
| ✗ Last-used visible | The key listing shows only ID, public key, enabled and created-at. The rotation guide says to verify a new key "by checking authentication logs", so usage is only traceable through audit logs, not a last-used field. Ironically, Defakto's Ledger product computes last-used for other vendors' keys.
|
| ✗ Leak revocation | Neither Defakto nor SPIRL appears in GitHub's supported-pattern list (partner or user). Keys are plain PKCS#8 Ed25519 PEMs with no identifying prefix, so they are hard to attribute if leaked.
|
Notes
Defakto was formerly SPIRL; the rename is only partly through. Docs moved from doc.spirl.com to d.defakto.security, but the CLI is still spirlctl, Terraform resources are spirl_*, agent endpoints are *.spirl.com, and there is a spirlctl migrate-to-defakto page. Mint is the flagship (SPIFFE trust domains, agents, Trust Domain Servers, JWT/X.509/WIT-SVIDs, RFC 8693 token exchange). Ledger (static-secret discovery and migration) shares the control plane and the same service-account auth, so the inbound grade applies to both; its outbound story is described in the outbound notes. What keeps this card from being clean: Ed25519 service-account keys and deployment keys still exist, never expire, show no last-used, and are not in any leak-revocation program, and keyless Trust Domain Server login is opt-in (off by default).
Badge
[](https://wif.tax/p/defakto-mint/)