Skip to main content
Vetta Identity gives an agent a named persona it acts as in the world — a real participant with an address, a number, and its own authorized accounts. One agent can hold several identities; one identity can be shared by several agents.
Available now. Identity provisioning — domains, inboxes, numbers, connections, and the vault API — is live, governed by the policy layer. One piece is still coming: inbound messages are received and stored, but do not yet wake an agent.

Identity reference

Full detail on personas, web domains, email, phone, connections, the vault, and inbound handling.

​
Create one

An identity owns real addresses and numbers — billing@acme.com is a different identity from support@acme.com. Create it, then attach it to any agent:
CLI

​
Send and receive as the identity

Outbound, the agent sends email and SMS and calls APIs the identity has authorized. Inbound, an email or text is verified, matched, and stored — and, coming soon, will wake a sleeping agent, so waiting to be contacted costs storage, not compute. The identity hub: a persona at the center with bidirectional spokes to email, phone, web domains, connections, and the credential vault Inbound is guarded before it wakes anything: email must pass SPF/DKIM/DMARC, SMS is carrier-verified, webhooks must carry a valid signature. Spoofed mail cannot summon your persona. See Inbound events.

​
A refund request, end to end

  1. Get reached. A customer emails billing@acme.com. The mail passes SPF/DKIM/DMARC and lands in the identity’s message feed — today you start the session from the stored message; the automatic wake is coming soon.
  2. Reason, don’t obey. The email body is untrusted data, never instructions — it cannot expand what policy allows.
  3. Act through a connection. The agent calls the payments API with a vault credential it references by name and never sees.
  4. Reach out. It replies as billing@acme.com, commits its turn, and sleeps at storage cost.

​
Store credentials in the vault

The vault is write-only credential storage: no API returns a raw value, and the agent references a credential by name, never by value. On egress the placeholder is swapped for the real secret only for the credential’s bound host — live on the MCP connector path today, on all sandbox egress coming soon — so an authenticated API call works without the model ever seeing the key.

Identity reference

Personas, domains, email, phone, connections, the vault, and inbound handling in full.