MoltID: Agent Type Classification, Cascade Revocation & SPIFFE Bridge — Live on MolTrust

TL;DR

Today we're launching MoltID -- MolTrust's Agent Identity & Governance module.

Three features ship today:

Agent Type Classification -- classify agents as orchestrator, autonomous, human_initiated, or copilot, with governance rules and trust modifiers per type
Cascade Revocation -- revoke a compromised agent and its entire downstream delegation tree in one API call (DFS, max 8 hops, CAEP events)
SPIFFE Bridge -- map existing SPIFFE URIs to W3C DIDs, enriched with MolTrust trust scores and classification

All live. All W3C standards. All anchored on Base L2.

The Problem

AI agent deployments are growing fast -- and so is the governance gap.

An orchestrator spawns sub-agents. Sub-agents delegate further. Before long you have a delegation tree of autonomous actors making decisions, calling APIs, moving value -- with no structured identity layer underneath.

94% of organizations experienced AI agent security incidents (OutSystems 2026)
Only 12% have a central governance platform

MoltID is the missing layer.

Feature 1: Agent Type Classification

The idea

Not all agents carry the same trust assumptions. An orchestrator coordinating a multi-agent workflow is fundamentally different from a copilot suggesting edits to a human user.

MoltID formalizes this with four agent classes:

Class	Description	Trust Modifier	Min Trust Score
orchestrator	Coordinates other agents	+5	70
autonomous	Self-directed, no human loop	0	60
human_initiated	Triggered by a human action	0	50
copilot	Human-assisted, advisory	-10	40

API

# Set agent class
POST /identity/agent-type/did:moltrust:abc123
Authorization: Bearer <api_key>
{
  "agent_class": "orchestrator",
  "framework": "langchain",
  "version": "0.2.1"
}

# Read class + governance rules
GET /identity/agent-type/did:moltrust:abc123

{
  "did": "did:moltrust:abc123",
  "agent_class": "orchestrator",
  "trust_modifier": 5,
  "governance": {
    "min_trust_score": 70,
    "review_frequency": "weekly",
    "audit_required": true
  }
}

# List all types
GET /identity/agent-types

A2A Agent Card integration

The agent class is exposed in the per-DID A2A Agent Card at /a2a/agent-card/{did}:

{
  "agent_classification": {
    "class": "orchestrator",
    "framework": "langchain",
    "governance_tier": "high",
    "trust_modifier": 5
  }
}

Machine-readable for any A2A-compatible system.

CAEP events

Every class change fires an agent_class_changed event to the caep_events table -- full audit trail.

Feature 2: Cascade Revocation

The idea

When an agent is compromised, you need more than a point revocation. You need to revoke the entire downstream delegation tree.

MoltID tracks delegation relationships in agent_delegations and supports cascade revocation with a single API call.

API

# Revoke single agent
POST /identity/revoke/did:moltrust:abc123
Authorization: Bearer <api_key>
{ "reason": "credential leaked" }

# Cascade revoke (revokes target + all downstream delegated agents)
POST /identity/revoke/did:moltrust:abc123
Authorization: Bearer <api_key>
{ "reason": "compromised", "cascade": true }

Response:

{
  "revoked": "did:moltrust:abc123",
  "affected_agents": [
    { "did": "did:moltrust:abc123", "depth": 0 },
    { "did": "did:moltrust:child-agent-1", "depth": 1 },
    { "did": "did:moltrust:child-agent-2", "depth": 1 }
  ],
  "count": 3
}

# Check revocation status
GET /identity/revocation-status/did:moltrust:abc123

{ "revoked": true, "revoked_at": "2026-04-15T...", "downstream_delegations": 2 }

# View delegation tree
GET /identity/delegations/did:moltrust:abc123

# Reinstate (admin only)
POST /identity/unrevoke/did:moltrust:abc123

Cascade mechanics

DFS traversal of agent_delegations table
Max 8 hops (configurable)
Visited-set prevents cycles
Children fetched before delegation records are revoked (ordering guarantee)
Every revoked agent: trust_score goes to 0.0, grade becomes "REVOKED", trust cache invalidated
CAEP event per revoked agent

Trust score integration

{
  "did": "did:moltrust:revoked-agent",
  "trust_score": 0.0,
  "grade": "REVOKED",
  "breakdown": { "revoked": true, "reason": "compromised" },
  "flags": ["revoked"]
}

Short-circuits before Phase 2 computation. No stale cached scores.

Feature 3: SPIFFE Bridge

The idea

Enterprise infrastructure already has workload identity: SPIFFE (Secure Production Identity Framework for Everyone). Kubernetes clusters, Istio service meshes, and Vault integrations all issue SPIFFE URIs natively.

The SPIFFE Bridge maps these URIs to MolTrust W3C DIDs -- no migration required.

spiffe://company.com/agent/trading-bot-01
  |  bind once
  v
did:moltrust:abc123
  |  enriched with
  v
trust score + agent class + revocation status + on-chain VC

API

# Bind a SPIFFE URI to an existing DID
POST /identity/spiffe/bind
Authorization: Bearer <api_key>
{
  "spiffe_uri": "spiffe://company.com/agent/trading-bot-01",
  "did": "did:moltrust:abc123"
}

# Resolve SPIFFE URI to DID + full MoltID context
GET /identity/spiffe/spiffe://company.com/agent/trading-bot-01

{
  "spiffe_uri": "spiffe://company.com/agent/trading-bot-01",
  "moltrust_did": "did:moltrust:abc123",
  "display_name": "Trading Bot 01",
  "trust_score": 82.5,
  "grade": "A",
  "agent_classification": {
    "agent_class": "autonomous",
    "governance": {
      "cascade_revocation_priority": "high",
      "min_trust_score_required": 50,
      "review_frequency_days": 90
    }
  },
  "revoked": false,
  "bound_at": "2026-04-15T..."
}

# List all bindings
GET /identity/spiffe
Authorization: Bearer <api_key>

# Remove binding (admin)
DELETE /identity/spiffe/bind/spiffe://company.com/agent/trading-bot-01
Authorization: Bearer <admin_key>

What's deferred to Q3

Full SPIFFE stack (SVID issuance, Workload API, X.509-SVID signing) is Q3 2026. The bridge covers the lookup/binding layer only -- enough for most enterprise integration use cases.

Regulatory alignment: IMDA MGF

The Singapore IMDA Model AI Governance Framework for Agentic AI (January 2026) defines four governance requirements for agentic systems:

IMDA Requirement	MoltID Implementation
Accountability	Every agent has a classified DID, anchored on Base L2
Transparency	Agent class + trust score publicly queryable
Controllability	Cascade revocation -- kill switch across full delegation tree
Human oversight	human_initiated / copilot classes enforce review cadences

MoltID doesn't just align with the framework -- it implements it as code.

Getting Started

npm

npm install @moltrust/sdk

import { AgentTrust } from '@moltrust/sdk';

const trust = await AgentTrust.verify('did:moltrust:abc123');
console.log(trust.agent_class);    // "orchestrator"
console.log(trust.trust_modifier); // 5
console.log(trust.revoked);        // false