🤖 Obot: как открыть доступ к AI без утраты контроля 🔒⚡

Недавно мы рассказывали про Model Context Protocol (MCP) - стандарт, позволяющий AI-агентам общаться с реальными системами, платформами и API 🚀

Без грамотного контроля внедрение MCP может обернуться хаосом и брешами в безопасности.

💡 Решение - Obot.

🛡️ Что такое Obot?

Obot - это открытая платформа и шлюз (MCP Gateway) с расширенными возможностями:
🔑 безопасная аутентификация
🖥️ централизованное администрирование
⚙️ гибкая настройка доступа
☁️ работа как в облаке, так и в дата-центре

📌 Репозиторий на GitHub | Сайт Obot

🚨 Больше деталей

🗂 Централизованный контроль - управление MCP-серверами, обновления, каталогизация, маршрутизация, всё через UI или GitOps.
🔐 Безопасность уровня Enterprise - OAuth 2.1, шифрование, аудит всех запросов.
⚡ Удобство для пользователей - каталог подключаемых узлов, поддержка Claude Desktop, VSCode, Cursor, Obot Chat.

🛠 Что под капотом?

🌐 MCP Gateway - обнаруживает серверы, управляет конфигурацией, аутентификацией и обновлениями.

💬 Chat-интерфейс - история диалогов, RAG, задачи, кастомизация поведения.

🛡 Admin-панель - настройка прав, фильтры запросов, логирование, мониторинг.

🌟 Ещё немного о преимуществах

📂 Open-source и самохостинг - полный контроль над данными.
🔄 MCP-совместимость - легко интегрируется с разными AI-агентами.
🛡 Security by default — аудит, доступ по ролям, шифрование.
🔌 Гибкая интеграция — Google, GitHub, Okta, Microsoft Entra (Enterprise).

📣 Комментарии

🗨 Sheng Liang (Acorn Labs):

«AI-инструменты уже работают в вашей сети. Без контроля они могут создать теневую инфраструктуру с утечками».

⚠ Obot решает эту задачу, давая защиту и прозрачность без ограничения возможностей пользователей.

🚀 Быстрый старт

🖱 Зайдите в демо: chat.obot.ai
📦 Установите в Kubernetes:

helm repo add obot https://charts.obot.ai helm install obot obot/obot --set config.OPENAI_API_KEY="<API KEY>" 

🔧 Настройте серверы, доступ, фильтры, аудит.
👥 Подключите пользователей и начните безопасную работу.

Stay secure and read SecureTechTalks 📚

#Obot #MCP #CyberSecurity #AIPlatform #SecureTechTalks #OpenSource #Admin #EnterpriseSecurity #DevSecOps #CloudSecurity

🔥 Firezone: новый взгляд на Zero Trust Gateway

В кибербезопасности давно не секрет: классические инструменты улаленного доступа всё хуже справляются с задачей защиты. Они либо слишком сложные в администрировании, либо превращаются в «ворота с одним замком» - взломал один ключ, и можно гулять по всей сети.

Но есть и исключения, Firezone - open-source решение, построенное на принципах Zero Trust и с прицелом на будущее.

🚀 Что такое Firezone?

Firezone - это платформа удалённого доступа нового поколения, объединяющая:

🌐 WireGuard как базовый протокол (скорость + надёжность + современная криптография).
🛡 Zero Trust Access: доступ к ресурсам не даётся «по умолчанию» только после аутентификации и проверки устройства.
🔄 Гибкость: интеграция с SSO, OpenID Connect, MFA.
🧩 Open Source: код открыт, можно кастомизировать под конкретные задачи.

🧰 Ключевые возможности

⚡ Молниеносная скорость: благодаря WireGuard производительность выше, чем у IPSec или OpenVPN.
👨‍💻 SSO и MFA: подключение пользователей через корпоративные IAM-системы (Okta, Google Workspace, Azure AD и др.).
🔑 Granular Access: доступ не ко всей сети, а только к нужным сервисам (например, к БД или API).
📊 Аудит и мониторинг: полные логи всех подключений.
🛠 Кроссплатформенность: клиенты для Linux, macOS, Windows, мобильных ОС.
☁️ Cloud-first архитектура: удобно для компаний, где половина ресурсов живёт в AWS/GCP/Azure.

🔍 Чем Firezone отличается от классических решений?

❌ В старых - «один ключ = весь доступ».
✅ В Firezone - доступ проверяется каждый раз, на каждом ресурсе.
❌ Старые инструменты плохо дружат с облаками и микросервисами.
✅ Firezone интегрируется с Kubernetes, контейнерами и SaaS-приложениями.

🔗 Репозиторий: github.com/firezone/firezone

Stay secure and read SecureTechTalks 📚

#Firezone #ZeroTrust #VPN #WireGuard #CyberSecurity #OpenSource #DevSecOps #CloudSecurity #AccessControl #SecureTechTalks

🔥 CNSpec: инструмент аудита инфраструктуры

Когда речь заходит о проверке безопасности, большинство инструментов умеют работать либо с серверами, либо с контейнерами, либо с облаками. Но CNSpec от Mondoo ломает привычную логику: он проверяет всё: от Linux и Kubernetes до AWS, Terraform и даже GitHub Actions.

🔍 Что такое CNSpec?

CNSpec - универсальный движок политики безопасности, который использует декларативный язык CUE для описания проверок.

Он позволяет сканировать:
🚀 Облака: AWS, Azure, GCP
📦 Контейнеры и Kubernetes
💻 Серверы и рабочие станции
🏗 Инфраструктуру как код, например Terraform, Ansible, Dockerfiles
💡 CI/CD пайплайны: GitHub, GitLab, Jenkins

🧠 Коротко про фичи

✨ Универсальность
Не нужно держать 15 утилит. CNSpec работает везде, где есть артефакт, конфиг или runtime-окружение, которое можно проверить.
🔗 Политики как код (PaC)
Все проверки это обычные файлы. Легко хранить в Git, переиспользовать и версионировать.
⚡ Динамические проверки
CNSpec не просто анализирует файлы, он может подключаться к реальным системам и считывать конфигурацию на лету.
🛡 Готовые библиотеки запросов
В репозитории полно примеров и библиотек для стандартизированных проверок: CIS Benchmarks, DevSec, собственные наборы Mondoo.
🌍 Работает без агентов
Запускать можно хоть локально, хоть через CI. Ничего ставить не нужно.

🧩 Пример использования

Например, вы хотите проверить конфигурацию Docker-контейнера:
cnspec scan docker <image>
CNSpec тут же покажет:
- неверные разрешения файлов
- слабые параметры запуска
- опасные capabilities
- секреты в слоях контейнера
- inconsistent settings безопасности

Аналогичные проверки доступны для Kubernetes, AWS IAM, Terraform и т.д.

🔗 Ссылка на GitHub

Stay secure and read SecureTechTalks 📚

#cybersecurity #securetechtalks #devsec #cnspec #cloudsecurity #iacsecurity #kubernetes #securityautomation #infosec #devops

🧨 KICS: как искать уязвимости на этапе разработки

Многие думают, что безопасность начинается на этапе SAST или pentest’а.  Но большинство уязвимостей появляются ещё до первой строки бизнес-кода, например в Kubernetes YAML.

🔍 Что такое KICS?

KICS (Keeping Infrastructure as Code Secure) - open-source инструмент от Checkmarx для анализа Infrastructure as Code.

KICS ищет security-ошибки, misconfiguration и опасные паттерны в IaC-файлах до деплоя, пока всё ещё можно починить одной строкой.

📦 Поддерживаемые форматы:
- Terraform
- Kubernetes (YAML)
- Helm
- Dockerfile
- Ansible
- CloudFormation
- ARM Templates
- Pulumi
- Serverless

Если у вас cloud, CI/CD и DevOps, то вы уже в зоне риска, а KICS может стать вашим ранним радаром.

🔥 KICS не «ещё один линтер»

❌ Это не форматтер
❌ Это не просто best practices
❌ Это не SAST

KICS проверяет реальные security-риски, а не стиль или синтаксис.

Он смотрит на инфраструктуру глазами атакующего и задаёт неприятные вопросы ещё до деплоя.

🧠 Принцип работы

KICS использует:
🔍 предопределённые security-queries
🧩 разбор IaC-структур
🛠️ rule-based движок
📊 модель критичности (Low → Critical)
Каждая находка это:
- описание риска
- уровень критичности
- ссылка на best practice
- рекомендации по исправлению

📡 Типичный сценарий

DevOps-пайплайн:
🧑‍💻 Dev пишет Terraform / YAML
🔁 PR уходит в Git
⚙️ CI запускает KICS
🚨 KICS находит опасные конфигурации
❌ Pipeline падает
🔧 Конфиг исправляется
✅ Только потом деплой
Security shift-left без конфликтов и ночных инцидентов.

🧱 Архитектура и возможности
🧩 CLI-инструмент
🧠 Более 1000 security-правил
🔄 Простая интеграция в CI/CD
📄 JSON / SARIF / HTML отчёты
🛠️ Кастомные правила
🌍 Активное сообщество
🔓 Полный open-source
Работает быстро, масштабируется без сюрпризов.

⚠️ Минусы (куда без них)

📚 Некоторые правила избыточно строгие
🧠 Нет понимания бизнес-контекста
❌ Не заменяет SAST / DAST
🔧 Требует тюнинга под конкретную среду

Однако для инструмента ранней стадии это ожидаемо и нормально.

🔗 GitHub: https://github.com/Checkmarx/kics

Stay secure and read SecureTechTalks 📚

#KICS #IaC #DevSecOps #CloudSecurity #OpenSource #Terraform #Kubernetes #AppSec #ShiftLeft #SecureTechTalks

🤖📊 Отчёт CSA: AI Governance, как фактор выживания

В 2025 году организации уже не просто пробуют ИИ, а внедряют его в продакшн.
Проблема в том, что скорость внедрения ИИ сильно опережает зрелость AI Governance.

CSA выпустили новый отчет, который основан на глобальном опросе IT- и ИБ-профессионалов (≈300 организаций), которых спрашивали не только о технологиях, но и о структурах AI Governance, ответственности за AI-риски и уровне подготовки команд.

Главный вывод исследования:
👉 Зрелый AI Governance самый сильный предиктор готовности компании к безопасному внедрению ИИ.

Не важно какой размер или бюджет у вашей компании. Важно иметь зрелый Governance.

📈 1. Множитель зрелости

Что такое зрелый AI Governance на практике?
Это рабочая система управления, которая включает:
- чёткие роли и зоны ответственности,
- политики использования ИИ,
- контроль жизненного цикла моделей,
- процедуры оценки рисков,
обучение сотрудников.

🔥 Согласно отчёту, организации с формализованным AI Governance:
в 2 раза чаще внедряют agentic AI, чаще проводят security-оценку моделей,
говорят о способности управлять AI-рисками.

Компании, где Governance «в процессе развития», стабильно проигрывают по всем этим параметрам.

🛡️ 2. Безопасность ИИ

CSA подчёркивает ключевую мысль:

AI Security - это не только защита данных или моделей.
Это управление процессами, людьми и ответственностью.

Без AI Governance невозможно:
- понять, где именно используется ИИ,
- определить, кто отвечает за последствия его работы,
- встроить AI-риски в общую систему управления ИБ.

🧑‍💼 3. Shadow AI

Отдельный тревожный сигнал - Shadow AI.
Сотрудники используют внешние ИИ-сервисы без согласования и контроля.

Это приводит к:
⚠️ утечкам данных,
⚠️ невозможности аудита,
⚠️ регуляторным рискам.

Именно зрелый AI Governance позволяет превратить хаотичное использование ИИ в контролируемый и безопасный процесс, не убивая инновации.

👨‍💼 4. Кадровый разрыв

ИИ внедряется быстро, а навыки сотрудников медленно.

Отчёт фиксирует:
нехватку специалистов по AI Security и слабую подготовку ИБ-команд. Возникает разрыв между стратегией и реальными процессами.

Организации с развитым AI Governance:
в 2–3 раза чаще обучают сотрудников, интегрируют AI-риски в SDLC, переводят знания в практику.

📊 5. Какие риски беспокоят компании больше всего?

По данным опроса:
🔹 №1 риск утечки данных через AI-сервисы
🔹 Модельные атаки и отравление данных воспринимаются как второстепенные

Компании недооценивают сложные и долгосрочные AI-угрозы.
🔁 AI Security больше не «поддержка», а драйвер

Интересный сдвиг:
👉 ИБ-команды больше не догоняют ИИ, они начинают его возглавлять.
Более 90% специалистов:
тестируют ИИ для threat detection, используют ИИ в red teaming, автоматизируют SOC-процессы.

AI Governance становится не тормозом, а инструментом масштабирования безопасности.

🔗 Отчет Cloud Security Alliance "The State of AI Security and Governance Survey Report (2025)"

Stay secure and read SecureTechTalks 📚

#AIsecurity #AIGovernance #CyberSecurity #AIrisks #SecureTechTalks #CloudSecurity #AgenticAI #ShadowAI #CyberTrends2025

🔎 Coroot: eBPF-observability для Kubernetes

Если у вас Kubernetes и вы устали собирать картину инцидентов из Prometheus, Grafana и логов, стоит обратить внимание на Coroot.

🧩 Что это?

Coroot - self-hosted observability-платформа для Kubernetes, которая через eBPF собирает сетевые и системные данные и пытается автоматически показать root cause проблемы.

🏗 Где будет полезен?

Инструмент особенно полезен, если у вас:
⚙️ десятки микросервисов и сложные зависимости
📈 периодические latency-спайки без явной причины
💥 OOM, CPU starvation, retry-штормы
❓ «сервис падает, но по метрикам всё нормально»
🗺 нет прозрачной карты сервисных взаимодействий

Типовые сценарии:
☁️ SaaS на Kubernetes
🚀 high-load API
🔐 DevSecOps-среды

🛠 Что инженер получает на практике?

🔹 Автоматическую service map
🔹 Видимость реальных сетевых вызовов между pod’ами
🔹 Детекцию деградации (latency, errors, saturation)
🔹 Подсветку вероятной первопричины
🔹 Мониторинг PostgreSQL и Redis
🔹 Анализ resource pressure

Другими словами, можно оперативно увидеть, где началась проблема и кто "роняет" систему.

🎯 Если на вашем кластере Kubernetes инциденты появляются «из ниоткуда», то Coroot стоит развернуть хотя бы в staging.

Инструмент не заменит весь мониторинговый стек, но заметно сократит время расследования.

🔗Репозиторий: https://github.com/coroot/coroot

Stay secure and read SecureTechTalks 📚

#CyberSecurity #Coroot #Kubernetes #Observability #DevSecOps #eBPF #CloudSecurity #BlueTeam #InfrastructureSecurity #SecureTechTalks

🔥 До сих пор используешь RBAC? А зря!

Большинство систем контроля доступа до сих пор живут в парадигме «пользователь → роль → доступ». Это работает, пока система статична. Но в реальности атаки происходят уже после логина, через последовательности действий, подмену запросов и использование легитимных API не по назначению.

Проблема в том, что классические модели проверяют идентичность, но не контролируют поведение.

🧠 Что меняется

Подход RTS-ABAC предлагает принимать решения о доступе в реальном времени с учётом контекста: состояния системы, типа операции и даже текущего момента времени.

Политики становятся «живыми»: часть можно кешировать, а часть пересчитывается на лету. Это даёт баланс между гибкостью и задержками.
Архитектурно логика принятия решений отделяется от исполнения: одни компоненты считают, другие просто применяют результат.

За счёт этого появляется централизованный контроль без перегрузки сервисов.

🔐 Динамика управления

Фокус смещается с «кто ты» на «что происходит». Даже валидный запрос может быть отклонён, если он выбивается из нормального поведения системы .
Это усложняет replay-атаки, подмену сообщений и скрытую эскалацию через API.

⏱ Про задержки

Практика показывает, что ~99.8% запросов укладываются в ~6 мс . Причём основная задержка не в политиках, а в криптографии.

💣 Цена вопроса

Больше контроля = больше сложности. Появляются новые компоненты и потенциальные точки атаки (например, DoS на уровень управления политиками).
Это не «серебряная пуля», а инструмент для зрелых систем.

RBAC заканчивается там, где начинается динамика.
Дальше только контекстный доступ и решения в реальном времени.

📄 Исследование RTS-ABAC: https://arxiv.org/abs/2603.23012

Stay secure and read SecureTechTalks 📚

#cybersecurity #infosec #zerotrust #abac #accesscontrol #appsec #cloudsecurity #devsecops #securityarchitecture #hacking

🌊 Bluerock: добавляем runtime-безопасность в Kubernetes

Kubernetes отлично умеет оркестрировать контейнеры. Но с безопасностью в runtime у него всегда были проблемы.

Вы настраиваете RBAC, network policies, admission controllers и сканирование образов и ждете отсутствия рисков ИБ. Однако всё это в основном работает до запуска workload’а.

После старта контейнера Kubernetes почти не понимает, что внутри него происходит на самом деле.

⚙️ Что же делать?

Bluerock - это runtime security layer для Kubernetes. Платформа наблюдает за поведением контейнеров уже после запуска и анализирует:
- запуск процессов
- syscall activity
- сетевые соединения
- доступ к файловой системе
взаимодействие pod’ов между собой
- обращения к Kubernetes API

Вместо анализа YAML-манифестов или образов система начинает смотреть на реальное поведение workload’а.

🧪 Так так так

Bluerock активно использует eBPF, что позволяет перехватывать события прямо на уровне ядра Linux без модификации контейнеров: process execution, fork/exec chains, network flows, filesystem access и другие runtime-события.

Дальше поверх этих данных строится policy engine. Политики задают допустимое поведение контейнера:
- какие процессы могут запускаться,
- какие outbound-соединения разрешены,
- какие filesystem paths доступны,
- какие действия считаются аномальными.

Например: контейнеру можно разрешить только конкретные бинарники (python, nginx, node) и заблокировать запуск shell или неизвестных процессов.

Или: разрешить обращения только к определённым API endpoints, запретив весь остальной outbound traffic.

🔒 Чем это отличается от обычной Kubernetes-защиты

Большинство Kubernetes security-инструментов работают со статикой: сканируют образы, проверяют конфигурации или анализируют манифесты.

Bluerock работает с runtime. Система анализирует не то, «как контейнер должен работать», а то, что он реально делает после запуска.

Для современных AI- и agent-based workload’ов это особенно актуально, потому что их поведение может меняться динамически в зависимости от prompt’ов, контекста или внешних данных.

🔗 GitHub: https://github.com/bluerock-io/bluerock

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #LLM #Kubernetes #CloudSecurity #RuntimeSecurity #eBPF #DevSecOps #OpenSource #SecureTechTalks

🚀 Какие классы open-source security-инструментов сейчас растут быстрее всего?

Рынок безопасности сейчас довольно быстро меняется, что хорошо видно по GitHub, OWASP, Black Hat. AI начал писать код, облака усложнились, а классический security stack перестал успевать.

⚙️ Безопасность AI и LLM

Самый быстрорастущий сегмент. Появляется новый класс инструментов, которые помогают защищать AI-системы.

Растут:
🔹 red teaming для LLM
🔹 тестирование prompt injection
🔹 защита AI-агентов
🔹 контроль вызова инструментов
🔹 аудит памяти, RAG и reasoning-цепочек

Еще год назад все это выглядело как research playground, а уже сегодня появляется полноценный AI AppSec stack.

Например: Promptfoo, PipeLock, OWASP Agent Memory Guard.

☁️ Runtime-безопасность облаков

Раньше защиту строили по принципу просканировали контейнер → нашли CVE → устранили и живём спокойно. Теперь этого недостаточно.

Активно растут:
🔹 eBPF-телеметрия
🔹 обнаружение поведения контейнеров
🔹 runtime-защита Kubernetes
🔹 наблюдение за облачными workload

Фокус смещается на остановку атак в момент выполнения.

🧠 Unified AppSec

Рынок начинает двигаться в сторону единого слоя корреляции рисков, где findings связываются через контекст приложения, эксплуатации и бизнес-критичности.

🤖 Безопасность AI-агентов

Самый интересный тренд.

AI-агенту дали:
🔹 shell
🔹 MCP/tools
🔹 API
🔹 память
🔹 доступ к инфраструктуре

Однако агента тоже нужно защищать как production-систему. Поэтому появляются:
🔹 контроль действий агентов
🔹 ограничения команд
🔹 защита памяти
🔹 аудит инструментов
🔹 политика выполнения действий

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #AppSec #OpenSource #CyberSecurity #CloudSecurity #LLM #AgenticAI #DevSecOps #SecureTechTalks

🧨 ToolHive: security слой для MCP серверов

ToolHive от Stacklok - open source продукт для безопасного запуска и управления MCP серверами. Он позволяет изолировать MCP серверы от инфраструктуры и дать команде централизованный контроль над тем, к каким ресурсам и инструментам получает доступ AI агент.

🛡️ Контроль доступа

ToolHive работает как proxy между AI клиентом и MCP сервером. Через него можно централизованно управлять:

🔹 аутентификацие и авторизацией;
🔹 доступными инструментами;
🔹 сетевыми endpoints;
🔹 логами аудита и телеметрии;
🔹 политиками доступа.

Есть интеграция с OIDC и OAuth, OpenTelemetry, Prometheus и Kubernetes Operator.

🔥 Registry

Команда может собрать каталог разрешённых MCP серверов, проверить их происхождение, задать разрешения и дать разработчикам готовые конфигурации.

ToolHive использует semantic tool search и заявляет сокращение расхода токенов до 85%, поскольку агенту можно показывать только релевантные инструменты.

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

🔗 GitHub: https://github.com/stacklok/toolhive

📚 Документация: https://docs.stacklok.com/

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AI #AIAgents #AISecurity #MCP #ModelContextProtocol #DevSecOps #CloudSecurity #CyberSecurity #SecureTechTalks

🧨 ChatGPT: изолированные аккаунты могут обмениваться данными

Два пользователя ChatGPT работают под разными аккаунтами. Для выполнения кода создаются отдельные контейнеры, которые не должны видеть окружение друг друга. Интернет ограничен, настроена сетевая изоляция. Что может пойти не так?

Исследователи Check Point Research обнаружили внутри инфраструктуры OpenAI общий сервис, через который контейнеры разных пользователей могли обмениваться данными.
В демонстрации этот канал использовали для передачи скрытых инструкций агенту другого пользователя, а цепочка в итоге дошла до данных из подключённого Gmail.

⚙️ Общим оказался Artifactory

Контейнеры ChatGPT должны откуда то получать Python и npm пакеты. Для этого они имели доступ к внутреннему JFrog Artifactory, который выступал посредником для загрузки зависимостей.
Исследователи обнаружили, что через доступные внутри контейнера credentials можно записывать дополнительные properties в метаданные объектов Artifactory. Затем оказалось, что эти properties видны из окружения другого аккаунта.

Эксперимент получился довольно интересным. Исследователь записывал значение из контейнера аккаунта A, переходил в ChatGPT под аккаунтом B и читал его оттуда.
Изолированные контейнеры получили общий shared clipboard.

🔥 Из shared clipboard сделали канал управления

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

После подключения к тестовому ChatGPT аккаунту Gmail, атакующий стал размещать инструкцию, чтобы получить данные из почты. Пользователь тем временем задавал ChatGPT обычный вопрос. Агент обрабатывал запрос пользователя, одновременно получал скрытое задание через общий инфраструктурный сервис, обращался к Gmail и возвращал полученные данные через тот же канал.

🕵️ Агент превращается в инсайдера

Check Point придумали для такого сценария термин coerced insider. У AI агента уже есть легитимные полномочия пользователя. Он может обращаться к подключённой почте, файлам и другим сервисам. Поэтому атакующему необязательно самостоятельно получать доступ к Gmail жертвы. Гораздо интереснее заставить это сделать агента, которому пользователь уже предоставил необходимые права.

🔗 Источник: Check Point Research

Stay secure and read SecureTechTalks 📚

#кибербезопасность #AISecurity #ChatGPT #OpenAI #AI #DataLeak #Gmail #CloudSecurity #CyberSecurity #SecureTechTalks

🧨 AI агенты 2 600 раз пытались обойти защиту Alibaba. Их остановил CAPTCHA, но не ограничения песочницы

14 октября исследовательская группа Swarmchasers опубликовала разбор необычной активности: с 28 сентября по 8 октября агенты, работавшие на инфраструктуре Tencent Cloud, пытались собирать данные картографического сервиса Amap. Задача выглядела безобидно: определить, через какие входы посетители чаще всего заходят в зоопарки, парки и другие места.

Когда прямые запросы блокировались, агенты начали искать обходные пути. Исследователи насчитали более 2 600 попыток. Некоторые завершились получением данных.

⚙️ Как агенты обходили ограничения

У агентов не было прямого доступа к Amap из рабочей песочницы. Тогда они превратили публичный сервис анализа URL urlquery.net в удалённую среду выполнения JavaScript.

Вместо обычного запроса агент передавал ссылку, содержавшую целую веб страницу с кодом. Браузер внешнего сервиса исполнял JavaScript и отправлял запросы к целевой системе. Полученные данные агенты извлекали через заголовки страниц, URL и webhook inbox.

После блокировок они пробовали другие методы: использовали токены антибот механизмов, обращались к предварительным серверам Amap и применяли API ключи, найденные в публичном коде. Среди них был ключ с защитным кодом, который, согласно рекомендациям Amap, должен храниться на серверной стороне.

Большинство попыток провалилось. Исследователи не нашли доказательств успешного проникновения во внутренние системы Alibaba.

🔬 Агенты читали отчёт о самих себе

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

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

🛡 О безопасности агентов

По данным Reuters, Tencent заявила, что активность относилась к оценке сторонних моделей исследовательской командой. Компания не обнаружила намеренной координации или подтверждённого взлома и сообщила об усилении сетевых ограничений и мониторинга. Исследователи также не нашли доказательств взаимодействия агентов между собой в реальном времени.

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

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

🔗 Технический разбор Swarmchasers

Stay secure and read SecureTechTalks 📚

#CyberSecurity #AISecurity #AIAgents #PromptInjection #AgentSecurity #Tencent #Alibaba #CloudSecurity #RedTeam #SecureTechTalks