Socious
MCP

Agent Identity

AI agents increasingly act on people’s behalf — drafting email, booking meetings, making purchases. The counterparty’s problem is always the same: who does this agent act for, what is it allowed to do, and is a real, verified human behind it?

Agent Identity answers that with a delegation: a scoped, expiring, revocable grant from a ShinID account to a named agent, carried as a signed token the agent presents wherever it acts. Anyone can check the token against Socious Verify — the check consults our records, not just the token, so a revoked delegation fails verification immediately even though its signature is still intact.

A delegation states:

  • Who delegates — the granting ShinID account, and whether a KYC-verified person is anchored behind it (verified_human: true when the grant is linked to a VERIFIED identity verification).
  • Which agent — a name (and optionally a URL) identifying the agent or its operator.
  • What it may do — a scope list you define, e.g. ["email:draft", "calendar:read", "purchases:under-100-eur"]. Scopes are your vocabulary; verifiers read them back and enforce them.
  • Until when — an expiry (default 30 days, maximum one year), plus revocation at any moment from the granting account.

Grant a delegation

POST /agent-delegations with your Secret Key:

{
  "agent_name": "claude-support-bot",
  "scope": ["tickets:read", "tickets:reply"],
  "ttl_seconds": 604800,
  "verification_id": "<uuid of a verification definition>",
  "customer_id": "user-42"
}

verification_id + customer_id are optional: pass them to anchor the delegation to an identity verification that has already reached VERIFIED — that is what turns on verified_human. The response contains the delegation record and the signed token; give the token to the agent.

Verify a delegation

POST /agent-delegations/verify with {"token": "..."} — from any account. The response is {"valid": true, "delegation": {...}} with the agent name, scope, delegator, expiry and verified_human — or {"valid": false, "reason": "..."} when the signature fails, the delegation has expired, or it has been revoked. Verify at time of use, not once at the start of a session: revocation only shows up here.

Revoke

POST /agent-delegations/:id/revoke. Immediate and idempotent; the agent’s token fails every verification from that moment. GET /agent-delegations lists your grants.

From an agent, over MCP

The same three operations are MCP tools on https://api.shinid.com/mcp, so agents handle delegations themselves:

ToolWhat it does
create_agent_delegationMint a delegation for a named agent — returns the signed token
verify_agent_delegationCheck a token another agent presents to you — valid/invalid with the grant or the reason
revoke_agent_delegationWithdraw a grant immediately

A typical exchange: an agent contacts your business claiming to act for a customer. Your own agent calls verify_agent_delegation with the presented token, sees valid: true, scope: ["orders:place"], verified_human: true — and proceeds, knowing a KYC-verified person authorized exactly this.

Sandbox keys mint and verify sandbox delegations only, live keys live ones — the same mode split as the rest of the API.