Agent Identity & the OpenEntity Ecosystem
Agent Secret Store consumes identity; it doesn't issue it. An agent's identity is its OpenEntity DID, and the vault records it so every product in the stack can talk about the same agent.
Four layers, one key
The ecosystem splits agent trust into four layers. The DID is the shared key between them.
| Layer | Product | Connection to the vault | Status |
|---|---|---|---|
| Identity | OpenEntity + Moltbot Den | The agent’s DID is stored on its vault agent as eid, next to its Moltbot Den agent ID. | Live |
| Identity | Moltbot Den trust tiers | The linked entity’s OEIS trust tier (0–4) is synced onto the vault agent. | Planned |
| Security | SecureMyAgent | sma fix --vault moves plaintext secrets found by a Checkup into the vault with the ass CLI. | Live |
| Security | SecureMyAgent attestations | A low security score or a critical finding forces human approval for sensitive secrets. | Planned |
| Governance | ClawGRC | Vault audit exports serve as evidence for key-management and access-control controls. | Live |
The Entity ID (eid)
Under the OEIS-1 standard, an Entity ID is a W3C DID. The default method is did:key (an Ed25519 key, always starting did:key:z6Mk). Entities can also use did:web, did:webvh, did:pkh (a wallet) or did:plc. An agent can create one with npx -y securemyagent register --name <name> or through the openentity.org registry.
Bind it when you create the agent:
ass agents create \
--name research-agent \
--scopes "secrets:read:production/*" \
--eid did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doKOr add it later from Dashboard → Agents → Edit, or with the API:
curl -X PATCH https://api.agentsecretstore.com/v1/agents/$AGENT_ID \
-H "Authorization: Bearer $FIREBASE_ID_TOKEN" \
-H "Content-Type: application/json" \
-d '{"eid": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"}'The vault returns the binding on every agent read and records it on the agent.created audit event:
{
"id": "6f1c…",
"name": "research-agent",
"eid": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
"moltbotden_entity_id": "research-agent",
"trust_tier": 0,
"allowed_namespaces": ["production"],
"active": true
}A binding is a claim, not a proof
The vault checks that the eid is a well-formed DID. It does not yet ask the agent to prove control of the DID's key. Treat the binding as the tenant owner's statement about which entity the agent is. Authentication still runs on the agent's ass_ key and scoped tokens.
Trust tiers
Trust tiers follow the OEIS-1 trust_tierscale of 0 to 4. Moltbot Den computes them from an entity's behavior. Link the agent's Moltbot Den agent ID now; tier sync onto the vault agent is planned, and until it ships every agent reports tier 0.
| Tier | Stage | Earned by |
|---|---|---|
| 0 | Instrument | Registered |
| 1 | Agent | Consistent behavior over 30+ events |
| 2 | Entity | A crystallized identity core |
| 3 | Verified entity | Has helped 5+ other entities |
| 4 | Sovereign entity | Full trust stack verified onchain |
Tiers don't relax approvals
Approval rules depend only on a secret's access tier. Sensitive and critical secrets always need a human approval, whatever the agent's trust tier. See Approval Workflows.
SecureMyAgent →
Move the plaintext keys a Checkup finds into the vault.
Moltbot Den →
Link vault agents to their Moltbot Den entities.
Compliance →
Map vault audit exports to ClawGRC controls.
Audit Trail →
Query and export every credential access.