Problem
Per the credentials doc: "If STRIPE_KEY already exists, it is overwritten." There's no history and no rollback for the built-in credential store — if an operator (or an agent proposing a value back into a credential slot) overwrites a key with a bad value, the previous value is just gone. The only recovery path is remembering it yourself.
This stands out because Infisical's own core platform explicitly ships secret versioning and point-in-time recovery as a headline feature — Agent Vault's built-in store doesn't have an equivalent yet, even though it's conceptually the same "encrypted key/value with mutation history" problem.
(Vaults backed by the Infisical credential store are out of scope here — Infisical is already the source of truth and has its own versioning. This is specifically for the built-in store.)
Proposal
- Add an append-only
credential_versions table: on every set/overwrite of a built-in credential, write the previous encrypted value + timestamp + actor before applying the new one. Same AES-256-GCM-at-rest treatment as live credentials — no change to the encryption model.
- Bound retention the same way request logs already are (
AGENT_VAULT_LOGS_MAX_AGE_HOURS / _MAX_ROWS_PER_VAULT — following that existing pattern rather than inventing a new one), e.g. AGENT_VAULT_CREDENTIAL_HISTORY_MAX_VERSIONS (default something small like 10).
- New CLI/API surface:
agent-vault vault credential history <key> --vault my-vault — list past versions with timestamp + actor (not the value, unless --reveal and sufficient permissions, mirroring credential list --reveal's existing access rule).agent-vault vault credential rollback <key> --version N --vault my-vault — restores a prior version as the current value (itself recorded as a new version, so rollback is never destructive).
- Delete (
credential delete) could optionally also just be a version-preserving soft-delete rather than a hard delete, to match — happy to scope that separately if it adds too much surface to the first PR.
Why this is worth doing
This is a real "oops" risk today with zero mitigation, and it's a natural feature-parity gap with a capability Infisical already knows works well on the main platform — this isn't proposing something novel, just extending an existing, proven pattern down into Agent Vault's simpler built-in store.
Happy to implement — would start with the versions table + history/rollback CLI and API endpoints, gated behind the same permission model as credential get/--reveal (member/admin only, never proxy-role agents).
Problem
Per the credentials doc: "If
STRIPE_KEYalready exists, it is overwritten." There's no history and no rollback for the built-in credential store — if an operator (or an agent proposing avalueback into a credential slot) overwrites a key with a bad value, the previous value is just gone. The only recovery path is remembering it yourself.This stands out because Infisical's own core platform explicitly ships secret versioning and point-in-time recovery as a headline feature — Agent Vault's built-in store doesn't have an equivalent yet, even though it's conceptually the same "encrypted key/value with mutation history" problem.
(Vaults backed by the Infisical credential store are out of scope here — Infisical is already the source of truth and has its own versioning. This is specifically for the built-in store.)
Proposal
credential_versionstable: on everyset/overwrite of a built-in credential, write the previous encrypted value + timestamp + actor before applying the new one. Same AES-256-GCM-at-rest treatment as live credentials — no change to the encryption model.AGENT_VAULT_LOGS_MAX_AGE_HOURS/_MAX_ROWS_PER_VAULT— following that existing pattern rather than inventing a new one), e.g.AGENT_VAULT_CREDENTIAL_HISTORY_MAX_VERSIONS(default something small like 10).agent-vault vault credential history <key> --vault my-vault— list past versions with timestamp + actor (not the value, unless--revealand sufficient permissions, mirroringcredential list --reveal's existing access rule).agent-vault vault credential rollback <key> --version N --vault my-vault— restores a prior version as the current value (itself recorded as a new version, so rollback is never destructive).credential delete) could optionally also just be a version-preserving soft-delete rather than a hard delete, to match — happy to scope that separately if it adds too much surface to the first PR.Why this is worth doing
This is a real "oops" risk today with zero mitigation, and it's a natural feature-parity gap with a capability Infisical already knows works well on the main platform — this isn't proposing something novel, just extending an existing, proven pattern down into Agent Vault's simpler built-in store.
Happy to implement — would start with the versions table +
history/rollbackCLI and API endpoints, gated behind the same permission model ascredential get/--reveal(member/admin only, never proxy-role agents).