Кто отправляет этот запрос? Аутентификация агентов 101 — Камиль Потрек, Keycard

Original · Who Is Making This Request? Agent Auth 101 - Kamil Potrec, Keycard

18:353 min readAI Engineer10/28/2026Computing/Software · Internet Technology

Key Takeaway

Безопасность агентов перестала быть опцией, а защита их учетных данных требует внедрения открытых стандартов, динамических учетных данных и шлюзов.

Highlights

  • Традиционные токены доступа пользователей никак не привязаны к конкретному устройству, из-за чего их легко перенести на личную машину и скомпрометировать.

  • Недетерминированная природа искусственного интеллекта приводит к тому, что агенты накапливают учетные данные и могут случайно или злонамеренно отправить конфиденциальные данные пользователю.

  • Использование шлюзов позволяет полностью изолировать учетные данные от среды выполнения агента и перехватывать все запросы на лету.

  • Платформа Keycard предоставляет единую плоскость управления для наделения агентов уникальной идентичностью, выдачи токенов и интеграции с существующими системами.

Timeline

  1. Взаимодействие агентов с учетными данными

    Агентам необходимы собственные учетные данные для связи с провайдерами моделей и удаленными серверами MCP. Однако серверы MCP видят только пользователя и не знают, запущен ли запрос через командную строку или другой инструмент. Из-за этого сервисные учетные записи аккумулируют широкие привилегии, а недетерминированная природа моделей делает принятие решений непредсказуемым.

    • Пользователи часто передают агентам персональные токены доступа или статические ключи API.
    • Удаленные серверы MCP используют учетные записи служб для работы от имени множества пользователей.
    • Недетерминированное поведение агентов порождает новые риски при выполнении запросов к внутренним сервисам.
  2. Проблемы безопасности неконтролируемых токенов

    Пользователи могут легко переносить токены доступа на личные машины, обходя корпоративные средства защиты. Раньше индустрия мирилась с рисками безопасности в ПО, полагаясь на надежность разработчиков. Агенты действуют как самостоятельные участники, постоянно оперируя чужими учетными данными, что создает постоянную уязвимость, сравнимую с оставленным без присмотра ноутбуком.

    • Существующие токены доступа не привязаны к защищенной корпоративной инфраструктуре.
    • Отсутствие простых механизмов отзыва учетных данных приводит к высокому риску злоупотреблений.
    • Появление автономных агентов принципиально отличает текущую ситуацию от традиционного программного обеспечения.
  3. Переход к динамической аутентификации

    Необходимо внедрять механизмы, при которых агенты запрашивают авторизацию у внешних систем перед выполнением действий. Использование OAuth, сертификатов и закрытых ключей позволяет выдавать кратковременные учетные данные, привязанные к конкретным инструментам. Это устраняет практику использования постоянных сервисных учетных записей с избыточными правами.

    • Динамические учетные данные ограничиваются конкретным взаимодействием и автоматически завершают работу.
    • Технологии OAuth и федерация удостоверений рабочих нагрузок позволяют решить задачу аутентификации агентов.
    • Устранение цикла рассуждений показывает, что агент технически близок к обычному программному обеспечению.
  4. Масштабирование и ограничения SDK

    В реальных условиях экосистема состоит из сотен разнообразных API со своими серверами авторизации. Написание SDK для каждого языка программирования не защищает от ошибок разработчиков и ухищрений самих агентов. Если учетные данные физически находятся в среде выполнения агента, их безопасность оказывается под угрозой.

    • Масштабирование системы усложняется наличием сотен различных API и множества независимых агентов.
    • Клиентские SDK не способны полностью решить проблему безопасности из-за возможных багов и настойчивости агентов.
    • Агенты способны кэшировать и использовать любые учетные данные, попадающие в их среду выполнения.
  5. Использование шлюзов и решение Keycard

    Размещение учетных данных в защищенном хранилище и пропуск всего трафика через шлюзы обеспечивает мгновенный отзыв прав и детальный анализ запросов. Продуктовая команда Keycard разработала единую плоскость управления, объединяющую идентификацию, политики и аудит. Использование открытых стандартов и эталонной реализации agentbaseline.org позволяет безопасно создавать сложные агентские системы.

    • Шлюзы изолируют учетные данные в защищенном анклаве и перехватывают весь сетевой трафик.
    • Платформа Keycard предоставляет единую плоскость управления, политики, аудит и клиентские SDK.
    • Безопасность агентов требует применения открытых стандартов и совместимости между различными системами.

Description

When an agent sends an invoice using your token, who actually made the request? Kamil Potrec of Keycard breaks down how agents get credentials today (personal tokens, static keys, over-privileged service accounts) and what proper agent auth requires: per-agent identity, delegation, short-lived scoped credentials, federation with legacy systems, policy and audit. He compares SDKs and gateways for keeping credentials out of an agent's reach, including the gateway tradeoffs. Chapters: 0:00 Intro 0:43 How agents get credentials today 3:46 What's wrong with this picture 5:15 Using OAuth for agents 7:10 Why it gets hard at scale 8:21 What proper agent auth needs 9:52 One request, many steps 11:16 Why SDKs aren't enough 12:37 Gateways: keep credentials away from agents 14:55 Gateway tradeoffs 16:24 How Keycard approaches it 17:26 Takeaways Kamil Potrec https://keycard.ai Agent Baseline: https://agentbaseline.org Join us in SF for the second annual AIE CODE summit: https://aie.codes our last flagship summit of 2026. Applications live now!

Write about this video