Cursor cloud agents can mint their own Vault login, and the static token goes away

The number worth holding onto is the ceiling on how long anything valuable exists. A minted JWT lives five minutes and cannot be refreshed ^[3]. The Vault token it buys is capped at thirty ^[9]. Worst case, mint to expiry, that is thirty-five minutes of usable credential ^[20], sitting in a VM that is being deleted anyway. The token in the secrets tab has no ceiling at all; it lasts until someone remembers it ^[2].

What replaces the secret is a signature check plus claim binding. The audience string is shared, defaults to `vault`, and the author states plainly it is not a secret, only a value that must match on both sides ^[10]. The parts doing the work are the RS256 signature, verified against a JWKS that Vault pulls itself ^[5], and the role's `bound_subject` and `repo_url` ^[9]. That also moves the firewall hole. The agent needs egress to Vault and nothing else ^[6], while the Vault cluster now needs to reach Cursor's discovery endpoint ^[8]. Anyone who has locked down outbound traffic on their Vault nodes will feel that before they feel anything else.

Two configuration traps in the write-up are worth more attention than the Terraform. Putting `cloud_agent_id` in `bound_claims` produces a role tied to a single run, which dies with the VM; it belongs in `claim_mappings`, for audit ^[11]. And on a personal account, mapping `team_id` or `automation_id` fails login outright, because a mapped claim that is absent from the token is fatal ^[12]. Both mistakes fail closed. You get a broken agent, not a quietly over-permitted one, which is the better direction for an error to point.

Containment is where the design is still honest about being early. The policy grants read across `cursor-kv/data/*`, so anything holding it reads every path under the mount, and the author says as much: the mount is the isolation boundary for now ^[15]. The second role, `cursor-automation`, binds `automation_id` instead of `sub` but carries the same policy ^[14], so the precision in the bindings decides who may log in, not what they may read ^[21]. Add that the JWT names the run rather than a process, and any process on the VM can mint one ^[17], and the policy has to be sized for the least trustworthy command the agent executes. The shape is familiar: this is the same discovery-plus-bound-issuer-plus-role arrangement Vault already uses for HCP Terraform dynamic credentials ^[18], installed as new mounts and roles alongside whatever you already run ^[19].