Roadmap | HashiCorp — BizFirstAI

Open decision — single-use AppRole secret_id: if a tenant's AppRole is configured with secret_id_num_uses = 1 (HashiCorp's own recommended hardening pattern), this node's re-authenticate-and-cache design works until the cached client token expires, then fails every subsequent execution with HASHICORP_AUTH_FAILED — there's no secret_id left to log in with again. Two documented options exist, and an explicit choice is needed before shipping to any tenant using single-use AppRole credentials:

Require secret_id_num_uses = 0 (unlimited) as a hard prerequisite for AppRole tenants — simplest, but pushes a security tradeoff onto the tenant.
Add a dedicated re-issuance mechanism so this node can request a fresh secret_id itself when the cached token is about to expire, rather than only ever caching what it was first given.

See Authentication for how the current cache behaves.

Deliberately Not Implemented

Area	Why it's out of scope today
Response caching for Secrets reads	Caching a secrets-manager response is a security anti-pattern, not an oversight — this is a permanent design choice, not a gap to close later.
`token/create`	Minting arbitrary new tokens with elevated policies is an admin operation, not something a workflow-automation credential should do. Not planned.
Kubernetes / LDAP / Okta / JWT / cert auth methods	Only Token and AppRole are supported — the two realistic automation-credential shapes. No other auth backend is wired up.

Phase 2 Candidates

Area	Status
Transit secrets engine (encrypt/decrypt as a service)	Flagged as a Phase 2 candidate in the design docs, not committed scope. No third-party corroboration of demand was found for it at design time.

Before This Is Production-Ready

No live integration testing yet. Everything currently shipped is verified by compiling and by direct comparison against HashiCorp's own official Vault API documentation — not by exercising a running Vault server. Live integration testing against a real Vault instance (OSS, Enterprise, and HCP Vault Dedicated) is required before calling this node production-ready.

What Won't Change

The 4-resource/18-operation shape (secrets/token/lease/system) reflects a deliberate scope decision, cross-checked against HashiCorp's own API docs across three review passes covering standby-vs-sealed status codes, LIST-on-empty-path behavior, AppRole single-use secret_id semantics, and cas: 0 semantics. New operations, if added, are expected to follow the same partial-class-per-operation / one-service-per-resource pattern already in place.