Agent Identity & DID (Decentralized Identifiers)(Цифрова ідентичність та аутентифікація агентів)

1. Огляд концепції та системна проблема

У період зародження агентів розробники просто прокидали свої особисті API-ключі або паролі в змінні оточення скриптів. У 2026 році, коли агенти управляють фінансовими транзакціями, керують продакшн-серверами та взаємодіють із зовнішніми контрагентами, такий підхід став неприйнятним:

• Відсутність аудиту: Логи показують, що комміт зробив "Олександр", хоча Олександр спав, а код писав автономний агент.
• Катастрофічний радіус ураження: Якщо агент зламаний через prompt injection, зловмисник отримує всі права людини, включно з доступом до особистої пошти та адмін-панелей.

Agent Identity впроваджує концепцію агента як повноправного цифрового суб'єкта з криптографічним паспортом, відкритими ключами та обмеженими повноваженнями.

2. Архітектурна таксономія та ментальна модель

┌─────────────────────────────────────────────────────────────┐
│               AGENT IDENTITY & TRUST STACK                  │
├─────────────────────────────────────────────────────────────┤
│ 1. Cryptographic Key Management (HSM / Secure Enclave)      │
│    • Private Key (never leaves isolated memory)             │
│    • Public Key / DID URI (did:key:z6MkuT...)               │
├─────────────────────────────────────────────────────────────┤
│ 2. Verifiable Credentials & Delegation Chains               │
│    • Issuer: Human Owner (Org Root Certificate)             │
│    • Scope: "Can execute read/write on repo:app, max $10"   │
│    • Expiration: Ephemeral tokens (TTL = 1 hour)            │
├─────────────────────────────────────────────────────────────┤
│ 3. Attestation & Proof of Execution                         │
│    • Git Commit Signatures (GPG / SSH Sig)                  │
│    • Signed MCP & A2A Requests                              │
├─────────────────────────────────────────────────────────────┤
│ 4. Audit & Revocation Infrastructure                        │
│    • Instant Key Revocation (Kill Switch)                   │
│    • Immutable Append-Only Ledger for Audit Logs            │
└─────────────────────────────────────────────────────────────┘

1. DID (Decentralized Identifier): Унікальний ідентифікатор агента у форматі W3C (наприклад, did:web:company.com:agents:devops-01), який дозволяє будь-якій системі отримати його публічний ключ без звернення до централізованих баз даних.
2. Short-Lived Delegation (Короткоживуче делегування): Людина підписує дозвіл для агента на 60 хвилин. Навіть якщо агент вийде з-під контролю, його сертифікат автоматично втратить силу.

3. Практичні інженерні сценарії в продакшені

01. Контрольований деплой інфраструктури

Агент отримує короткочасний сертифікат на оновлення одного конкретного кластера Docker на VPS. Якщо агент намагається виконати команду на іншому сервері, шлюз безпеки відхиляє запит через невалідний підпис.

02. Підписання коммітів для відповідності ISO 27001 / SOC 2

Усі комміти, згенеровані ШІ, позначаються окремим підписом GPG Signed by Agent ID: 4092. Аудитори чітко бачать, які рядки коду пройшли людський код-рев'ю, а які були створені автономно.

4. Підводні камені, типові помилки та безпека

• Зберігання приватних ключів у відкритих файлах: Якщо агент записує свій private_key.pem у робочу директорію, зловмисник може викрасти його через виклик читання файлів. Ключі повинні зберігатися в Secure Enclave або HashiCorp Vault.
• Відсутність механізму аварійного відкликання (Kill-Switch): Кожен агент повинен мати статус перевірки активності: одна зміна прапорця в IAM-системі повинна миттєво анулювати всі його підписи та токени.

5. Стратегічний висновок для інженера 2026 року

Agent Identity переводить роботу з ШІ з площини аматорських експериментів у площину корпоративної безпеки та юридичної відповідальності. Безпечний агент — це не просто модель у циклі, це верифікований суб'єкт із чітко окресленими кордонами довіри.