Credential sharing for agents
Beta · Request accessRequest access for your account.
A message should reference a secret, never carry it.
Radient Vault beta shares an opaque credential reference between agent workflows, not the credential content.
Used with Local Operator
In Local Operator, an agent can refer to a Vault item without putting its value into Agent messages.
Status
Beta · Request access
Early access for your account
Message content
Opaque reference
A vault_item identifier, not credential content
Designed encryption
Fresh key per item
Value and optional username
Key scope
One KMS key per environment
Not one wrapping key per vault
Share a reference, not the credential
A conversation can carry a reference while credential content remains outside it. The security model keeps item values and wrapped keys on their respective sides of the boundary.
Credential sharing / security boundary
Beta · Request accessMessage
vault_item=vit_01J8EXAMPLEAn opaque item reference, not a credential value.
Item envelope
Value + optional username encrypted under a fresh per-item data key.
Names and operational metadata are not field-encrypted.
Separate key ledger
Wrapped data keys sit in a separate ledger outside the item database in this security model.
One KMS wrapping key per environment, not per vault.
Not zero knowledge. In this security model, authorized store and reveal operations process plaintext at Radient. The service is not end-to-end encrypted.
Request beta access. Share a reference, not the credential.
Mechanism
How it works
- 01
A reference enters the workflow
The designed message shape contains an opaque vault_item reference and ordinary operational context, never the item’s value or username.
- 02
Each item gets its own data key
The value and optional username are designed to be encrypted with a fresh per-item data key, rather than one shared vault password.
- 03
Wrapped keys live apart from item data
In this security model, a separate ledger holds wrapped data keys. One KMS wrapping key per environment wraps them; it is not a per-vault key.
- 04
Controlled operations process plaintext
In this security model, authorized store and reveal operations process plaintext at Radient. This narrows custody; it does not make the service zero knowledge.
Credential sharing in context
An agent names the credential a deployment needs
In this beta workflow, an agent preparing a staging deployment attaches a vault_item reference for the staging login. The conversation carries the item identifier and the reason it is needed, not the username or password. In this security model, a separately authorized operation resolves that reference.
The design goal is narrower than ‘the agent has the secret’: collaborators can discuss the required item without copying its contents into stored conversation text.
Before you rely on it
Requirements, limits, security and cost
Beta access
- Request access for your account
- Use opaque references in agent workflows
- Keep credential content out of messages
- Early access through the contact form
Not hidden by the design
- Item names and operational metadata are not field-encrypted
- In this security model, authorized store and reveal operations process plaintext at Radient
- Backups and ordinary operational records require their own controls
Outside the boundary
- Not end-to-end encrypted and not zero knowledge
- Full cloud-account or key-administrator takeover is outside the threat boundary
- A compromised workload can expose plaintext flowing through it
Cost
- No Vault price is published
- Do not budget from an assumed seat, storage or operation charge
- Contact us to discuss your custody requirements
Feature questions