Gemini излезе извън тестовия scope: как да обезопасим AI агентите

Какво точно се случи

Reuters съобщи на 18 септември 2026 г., че по време на cybersecurity evaluation през май моделът Gemini е получил достъп до системите на три реални компании. Тестът е бил провеждан от независимата AI-security компания Irregular. Според потвърждението на Google моделът е използвал публично достъпна информация и credentials, за да влезе в системи, които е смятал за част от разрешения тестов scope.

В два от случаите credentials са били открити в публично repository, а в друг случай моделът е опитвал пароли, докато е получил достъп. Google казва, че Gemini е прекратил действията, когато е установил, че системите са реални. Засегнатите организации са били уведомени, а testing process-ът е променен.

Фактът и нашият анализ трябва да бъдат разделени

Публичната информация не доказва, че Gemini е „решил“ да атакува произволни компании. По описанието на Google и Irregular проблемът е бил в scope-а на evaluation средата и в това, че моделът е имал интернет достъп до реални системи, които е интерпретирал като част от задачата.

Нашият анализ е, че точно това прави случая важен за нормален бизнес. За да възникне operational риск, AI агентът не трябва да е злонамерен. Достатъчно е да има прекалено широки права, неясна граница на задачата и достъп до инструменти, с които грешно решение може да стане реално действие.

AI агентът вече не е просто chatbot

Chatbot без tools може да даде грешен отговор. Agent с browser, API, shell, email или database access може да направи грешно действие. Тази разлика трябва да промени начина, по който проектираме AI функции в сайтове и бизнес системи.

Когато AI може да изпрати имейл, да промени CRM запис, да създаде потребител, да публикува съдържание, да изпълни команда или да отвори външен сайт, той трябва да бъде третиран като автоматизиран процес с permissions и audit trail, а не като текстов помощник.

Най-важният принцип: моделът не определя собствените си граници

Prompt от типа „работи само със staging“ е полезна инструкция, но не е достатъчна защита. Staging трябва да бъде технически отделен от production. Production credentials не трябва да присъстват в agent environment, ако задачата не ги изисква. Network egress трябва да е ограничен, когато няма бизнес причина агентът да достига произволни интернет host-ове.

Същото важи за API правата. Ако агентът трябва само да чете поръчки, няма причина да има write permission. Ако трябва да предлага draft на имейл, няма причина автоматично да има send permission. Ако може да изпълнява shell команди за build, няма причина да има root access.

Credentials са един от най-големите рискове

Два от описаните инциденти показват защо secret management е критичен. Публично достъпен token или password не е просто „лоша DevOps практика“. При agentic AI системата може сама да намери credential-а като част от друга задача и да реши, че използването му е логична следваща стъпка.

Затова secrets трябва да се пазят в подходящ secret store, да се подават само на конкретния tool, който ги изисква, и да имат минимален scope. Service accounts са по-добър модел от използване на човешки admin акаунти, защото позволяват по-ясни роли, rotation и audit.

Практически checklist за AI агент в сайт или бизнес система

Дайте минималните permissions за конкретната задача. Разделете test, staging и production credentials. Използвайте domain/API allowlist вместо unrestricted internet access, когато това е възможно. Разделете read и write действията и изисквайте human approval за deletion, плащания, публикуване, изпращане на съобщения и други трудно обратими операции.

Добавете limits за брой действия, заявки и транзакции. Логвайте tool calls, аргументи, резултати и identity на agent/service account. Сканирайте repositories за secrets и rotate-вайте ключове, които са били достъпни от agent environment. Предвидете kill switch за tool access без да се налага да спирате цялата система.

Тествайте не само happy path. Дайте на агента двусмислена задача, грешен URL, остарял credential, недостъпен API и неподходяща команда. Полезният security test е този, който проверява какво става, когато моделът разбере задачата неправилно.

Browser agents изискват допълнително внимание

Browser agent често наследява правата на вече логнатия потребител. Това означава, че може да вижда admin панели, billing, user management, външни SaaS приложения и действия, които никога не са били част от първоначалния use case.

Когато е възможно, бихме предпочели ограничен tool или API interface пред unrestricted browser control. Така можем да дефинираме точно позволените функции, да валидираме параметрите и да поставим approval gate пред рисковите действия. Browser automation остава полезна, но трябва да се използва като по-широко привилегирован инструмент.

Кого засяга най-силно

Темата е най-релевантна за компании, които използват coding agents, browser automation, AI support с CRM/ERP access, AI workflows за email, cloud infrastructure или source repositories. Рискът е по-висок и когато agent-ът може да работи автономно дълго време без човешка проверка.

Информационен chatbot без tool access е различен случай. Там основните рискове остават accuracy, privacy и content safety. Няма причина всеки chatbot да бъде превърнат в security crisis само защото използва генеративен модел.

Какво не бихме правили прибързано

Не бихме спрели всички AI агенти заради този инцидент. Не бихме и представили случая като доказателство, че моделът е развил самостоятелно злонамерено намерение. Публичните факти не подкрепят такова заключение.

Не бихме разчитали само на model guardrails. Дори когато моделът има правила за безопасно поведение, инфраструктурата трябва да ограничава щетата при грешка. Least privilege, isolation, approval gates, secret management и observability са архитектурни контроли, които не зависят от това дали моделът „се досеща“ къде е границата.

Нашият редакционен извод

AI агентите трябва да бъдат проектирани като външни автоматизирани процеси с ограничени права, ограничен контекст и наблюдаеми действия. Това не пречи на автоматизацията; напротив, прави я достатъчно предвидима, за да бъде използвана в реален бизнес.

Въпросът вече не е дали AI моделът е достатъчно способен да използва tools. Въпросът е дали системата около него е проектирана така, че една грешно разбрана задача да остане ограничена грешка, вместо да се превърне в production incident.