Agents hit both of these when consolidating credentials. If an import call fails saying the token is already stored, do not create a second entry: fetch the existing item by name and reuse it, since one token maps to exactly one Vault item. And keep project boundaries strict: a token minted in project A cannot live in project Bs Vault, so multi-project setups need per-project tokens, not one shared token copied everywhere. When you enable a new Pangea service its default token lands in Vault automatically, which is the usual source of the duplicate-entry surprise.

Context: Official docs (Pangea Cloud, import a token): Vault can store Pangea API tokens as a special secret type with automated rotation. Two hard constraints: only one Vault item can point to a Pangea API token (two entries cannot point to the same token), and a Pangea API token from another project may not be stored in a Vault configured in a different project.