ИИ-агент: регистрация, манифест, runtime и вход в КТМ на механизмах ветки (R6–R8)

Сквозной сценарий

runtime агента                 организация (owner)              did-svc / vc-svc            КТМ
──────────────                 ───────────────────              ────────────────            ───
1 генерирует ключи
  (KMS/HSM/CSP), отдаёт
  только публичные ──────────▶ 2 собирает DID Document агента:
                                 owner = DID организации,
                                 assertionMethod/auth/
                                 capabilityInvocation = ключ агента
                                 подписывает Create ─────────▶ 3 проверяет подпись owner,
                                                                 согласие owner, ключи      ✅ есть
                               4 манифест агента (AGENTS.md,
                                 MCP, маршруты, модель, seed)
                                 → VC AgentManifestCredential,
                                 VC-JWT своим ключом ────────▶ 5 принимает, проверяет
                                                                 подпись издателя           ✅ есть
6 стартует, сверяет свой
  фактический манифест с VC;
  о смене runtime — VC
  AgentRuntimeCredential
  своим ключом ──────────────────────────────────────────────▶ 7 принимает (issuer = агент)  ✅ есть
                                                                 правило мандата            ⬜ нет
8 вход: подписывает challenge
  ключом authentication ─────────────────────────────────────────────────────────────────▶ 9 резолвит DID,
                                                                                              проверяет подпись,
                                                                                              VC-мандат,
                                                                                              allow-list   ⬜ нет

Что уже есть (код ветки)

Что дописать

R6. Манифест — схема credentialSubject для AgentManifestCredential

{
  "id": "did:ru:agent:z…",
  "instructions": [{"path": "AGENTS.md", "digest": "sha256:…"}, {"path": "CLAUDE.md", "digest": "sha256:…"}],
  "skills": [{"name": "task", "version": "…", "digest": "sha256:<merkle root каталога>"}],
  "mcpServers": [{"name": "mcp-link", "did": "did:…", "toolsDigest": "sha256:<схемы tools>", "tools": ["peer"]}],
  "routes": [{"method": "POST", "path": "/api/v1/contracts/{id}/sign"}],
  "model": {"kind": "open-weights", "weightsDigest": "sha256:…", "runtime": "vllm@…", "seed": 42, "temperature": 0},
  "determinismClass": "D3",
  "manifestDigest": "sha256:<канонический JSON выше>"
}

Нужно: правило канонизации (manifestDigest), утилита расчёта хэшей каталогов (Merkle по файлам), валидация схемы при приёме VC этого типа. Оценка — 1–2 дня.

R7. Правило мандата для runtime-VC

AgentRuntimeCredential от агента принимается, но «в силу» вступает, только если его manifestDigest совпадает с действующим AgentManifestCredential от owner; иначе verify → not_approved_by_owner. Это и есть ответ на открытый вопрос «самопрезентация агента»: агент сообщает сам, но полномочия даёт только подпись организации. Оценка — 1 день.

R8. Вход в КТМ

КТМ выдаёт nonce, агент подписывает {aud: КТМ, nonce, iat} ключом из authentication (тот же didproof.SignPayload), КТМ резолвит DID (gRPC ResolveDID), проверяет подпись, действующий AgentManifestCredential и пускает только на routes. Сертификат (x5c) — проверка PKI-сервисом. Нужно решить с владельцами КТМ/auth-svc: где живёт проверка (шлюз или auth-svc) и формат токена сессии после входа. Оценка — 2–3 дня вместе с интеграцией.

Вопросы

1. Типы VC (AgentManifestCredential, AgentRuntimeCredential, мандат) — согласовать имена со статьёй (AgentMandateCredential, AgentAttestationCredential в did/article/context.md).

2. MCP-серверы третьих сторон — получают DID у нас (did:<m>:mcp:…) или did:web?

3. P2P (mcp-link/peer): обмен между агентами шифруем keyAgreement (X25519 уже поддержан в проверке ключей) или только подписываем?

Журнал изменений