R4
Browse docs+

Current Limitations

R4 already supports a strong agent runtime path for password retrieval and basic vault metadata management:

  • AGENT API keys
  • local private-key ownership
  • runtime public-key registration
  • wrapped vault-key delivery
  • local decryption through the CLI, SDK, or raw machine API

That is the supported path this website is optimized around.

What AGENT Runtimes Can Do Today

  • register their runtime public key
  • re-register the same runtime public key idempotently
  • list the vaults they can access
  • fetch wrapped vault keys
  • fetch signer directories and checkpoint metadata
  • list vault items
  • retrieve shared ciphertext and decrypt locally
  • create vaults
  • create vault items
  • archive vaults
  • archive vault items
  • use secrets through the CLI, SDK, or machine API

Current Onboarding And Rotation Constraints

  • Operators should create the agent first, let the runtime register its first public key, and only then grant vault-backed access through security groups, projects, or direct sharing.
  • Rotating to a different runtime public key while vault-backed access exists now requires the runtime to submit a complete replacement rewrappedVaultKeys batch for every active vault DEK, in addition to the normal continuity signature from the current private key.

What AGENT Runtimes Still Do Not Do Yet

There are still important constraints:

  • the runtime must keep its active registered private key locally and sign checkpoints with the current signerEncryptionKeyId
  • rotating to a different runtime public key is only self-service when the runtime can also pre-sign replacement wrapped DEKs for every active vault assignment
  • attachment management, procurement, and outbound webhooks now exist on the AGENT machine surface, but they still need their own permissions and sometimes extra tenant or org roles

How to Describe the Product Correctly

Use this framing:

  • Humans and operators store, organize, and share passwords in R4
  • Agents retrieve, use, and checkpoint-sign vault metadata with the passwords and vaults that were shared to them
  • The agent runtime proves identity with an AGENT API key, signs metadata with its registered runtime key, and decrypts with its local private key

Avoid this framing until the product changes:

  • “Agents can rotate keys with existing vault access without providing replacement wrapped DEKs”
  • “Agents automatically have every attachment, procurement, or compliance workflow without the needed endpoint permissions and tenant/org roles”

If You Need Agent Writes

If your workflow needs broader autonomous admin coverage beyond the currently documented machine surfaces, treat that as a product gap and plan it explicitly. The website and docs should stay aligned with the current supported runtime contract until those capabilities exist.

AGENT runtimes are encouraged to report these gaps through POST /api/v1/machine/feedback when the current CLI, SDK, MCP server, or raw machine API does not support the needed workflow. Use an AGENT API key with machine.feedback.write or machine.feedback.all, and do not include secret values, plaintext credentials, tokens, or private user data.