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 during Platform agent creation
• wrapped vault-key delivery
• local decryption through the SDK, MCP server, or raw machine API

That is the supported path this website is optimized around.

What AGENT Runtimes Can Do Today

• use the runtime public key registered by the Platform agent wizard
• re-register the same runtime public key idempotently when repairing setup
• list the vaults they can access
• fetch wrapped vault keys
• fetch signer directories and checkpoint metadata
• list vault items, read single fields, and read environment-marked fields
• retrieve shared ciphertext and decrypt locally
• run full or delta vault sync and metadata search
• create, update, and archive vaults
• create, update, move, and archive vault items
• read project- and license-scoped environment bundles
• use secrets through the SDK, MCP server, or machine API

Current Onboarding And Rotation Constraints

• Operators should create the agent through the Platform wizard so the public key is registered before security-group access is applied. If access was granted before registration in a legacy flow, re-share or re-assign the access path after registration.
• 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 so it can unwrap vault DEKs and prove continuity during key rotation
• 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 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.