🔒 Дифференциальная приватность в ИИ: решение, создающее проблемы для разработчиков? 🔒
🚨 Дифференциальная приватность – одна из популярных технологий для защиты пользовательских данных в ИИ. Она добавляет случайный шум в данные, чтобы усложнить идентификацию конкретных пользователей. Однако, несмотря на её преимущества, многие разработчики сталкиваются с трудностями в поиске баланса между конфиденциальностью и точностью результатов.
⚖️ Баланс между приватностью и точностью
Основной параметр в дифференциальной приватности — это эпсилон (ε), который регулирует уровень конфиденциальности. Чем ниже значение ε, тем выше приватность, но и больше добавленного шума. Это приводит к снижению точности моделей, что может быть критическим в таких отраслях, как здравоохранение и финансы, где даже незначительные ошибки могут иметь серьёзные последствия.
🩺 Пример: Здравоохранение
В медицинских моделях, таких как те, что используются для диагностики рака, добавление шума может скрыть тонкие детали в изображениях, что увеличивает вероятность ошибочного диагноза. Это не просто техническая проблема — такие ошибки могут угрожать жизни.
💳 Пример: Финансовые сервисы
В финтехе системы обнаружения мошенничества зависят от минимальных аномалий в транзакциях. Дифференциальная приватность может «замаскировать» эти сигналы, что снижает эффективность моделей, использующих такие данные.
💡 Альтернативные подходы: федеративное обучение и умный сбор данных
Вместо дифференциальной приватности можно использовать федеративное обучение, которое позволяет тренировать модели на локальных устройствах без передачи сырых данных. Это сохраняет конфиденциальность и обеспечивает точность.
Кроме того, компании могут сосредоточиться на сборе только нужных данных, уменьшая объём информации, подлежащей анонимизации, и повышая точность моделей.
🔍 Регуляторы, такие как GDPR и CCPA, уже заставили многие компании внедрять дифференциальную приватность. Но важно, чтобы законы адаптировались к новым технологиям, позволяя разработчикам выбирать решения, подходящие для конкретных случаев, без ущерба для производительности.
📢 Дифференциальная приватность имеет свои ограничения, и она не является универсальным решением. Однако умный подход к сбору данных и использование таких технологий, как федеративное обучение, помогут разработчикам создавать точные и безопасные модели, не жертвуя инновациями.
Stay secure and read SecureTechTalks 📚
#AI #Privacy #Cybersecurity #MachineLearning #DataSecurity #SecureTechTalks #ИИ #Кибербезопасность #Конфиденциальность
🚨 Дифференциальная приватность – одна из популярных технологий для защиты пользовательских данных в ИИ. Она добавляет случайный шум в данные, чтобы усложнить идентификацию конкретных пользователей. Однако, несмотря на её преимущества, многие разработчики сталкиваются с трудностями в поиске баланса между конфиденциальностью и точностью результатов.
⚖️ Баланс между приватностью и точностью
Основной параметр в дифференциальной приватности — это эпсилон (ε), который регулирует уровень конфиденциальности. Чем ниже значение ε, тем выше приватность, но и больше добавленного шума. Это приводит к снижению точности моделей, что может быть критическим в таких отраслях, как здравоохранение и финансы, где даже незначительные ошибки могут иметь серьёзные последствия.
🩺 Пример: Здравоохранение
В медицинских моделях, таких как те, что используются для диагностики рака, добавление шума может скрыть тонкие детали в изображениях, что увеличивает вероятность ошибочного диагноза. Это не просто техническая проблема — такие ошибки могут угрожать жизни.
💳 Пример: Финансовые сервисы
В финтехе системы обнаружения мошенничества зависят от минимальных аномалий в транзакциях. Дифференциальная приватность может «замаскировать» эти сигналы, что снижает эффективность моделей, использующих такие данные.
💡 Альтернативные подходы: федеративное обучение и умный сбор данных
Вместо дифференциальной приватности можно использовать федеративное обучение, которое позволяет тренировать модели на локальных устройствах без передачи сырых данных. Это сохраняет конфиденциальность и обеспечивает точность.
Кроме того, компании могут сосредоточиться на сборе только нужных данных, уменьшая объём информации, подлежащей анонимизации, и повышая точность моделей.
🔍 Регуляторы, такие как GDPR и CCPA, уже заставили многие компании внедрять дифференциальную приватность. Но важно, чтобы законы адаптировались к новым технологиям, позволяя разработчикам выбирать решения, подходящие для конкретных случаев, без ущерба для производительности.
📢 Дифференциальная приватность имеет свои ограничения, и она не является универсальным решением. Однако умный подход к сбору данных и использование таких технологий, как федеративное обучение, помогут разработчикам создавать точные и безопасные модели, не жертвуя инновациями.
Stay secure and read SecureTechTalks 📚
#AI #Privacy #Cybersecurity #MachineLearning #DataSecurity #SecureTechTalks #ИИ #Кибербезопасность #Конфиденциальность
🔥 Штрафы до 3% от выручки и тюрьма до 10 лет! Как новые законы изменят кибербезопасность в 2025 году?
🚀 В 2025 году в России вступят в силу новые законы, которые кардинально изменят правила игры. Теперь за утечку данных можно получить многомиллионные штрафы или даже реальный срок! Разбираем главные изменения и даём рекомендации, как избежать проблем.
💰 1. Огромные штрафы за утечку персональных данных
📌 Что изменилось?
💸 Теперь за утечку персональных данных компаниям грозят штрафы до 3% от годовой выручки!
⚖ Для должностных лиц штраф составит от 200 тыс. до 1,3 млн рублей, а за повторное нарушение — до 1,5 млн рублей.
🏢 Для юридических лиц за первое нарушение штрафы останутся в пределах 3–15 млн рублей, но при повторной утечке они могут достигнуть 3% от годового оборота.
📉 Такой закон уже действует в Европе (GDPR) и привёл к тому, что компании стали серьёзно относиться к защите данных.
🛡 2. Можно ли снизить штраф?
✅ Да, если компания:
Вложила не менее 0,1% от оборота в защиту данных за последние 3 года.
Соблюдала все требования безопасности в течение последнего года.
💡Кто виноват? Что делать?
📌 Срочно пересмотреть все процессы работы с персональными данными!
📌 Обновить политику безопасности и провести аудит защиты данных.
📌 Разграничить права доступа сотрудников к данным.
🚔 3. Уголовная ответственность: до 10 лет тюрьмы!
🔍 Что изменилось?
⚠ Теперь за неправомерный доступ, использование или передачу персональных данных можно:
Лишиться свободы на 4 года и получить штраф до 300 тыс. рублей.
Если это сделал сотрудник компании — до 6 лет лишения свободы и штраф до 1 млн рублей.
А если утечка привела к тяжёлым последствиям (банкротство, ущерб здоровью) — до 10 лет лишения свободы и штраф до 3 млн рублей!
🔍 4. Роскомнадзор хочет стандартизировать обработку данных
📢 Основные предложения:
📉 Сократить количество оснований для обработки персональных данных.
🔐 Ввести единые отраслевые стандарты защиты данных.
🤝 Передавать защиту персональных данных на аутсорсинг, если у компании нет ресурсов на собственную безопасность.
🧐 Есть ли риски?
📌 Малый бизнес может не справиться с новыми требованиями.
📌 Придётся инвестировать в системы защиты, такие как DCAP-системы (контроль утечек данных).
✅ Что делать, чтобы не попасть под санкции?
🔹 Обновить системы защиты персональных данных (DLP, DCAP, SIEM).
🔹 Провести аудит информационной безопасности до конца 2024 года.
🔹 Настроить мониторинг аномальной активности сотрудников.
🔹 Разграничить доступ к критическим данным.
🔹 Готовить отчётность о выполнении требований регуляторов.
⚡ Пора действовать!
💥 Грядёт новая эра в кибербезопасности: наказания за утечки станут жёстче, а требования — строже.
🛑 Если бизнес не примет меры прямо сейчас, можно потерять миллионы рублей на штрафах или даже получить уголовное дело.
📢 Как вы думаете, поможет ли это реально снизить утечки или компании найдут способы обхода?
Делитесь мнением в комментариях!
Stay secure and read SecureTechTalks 📚
#Кибербезопасность #ПерсональныеДанные #УтечкаДанных #SecureTechTalks #ЗаконОДанных #ЗащитаИнформации #Киберугрозы #Фишинг #DataSecurity #Роскомнадзор
🚀 В 2025 году в России вступят в силу новые законы, которые кардинально изменят правила игры. Теперь за утечку данных можно получить многомиллионные штрафы или даже реальный срок! Разбираем главные изменения и даём рекомендации, как избежать проблем.
💰 1. Огромные штрафы за утечку персональных данных
📌 Что изменилось?
💸 Теперь за утечку персональных данных компаниям грозят штрафы до 3% от годовой выручки!
⚖ Для должностных лиц штраф составит от 200 тыс. до 1,3 млн рублей, а за повторное нарушение — до 1,5 млн рублей.
🏢 Для юридических лиц за первое нарушение штрафы останутся в пределах 3–15 млн рублей, но при повторной утечке они могут достигнуть 3% от годового оборота.
📉 Такой закон уже действует в Европе (GDPR) и привёл к тому, что компании стали серьёзно относиться к защите данных.
🛡 2. Можно ли снизить штраф?
✅ Да, если компания:
Вложила не менее 0,1% от оборота в защиту данных за последние 3 года.
Соблюдала все требования безопасности в течение последнего года.
💡
📌 Срочно пересмотреть все процессы работы с персональными данными!
📌 Обновить политику безопасности и провести аудит защиты данных.
📌 Разграничить права доступа сотрудников к данным.
🚔 3. Уголовная ответственность: до 10 лет тюрьмы!
🔍 Что изменилось?
⚠ Теперь за неправомерный доступ, использование или передачу персональных данных можно:
Лишиться свободы на 4 года и получить штраф до 300 тыс. рублей.
Если это сделал сотрудник компании — до 6 лет лишения свободы и штраф до 1 млн рублей.
А если утечка привела к тяжёлым последствиям (банкротство, ущерб здоровью) — до 10 лет лишения свободы и штраф до 3 млн рублей!
🔍 4. Роскомнадзор хочет стандартизировать обработку данных
📢 Основные предложения:
📉 Сократить количество оснований для обработки персональных данных.
🔐 Ввести единые отраслевые стандарты защиты данных.
🤝 Передавать защиту персональных данных на аутсорсинг, если у компании нет ресурсов на собственную безопасность.
🧐 Есть ли риски?
📌 Малый бизнес может не справиться с новыми требованиями.
📌 Придётся инвестировать в системы защиты, такие как DCAP-системы (контроль утечек данных).
✅ Что делать, чтобы не попасть под санкции?
🔹 Обновить системы защиты персональных данных (DLP, DCAP, SIEM).
🔹 Провести аудит информационной безопасности до конца 2024 года.
🔹 Настроить мониторинг аномальной активности сотрудников.
🔹 Разграничить доступ к критическим данным.
🔹 Готовить отчётность о выполнении требований регуляторов.
⚡ Пора действовать!
💥 Грядёт новая эра в кибербезопасности: наказания за утечки станут жёстче, а требования — строже.
🛑 Если бизнес не примет меры прямо сейчас, можно потерять миллионы рублей на штрафах или даже получить уголовное дело.
📢 Как вы думаете, поможет ли это реально снизить утечки или компании найдут способы обхода?
Делитесь мнением в комментариях!
Stay secure and read SecureTechTalks 📚
#Кибербезопасность #ПерсональныеДанные #УтечкаДанных #SecureTechTalks #ЗаконОДанных #ЗащитаИнформации #Киберугрозы #Фишинг #DataSecurity #Роскомнадзор
🔥 Критическая уязвимость в Apache Parquet 🔥
😱 Если вы работаете с аналитикой данных, машинным обучением или облачными вычислениями, этот пост для вас! В Apache Parquet обнаружена уязвимость уровня 10/10 по шкале CVSS v4. Это значит, что злоумышленник может незаметно проникнуть в систему, выполнить код и захватить контроль над вашими данными! 😨
❗ Что случилось?
Исследователь из Amazon Кэйи Ли обнаружил критическую ошибку в parquet-avro (CVE-2025-30065). Она связана с небезопасной десериализацией — если обработать специально созданный файл Parquet, хакер получит полный доступ к вашей системе. 😵💫
📌 Затронутые версии: 1.8.0 – 1.15.0
✅ Исправлено в: 1.15.1
🚨 Кому стоит беспокоиться?
Apache Parquet используется во множестве компаний по всему миру, например в облачных сервисах (AWS, Google Cloud, Azure) файлы Parquet передаются миллионами в день! Представьте, что произойдёт, если к этим данным получат доступ злоумышленники... 💥
🔥 Как защититься?
1️⃣ СРОЧНО обновите Apache Parquet до версии 1.15.1. 🚀
2️⃣ Проверяйте источники файлов Parquet. Не открывайте их, если не уверены в надёжности! 🚫
3️⃣ Настройте мониторинг любых аномалий при обработке файлов. 🕵️♂️
4️⃣ Проанализируйте логи на предмет попыток эксплуатации уязвимости. 📊
5️⃣ Используйте механизмы изоляции (песочницы, контейнеризация) для обработки неизвестных данных. 🔒
Stay secure and read SecureTechTalks 📚
#Кибербезопасность #BigData #ApacheParquet #DataSecurity #ИнформационнаяБезопасность #SecurityNews #Облака #ITНовости #Уязвимости #ЗащитаДанных
😱 Если вы работаете с аналитикой данных, машинным обучением или облачными вычислениями, этот пост для вас! В Apache Parquet обнаружена уязвимость уровня 10/10 по шкале CVSS v4. Это значит, что злоумышленник может незаметно проникнуть в систему, выполнить код и захватить контроль над вашими данными! 😨
❗ Что случилось?
Исследователь из Amazon Кэйи Ли обнаружил критическую ошибку в parquet-avro (CVE-2025-30065). Она связана с небезопасной десериализацией — если обработать специально созданный файл Parquet, хакер получит полный доступ к вашей системе. 😵💫
📌 Затронутые версии: 1.8.0 – 1.15.0
✅ Исправлено в: 1.15.1
🚨 Кому стоит беспокоиться?
Apache Parquet используется во множестве компаний по всему миру, например в облачных сервисах (AWS, Google Cloud, Azure) файлы Parquet передаются миллионами в день! Представьте, что произойдёт, если к этим данным получат доступ злоумышленники... 💥
🔥 Как защититься?
1️⃣ СРОЧНО обновите Apache Parquet до версии 1.15.1. 🚀
2️⃣ Проверяйте источники файлов Parquet. Не открывайте их, если не уверены в надёжности! 🚫
3️⃣ Настройте мониторинг любых аномалий при обработке файлов. 🕵️♂️
4️⃣ Проанализируйте логи на предмет попыток эксплуатации уязвимости. 📊
5️⃣ Используйте механизмы изоляции (песочницы, контейнеризация) для обработки неизвестных данных. 🔒
Stay secure and read SecureTechTalks 📚
#Кибербезопасность #BigData #ApacheParquet #DataSecurity #ИнформационнаяБезопасность #SecurityNews #Облака #ITНовости #Уязвимости #ЗащитаДанных
😱1
🛡 Protegrity Developer Edition: защита данных в эпоху GenAI
🔍 Protegrity Developer Edition - это лёгкая платформа для экспериментов с защитой данных и ИИ. Она позволяет разработчикам:
✨ находить PII и чувствительные сущности
✨ маскировать / редактировать данные
✨ защищать и «раззащищать» через токенизацию
✨ ставить семантические guardrails для LLM
📦 Всё это запускается локально через Docker, а примеры и SDK позволяют быстро встроить защиту в Python или REST-приложения.
⚙ Архитектура и ключевые модули
🔎 Data Discovery - распознаёт в тексте персональные данные и другие чувствительные объекты, даёт confidence score.
🛑 Semantic Guardrail: отсекает утечки PII, ловит подозрительные промпты и предотвращает «галлюцинации» модели.
🧪 Sample Apps - готовые скрипты:
🔍 поиск сущностей
🖊 редактирование / маскирование
🔒 защита (protect)
🔓 обратное восстановление (unprotect)
⚡ API Service - единая точка для вызова операций через REST и SDK.
📈 Где использовать - реальные кейсы
🤖 AI-чат-боты и ассистенты - защита ввода и вывода, чтобы модель не утекла PII.
📊 Анонимизация тренировочных данных - очищаем датасеты для обучения LLM.
🛡 Мониторинг вывода моделей - если ответ содержит чувствительные данные, guardrail его блокирует.
🚀 R&D и прототипирование - стартапы и исследователи могут тестировать интеграции без лицензий и сложных деплойментов.
✅ Плюсы и ⚠ ограничения
✅ Быстрый старт, простая архитектура
✅ Семантическая защита, а не только паттерны
✅ Подходит для экспериментов с GenAI
⚠ Не для продакшн-нагрузки
⚠ Ограниченные ресурсы контейнеров
⚠ Требует настройки порогов и политик
🌐 Позиционирование
🌍 Protegrity выпустила Dev Edition на GitHub, чтобы любой разработчик мог «поиграть» с защитой данных.
📰 Компания прямо заявляет: цель - дать сообществу инструменты для экспериментов и инноваций в области приватности GenAI.
🔗 Полезные ссылки
📂 GitHub: https://github.com/Protegrity-Developer-Edition/protegrity-developer-edition
📖 Документация: https://developer.docs.protegrity.com/docs/about_dev/
📝 Блог-анонс: https://www.protegrity.com/blog/secure-your-ai-pipeline-introducing-protegrity-developer-edition
📰 Пресс-релиз: https://wallarm.com/news/correcting-and-replacing-protegrity-releases-free-developer-edition-on-github-for-genai-privacy-innovation
Stay secure and read SecureTechTalks 📚
#кибербезопасность #PII #GenAI #datasecurity #LLM #privacy #обезличивание #infosec #DevEdition #SecureTechtalks
🔍 Protegrity Developer Edition - это лёгкая платформа для экспериментов с защитой данных и ИИ. Она позволяет разработчикам:
✨ находить PII и чувствительные сущности
✨ маскировать / редактировать данные
✨ защищать и «раззащищать» через токенизацию
✨ ставить семантические guardrails для LLM
📦 Всё это запускается локально через Docker, а примеры и SDK позволяют быстро встроить защиту в Python или REST-приложения.
⚙ Архитектура и ключевые модули
🔎 Data Discovery - распознаёт в тексте персональные данные и другие чувствительные объекты, даёт confidence score.
🛑 Semantic Guardrail: отсекает утечки PII, ловит подозрительные промпты и предотвращает «галлюцинации» модели.
🧪 Sample Apps - готовые скрипты:
🔍 поиск сущностей
🖊 редактирование / маскирование
🔒 защита (protect)
🔓 обратное восстановление (unprotect)
⚡ API Service - единая точка для вызова операций через REST и SDK.
📈 Где использовать - реальные кейсы
🤖 AI-чат-боты и ассистенты - защита ввода и вывода, чтобы модель не утекла PII.
📊 Анонимизация тренировочных данных - очищаем датасеты для обучения LLM.
🛡 Мониторинг вывода моделей - если ответ содержит чувствительные данные, guardrail его блокирует.
🚀 R&D и прототипирование - стартапы и исследователи могут тестировать интеграции без лицензий и сложных деплойментов.
✅ Плюсы и ⚠ ограничения
✅ Быстрый старт, простая архитектура
✅ Семантическая защита, а не только паттерны
✅ Подходит для экспериментов с GenAI
⚠ Не для продакшн-нагрузки
⚠ Ограниченные ресурсы контейнеров
⚠ Требует настройки порогов и политик
🌐 Позиционирование
🌍 Protegrity выпустила Dev Edition на GitHub, чтобы любой разработчик мог «поиграть» с защитой данных.
📰 Компания прямо заявляет: цель - дать сообществу инструменты для экспериментов и инноваций в области приватности GenAI.
🔗 Полезные ссылки
📂 GitHub: https://github.com/Protegrity-Developer-Edition/protegrity-developer-edition
📖 Документация: https://developer.docs.protegrity.com/docs/about_dev/
📝 Блог-анонс: https://www.protegrity.com/blog/secure-your-ai-pipeline-introducing-protegrity-developer-edition
📰 Пресс-релиз: https://wallarm.com/news/correcting-and-replacing-protegrity-releases-free-developer-edition-on-github-for-genai-privacy-innovation
Stay secure and read SecureTechTalks 📚
#кибербезопасность #PII #GenAI #datasecurity #LLM #privacy #обезличивание #infosec #DevEdition #SecureTechtalks
🧠 Почему мультиагентные системы деградируют
В детстве была игра, когда шёпотом передаёшь фразу по цепочке и в конце она превращается во что-то странное. Похоже, мы встроили эту механику прямо в архитектуру современных AI-систем.
⚙ Текущая реальность
Сегодня мультиагентные LLM выглядят как очевидный шаг вперёд. Один агент генерирует, второй проверяет, третий агрегирует, четвёртый управляет процессом, а пятый все этой протоколирует.
По логике, если одна модель умная, то система из нескольких должна быть еще умнее. Но, к сожалению, это не так.
🚨 Больше коммуникации ≠ лучше результат
Система может генерировать больше токенов, обсуждать дольше, «думать коллективно», но терять ключевые факты по дороге. Причина не в интеллекте моделей, а в накоплении шума, искажений и
коррелированных ошибок.
🌲 Топология
Когда все агенты общаются напрямую (⭐), точность максимальна. Но как только появляется иерархия (🌲):
➖ промежуточные агенты начинают сжимать контекст
➖ часть информации не проходит вверх
➖ сигнал становится необратимо искажённым
На практике, до 25% критичных данных теряется при переходе к древовидной схеме. «Менеджер» в AI-системе это не усилитель, а фильтр с потерями.
🦠 Эксплойты никто не отменял
Давай всомним о безопасности 😁 и добавим одного «заражённого» агента (prompt injection / malicious logic):
➖ в ⭐ звезде атака распространяется быстро → система «заражается» целиком
➖ в 🌲 дереве часть вреда гасится → но вместе с ним теряется и полезный сигнал
Получаем этакий парадокс:
👉 чем лучше связность системы, тем она уязвимее
👉 чем больше потерь, тем выше устойчивость
🧩 В сухом остатке:
Мультиагентные LLM не становятся «командой экспертов». Это все также распределённая система передачи сигналов, где:
➖ информация умирает по дороге
➖ ошибки усиливают друг друга
➖ архитектура напрямую влияет на безопасность
Stay secure and read SecureTechTalks 📚
#кибербезопасность #LLM #AI #MultiAgent #PromptInjection #DataSecurity #AIархитектура #Infosec #SecureAI #GenAI
В детстве была игра, когда шёпотом передаёшь фразу по цепочке и в конце она превращается во что-то странное. Похоже, мы встроили эту механику прямо в архитектуру современных AI-систем.
⚙ Текущая реальность
Сегодня мультиагентные LLM выглядят как очевидный шаг вперёд. Один агент генерирует, второй проверяет, третий агрегирует, четвёртый управляет процессом, а пятый все этой протоколирует.
По логике, если одна модель умная, то система из нескольких должна быть еще умнее. Но, к сожалению, это не так.
🚨 Больше коммуникации ≠ лучше результат
Система может генерировать больше токенов, обсуждать дольше, «думать коллективно», но терять ключевые факты по дороге. Причина не в интеллекте моделей, а в накоплении шума, искажений и
коррелированных ошибок.
🌲 Топология
Когда все агенты общаются напрямую (⭐), точность максимальна. Но как только появляется иерархия (🌲):
На практике, до 25% критичных данных теряется при переходе к древовидной схеме. «Менеджер» в AI-системе это не усилитель, а фильтр с потерями.
🦠 Эксплойты никто не отменял
Давай всомним о безопасности 😁 и добавим одного «заражённого» агента (prompt injection / malicious logic):
Получаем этакий парадокс:
👉 чем лучше связность системы, тем она уязвимее
👉 чем больше потерь, тем выше устойчивость
🧩 В сухом остатке:
Мультиагентные LLM не становятся «командой экспертов». Это все также распределённая система передачи сигналов, где:
Stay secure and read SecureTechTalks 📚
#кибербезопасность #LLM #AI #MultiAgent #PromptInjection #DataSecurity #AIархитектура #Infosec #SecureAI #GenAI
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
🔐 Люди сами сливают свои данные в AI, а OpenAI пытается это исправить
Сегодня речь пойдет о проблеме, о которой все знают, но почти никто не решает.
Пользователи массово вставляют персональные данные в диалоги с LLM ( включая креды и номера карт).
На днях OpenAI выпустила инструмент, который работает до того, как данные “утекут” в модель.
🧠 Что за штука?
Речь про Privacy Filter, отдельную модель для поиска и удаления PII (персональных данных) из текста.
В отличие от классических DLP/regex-фильтров, модель не просто ищет шаблоны вроде “@gmail.com” или “+7…”, а анализирует контекст, понимает, где данные публичные, а где приватные, принимает решение прямо в тексте.
Инструмент работает в один проход и поддерживает длинные документы до 128k токенов.
🔍 По каким атрибутам работает поиск?
Модель покрывает основные категории чувствительных данных: имена, адреса, email, телефоны, URL, даты, финансовые реквизиты и секреты вроде паролей или API-ключей.
💡 Локальный запуск
Модель можно запускать локально, т.е. данные не нужно отправлять в облако. Фильтрация происходит прямо на стороне пользователя, что существенно снижает риск утечек.
Постепенно двигаемся сторону privacy-by-design.
⚠️ Пока не идеально
OpenAI заявляет, что модель не идеальна, а риски лежат на пользователях 😁. Фильтр может ошибаться, иногда пропускать редкие или нестандартные персональные данные, а иногда наоборот, скрывать лишнее. В общем все стандартно для решений обезличивания.
📎 Официальный релиз:
https://openai.com/index/introducing-openai-privacy-filter/
🔗 Ссылка на GitHub: https://github.com/openai/privacy-filter
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #Privacy #PII #OpenAI #LLM #DataSecurity #Infosec #SecureTechTalks
Сегодня речь пойдет о проблеме, о которой все знают, но почти никто не решает.
Пользователи массово вставляют персональные данные в диалоги с LLM ( включая креды и номера карт).
На днях OpenAI выпустила инструмент, который работает до того, как данные “утекут” в модель.
🧠 Что за штука?
Речь про Privacy Filter, отдельную модель для поиска и удаления PII (персональных данных) из текста.
В отличие от классических DLP/regex-фильтров, модель не просто ищет шаблоны вроде “@gmail.com” или “+7…”, а анализирует контекст, понимает, где данные публичные, а где приватные, принимает решение прямо в тексте.
Инструмент работает в один проход и поддерживает длинные документы до 128k токенов.
🔍 По каким атрибутам работает поиск?
Модель покрывает основные категории чувствительных данных: имена, адреса, email, телефоны, URL, даты, финансовые реквизиты и секреты вроде паролей или API-ключей.
💡 Локальный запуск
Модель можно запускать локально, т.е. данные не нужно отправлять в облако. Фильтрация происходит прямо на стороне пользователя, что существенно снижает риск утечек.
⚠️ Пока не идеально
OpenAI заявляет, что модель не идеальна, а риски лежат на пользователях 😁. Фильтр может ошибаться, иногда пропускать редкие или нестандартные персональные данные, а иногда наоборот, скрывать лишнее. В общем все стандартно для решений обезличивания.
📎 Официальный релиз:
https://openai.com/index/introducing-openai-privacy-filter/
🔗 Ссылка на GitHub: https://github.com/openai/privacy-filter
Stay secure and read SecureTechTalks 📚
#CyberSecurity #AI #Privacy #PII #OpenAI #LLM #DataSecurity #Infosec #SecureTechTalks
👍1
🧬 VectorSmuggle: данные научились прятать внутри embedding’ов
Большинство AI-систем относятся к embedding как к безопасному промежуточному формату, т.к. Вектор не выглядит как текст и не содержит очевидного payload.
Поэтому embedding’и спокойно:
🔹 передаются между сервисами
🔹 индексируются в vector DB
🔹 попадают в shared storage
🔹 используются в retrieval pipeline
Практически никто не анализирует их содержимое с точки зрения безопасности. А зря.
⚙️ Что такое VectorSmuggle
Исследователи показали, что внутри embedding можно скрытно кодировать произвольные данные, сохраняя при этом его внешнюю «нормальность».
Технически идея строится вокруг особенностей embedding space.
LLM и embedding-модели преобразуют текст в высокоразмерные векторы. При этом небольшие изменения отдельных компонент обычно не ломают semantic similarity.
Именно этот запас устойчивости злоумышленники используют, как covert channel.
Часть измерений embedding’а начинает хранить скрытый payload, который можно позже извлечь специальным декодером.
Со стороны embedding продолжает выглядеть легитимно:
🔹 проходит similarity search
🔹 нормально индексируется
🔹 не вызывает ошибок в vector pipeline
Но внутри уже находится скрытая информация.
🧪 Реализация
Схема выглядит довольно элегантно, сначала данные кодируются внутрь embedding-вектора через модификацию отдельных dimensions. После этого embedding отправляется в обычную vector infrastructure: FAISS, Pinecone, Milvus или другую vector DB.
Позже получатель извлекает embedding и декодирует скрытый payload обратно в исходные данные. Ключевая проблема в том, что embedding-инфраструктура почти не имеет механизмов проверки:
🔹 что именно хранится внутри вектора
🔹 насколько embedding отклоняется от нормального распределения
🔹 используется ли vector space как covert storage
Для системы это просто массив float-значений.
🧨 Опасность⚠️
На практике VectorSmuggle открывает довольно неприятные сценарии.
Например:
🔹 скрытая передача данных через RAG-pipeline
🔹 covert communication между агентами
🔹 хранение payload внутри vector DB
🔹 обход DLP/контент-фильтрации
🔹 скрытая эксфильтрация информации через embedding API
Особенно интересно выглядит последний пункт. Многие security-системы анализируют текст, файлы или сетевой трафик, но практически не смотрят на embedding-space как на потенциальный канал утечки данных, хотя именно туда AI-инфраструктура сейчас начинает переносить всё больше информации.
🔗 Исследование: https://arxiv.org/abs/2505.12540
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Embedding #VectorDB #RAG #DataSecurity #AppSec #AIrisks #SecureTechTalks
Большинство AI-систем относятся к embedding как к безопасному промежуточному формату, т.к. Вектор не выглядит как текст и не содержит очевидного payload.
Поэтому embedding’и спокойно:
🔹 передаются между сервисами
🔹 индексируются в vector DB
🔹 попадают в shared storage
🔹 используются в retrieval pipeline
Практически никто не анализирует их содержимое с точки зрения безопасности. А зря.
⚙️ Что такое VectorSmuggle
Исследователи показали, что внутри embedding можно скрытно кодировать произвольные данные, сохраняя при этом его внешнюю «нормальность».
Технически идея строится вокруг особенностей embedding space.
LLM и embedding-модели преобразуют текст в высокоразмерные векторы. При этом небольшие изменения отдельных компонент обычно не ломают semantic similarity.
Именно этот запас устойчивости злоумышленники используют, как covert channel.
Часть измерений embedding’а начинает хранить скрытый payload, который можно позже извлечь специальным декодером.
Со стороны embedding продолжает выглядеть легитимно:
🔹 проходит similarity search
🔹 нормально индексируется
🔹 не вызывает ошибок в vector pipeline
Но внутри уже находится скрытая информация.
🧪 Реализация
Схема выглядит довольно элегантно, сначала данные кодируются внутрь embedding-вектора через модификацию отдельных dimensions. После этого embedding отправляется в обычную vector infrastructure: FAISS, Pinecone, Milvus или другую vector DB.
Позже получатель извлекает embedding и декодирует скрытый payload обратно в исходные данные. Ключевая проблема в том, что embedding-инфраструктура почти не имеет механизмов проверки:
🔹 что именно хранится внутри вектора
🔹 насколько embedding отклоняется от нормального распределения
🔹 используется ли vector space как covert storage
Для системы это просто массив float-значений.
🧨 Опасность
На практике VectorSmuggle открывает довольно неприятные сценарии.
Например:
🔹 скрытая передача данных через RAG-pipeline
🔹 covert communication между агентами
🔹 хранение payload внутри vector DB
🔹 обход DLP/контент-фильтрации
🔹 скрытая эксфильтрация информации через embedding API
Особенно интересно выглядит последний пункт. Многие security-системы анализируют текст, файлы или сетевой трафик, но практически не смотрят на embedding-space как на потенциальный канал утечки данных, хотя именно туда AI-инфраструктура сейчас начинает переносить всё больше информации.
🔗 Исследование: https://arxiv.org/abs/2505.12540
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #Embedding #VectorDB #RAG #DataSecurity #AppSec #AIrisks #SecureTechTalks
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2👍1
🧠 AI-агенты знают слишком много...
На arXiv вышел обзор: Agents That Know Too Much: A Data-Centric Survey of Privacy in LLM Agents.
Авторы вводят новую модель Data Surfaces, где вместо привычного подхода «разберём типы атак» исследователи предлагают смотреть на поверхности данных:
🔹 базы данных и хранилища
🔹 файлы и таблицы
🔹 RAG-индексы
🔹 внешние API и инструменты
🔹 долговременная память агента
🔹 каналы общения между агентами
Такой подход значительно изменяет модель угроз. Например, чувствительные данные могут утечь не через финальный ответ, а через SQL-запрос, который агент сам сгенерировал или через промежуточные результаты reasoning. А это не так-то просто контролировать.
🧨 Память, как самый опасный слой
Отдельно авторы выделяют memory-layer, потому что память агента:
1. переживает сессии
2. хранит прошлый контекст
3. может быть отравлена
4. может случайно утечь другому пользователю
Таким образом это делает prompt injection постоянным. Один вредоносный документ может записать payload в memory store, а агент достанет его через неделю уже как доверенный контекст.
Это уже не prompt injection.
🛡️ Чего еще интересного в статье?
Авторы считают, что обычного контроля доступа больше недостаточно. Нужен information-flow control. Система, которая отслеживает не просто доступ, а движение данных между всеми слоями агента. Кто что прочитал, что куда передал, что сохранил, что переиспользовал.
Privacy для AI-агентов начинает превращаться в data lineage security.
🔗 Исследование: https://arxiv.org/abs/2606.26627
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #Privacy #RAG #MemorySecurity #DataSecurity #AIsecurity #SecureTechTalks
На arXiv вышел обзор: Agents That Know Too Much: A Data-Centric Survey of Privacy in LLM Agents.
Авторы вводят новую модель Data Surfaces, где вместо привычного подхода «разберём типы атак» исследователи предлагают смотреть на поверхности данных:
🔹 базы данных и хранилища
🔹 файлы и таблицы
🔹 RAG-индексы
🔹 внешние API и инструменты
🔹 долговременная память агента
🔹 каналы общения между агентами
Такой подход значительно изменяет модель угроз. Например, чувствительные данные могут утечь не через финальный ответ, а через SQL-запрос, который агент сам сгенерировал или через промежуточные результаты reasoning. А это не так-то просто контролировать.
🧨 Память, как самый опасный слой
Отдельно авторы выделяют memory-layer, потому что память агента:
1. переживает сессии
2. хранит прошлый контекст
3. может быть отравлена
4. может случайно утечь другому пользователю
Таким образом это делает prompt injection постоянным. Один вредоносный документ может записать payload в memory store, а агент достанет его через неделю уже как доверенный контекст.
Это уже не prompt injection.
🛡️ Чего еще интересного в статье?
Авторы считают, что обычного контроля доступа больше недостаточно. Нужен information-flow control. Система, которая отслеживает не просто доступ, а движение данных между всеми слоями агента. Кто что прочитал, что куда передал, что сохранил, что переиспользовал.
Privacy для AI-агентов начинает превращаться в data lineage security.
🔗 Исследование: https://arxiv.org/abs/2606.26627
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #LLM #AgenticAI #Privacy #RAG #MemorySecurity #DataSecurity #AIsecurity #SecureTechTalks
👍2
🧨 Google учит AI работать с зашифрованными данными
Fully Homomorphic Encryption (FHE) сохраняет данные зашифрованными даже во время вычислений.
Мы уже рассказывали про проблемы гомоморфного шифрования и федеративного обучения. Однако Google не стоит на месте и продолжает развивать технологию в виде открытого проекта HEIR, который должен упростить создание приложений.
⚙️ Суть проекта
Разработчик описывает обычную программу. HEIR автоматически преобразует её так, чтобы вычисления выполнялись непосредственно над зашифрованными данными.
Получается цепочка:
данные → шифрование → AI или другая обработка → зашифрованный результат → расшифровка
Сервер работает с зашифрованной информацией и не получает исходные данные.
🧠 Зачем здесь AI
Такой подход особенно интересен для систем, где данные слишком чувствительны для передачи внешнему AI сервису.
Например:
🔹 банк отправляет транзакцию на анализ мошенничества, не раскрывая её содержимое;
🔹 SOC анализирует сетевые события, сохраняя данные клиентов зашифрованными;
🔹 медицинская система использует AI для анализа данных пациента без передачи модели открытой медицинской информации.
HEIR поддерживает несколько современных методов гомоморфного шифрования и умеет автоматически оптимизировать вычисления.
🔥 Главная проблема
Само шифрование уже существует. Главный барьер сейчас в том, что такие вычисления дорогие и сложные для разработчиков.
HEIR пытается спрятать большую часть криптографической сложности внутри компилятора. Разработчик описывает нужную логику, а система сама преобразует её в операции над зашифрованными данными.
Когда этот подход станет достаточно быстрым, появится интересная архитектура для корпоративного AI.
Модель получает данные, но инфраструктура вокруг неё не получает доступа к исходной информации.
🔗 GitHub: https://github.com/google/heir
🔗 Документация: https://heir.dev/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #FHE #Privacy #Cryptography #Google #OpenSource #AISecurity #DataSecurity #SecureTechTalks
Fully Homomorphic Encryption (FHE) сохраняет данные зашифрованными даже во время вычислений.
Мы уже рассказывали про проблемы гомоморфного шифрования и федеративного обучения. Однако Google не стоит на месте и продолжает развивать технологию в виде открытого проекта HEIR, который должен упростить создание приложений.
⚙️ Суть проекта
Разработчик описывает обычную программу. HEIR автоматически преобразует её так, чтобы вычисления выполнялись непосредственно над зашифрованными данными.
Получается цепочка:
данные → шифрование → AI или другая обработка → зашифрованный результат → расшифровка
Сервер работает с зашифрованной информацией и не получает исходные данные.
🧠 Зачем здесь AI
Такой подход особенно интересен для систем, где данные слишком чувствительны для передачи внешнему AI сервису.
Например:
🔹 банк отправляет транзакцию на анализ мошенничества, не раскрывая её содержимое;
🔹 SOC анализирует сетевые события, сохраняя данные клиентов зашифрованными;
🔹 медицинская система использует AI для анализа данных пациента без передачи модели открытой медицинской информации.
HEIR поддерживает несколько современных методов гомоморфного шифрования и умеет автоматически оптимизировать вычисления.
🔥 Главная проблема
Само шифрование уже существует. Главный барьер сейчас в том, что такие вычисления дорогие и сложные для разработчиков.
HEIR пытается спрятать большую часть криптографической сложности внутри компилятора. Разработчик описывает нужную логику, а система сама преобразует её в операции над зашифрованными данными.
Когда этот подход станет достаточно быстрым, появится интересная архитектура для корпоративного AI.
Модель получает данные, но инфраструктура вокруг неё не получает доступа к исходной информации.
🔗 GitHub: https://github.com/google/heir
🔗 Документация: https://heir.dev/
Stay secure and read SecureTechTalks 📚
#кибербезопасность #AI #FHE #Privacy #Cryptography #Google #OpenSource #AISecurity #DataSecurity #SecureTechTalks
👍1