Sovereign data
This section is the customer side: the idea it rests on, the vault and its connections, the Memory Bank, connectors, and members a customer owns, and how your own apps build on a vault.
Before any API, there is one idea the platform is arranged around: the data belongs to the customer, and it stays in their vault. What you build does not own that data or copy it out. It is a guest with permission to compute against it.
The inversion
In a conventional app the user signs up, connects an account, and their records land in your database. From then on their data lives in your product, on your terms: the user is the guest. They can ask you to delete it, but they cannot check that you did, and they cannot take their history with them.
Manykind turns that around. The data sits in the customer’s vault, backed by storage their wallet controls. Your agent or workflow travels to the data: it runs against the vault under an agreement the owner signed, touches only what that agreement covers, and leaves everything where it was when the owner withdraws it. Now you are the guest.
| Conventional app | Manykind | |
|---|---|---|
| Whose data it is | Yours to hold, once handed over | The customer’s, always |
| Where it lives | Copied into your database | In the customer’s vault |
| Who is the guest | The user, inside your product | Your agent, inside the customer’s vault |
| How access starts | The user accepts terms and hands data over | The owner signs an agreement naming what you may touch |
| How access ends | You are asked to delete your copy | The owner revokes the agreement |
| After the customer leaves | Your copy stays with your company | Nothing to keep; it was never yours |
| Who holds the authority | Your platform account | The owner’s wallet |
The customer keeps control of their history. You stop running a data pipeline you never wanted: no records to migrate, no store of user data to secure, no deletion requests to service.
What being a guest means
Your agent or workflow operates under a signed, scoped, revocable agreement:
- Signed. The vault owner’s wallet signs it. That signature is the authority, and nothing you hold can stand in for it.
- Scoped. An agreement is never “access to the vault.” It names one or more scopes, named partitions of the vault, and your agent works only there.
- Revocable. The owner can withdraw it at any time. What your agent wrote stays in the vault; connect a different agent later and it can pick up from there.
The mechanics are in Connections and consent.
Authority roots in the owner’s wallet
On conventional platforms, capability arrives as a credential you hold: an API key or service token. On Manykind no such credential reaches a customer’s data. You could hold every secret you own and still read none of it.
Capability rests on two things that belong to the customer:
- the wallet that owns their vault, and
- an agreement that wallet signed, naming which Agent Service may operate in which scopes.
You cannot widen your own access. You can only ask the owner to sign a broader agreement. That is what self-sovereign means in practice.
The standard behind it
None of this holds if it is one platform’s policy, so the ownership model is specified rather than promised. The Self-Sovereign Context Protocol (SSCP) makes the customer’s own data, not the agent and not the platform, the unit of portability, with the owner’s wallet as the only authority over it. It sits above agent-access protocols such as MCP and A2A, and beside identity protocols such as OAuth and DIDs, filling the ownership and consent layer they leave open.
Manykind is the first implementation of SSCP. What you build against is stable either way: your agent connects to a vault under a signed agreement, and that contract is what SSCP standardizes.
Everything you build works this way
- Agents and workflows run on the platform against a vault that connected them. They keep shared working state in cubbies and file durable conclusions into the vault’s Memory Bank.
- Widgets are the UI your Agent Service ships. They run in the browser as the signed-in person, under that person’s access to the vault.
- Your own apps (web, mobile, server) talk to a vault through the Vault SDK under the same rules.
Self-sovereign here means owned and revocable: the customer owns their data and can revoke any agreement by signature. It does not mean a hosting operator is cryptographically unable to read the data. Ask for the narrowest scope you need, and treat a revoked agreement as a hard stop.