ИИ агентите за писане на код променят колко бързо разработчиците могат да създават и внедряват софтуер, както и колко бързо идентификационните данни могат да бъдат компрометирани. Според доклада на GitGuardian „State of Secrets Sprawl 2026“, при сумитирането на промени (commits), идентифицирани като подпомогнати от ИИ, изтичат тайни с приблизително двойно по-висок процент спрямо тези, написани от хора. Повечето от най-бързо растящите категории изтекли идентификационни данни вече са свързани с ИИ услуги, което означава, че инструментите, предназначени да ускорят разработката, също така ускоряват и разкриването на ключовете, на които разчита самата разработка.

Това не е нова уязвимост; новото е, че ИИ променя мащаба и темпото, с които тези грешки могат да възникнат. Един агент за писане на код може да прочете целия проект, да модифицира файлове, да генерира конфигурации и да взаимодейства с външни услуги за времето, за което един разработчик би прегледал една заявка за изтегляне (pull request). Основният проблем не е, че ИИ агентите понякога попадат на тайни, а че много от тези тайни никога не са били проектирани за среда, в която софтуерът може да действа самостоятелно. ИИ агентите за писане на код допринасят за разрастването на тайните чрез твърдо кодиране (hardcoding) на идентификационни данни в повече файлове и разпространение на съществуващите в повече системи, отколкото екипите по сигурност могат да проследят и да ротират.

Как се промени разрастването на тайните в ерата на автономния ИИ

Разрастването на тайните (secrets sprawl) се случва, когато идентификационни данни като API ключове, токени и данни за служебни профили (service accounts) се натрупват в повече системи, отколкото дадена организация може надеждно да инвентаризира и да ротира — твърдо кодирани в изходни файлове, поставени в конфигурации и копирани в тикети. Екипите по сигурност исторически са се опитвали да контролират това разрастване чрез откриване на разкрити тайни със задна дата; скенерите наблюдават хранилищата, pre-commit куките прихващат каквото могат, а екипите по сигурност ротират идентификационните данни, след като бъде открито разкриване. Тези контроли все още имат значение, но ИИ агентите показват ограниченията на разчитането единствено на откриването. Агентите могат да четат локални файлове, да изпълняват команди, да извикват API, да взаимодействат със сървъри по протокола Model Context Protocol (MCP) и да променят конфигурацията. Всяка допълнителна възможност създава още едно място, където може да се изискват идентификационни данни, и още един път, през който тези данни могат да се разпространят.

Ето защо организациите трябва да третират разрастването на тайните в ерата на автономния ИИ като проблем на нечовешката самоличност (Non-Human Identity - NHI), а не като такъв на поведението на модела. Всяко полезно действие, което един агент предприема в друга система, има самоличност зад гърба си. Когато агентите заявяват база данни, извикват API и внедряват в среда за тестване (staging), някакви идентификационни данни упълномощават това действие. Организациите не могат надеждно да предвидят всяко действие, което една автономна система ще предприеме, но могат да контролират до какво е позволено да има достъп самоличността зад тази система.

Как ИИ агентите за писане на код могат да разкрият тайни

Това, което прави агентите за писане на код полезни, е и това, което създава нови рискове за идентификационните данни: агентите се нуждаят от контекст. Агент, който не може да прочете целия проект, не предоставя голяма помощ, особено такъв, който трябва да бъде повторно упълномощаван за всяка операция. По-долу са посочени няколко начина, по които това се случва на практика, показващи защо организациите трябва да бъдат по-внимателни, когато предоставят на ИИ агентите за писане на код достъп до идентификационни данни и тайни.

Агентите могат да достъпват чувствителни файлове в контекста на проекта

Разработчиците често съхраняват идентификационни данни в .env файлове и локални конфигурации, останали от предишна сесия за отстраняване на грешки и никога непредназначени за контрол на версиите. ИИ агент за писане на код с широк достъп до проект може да бъде в състояние да прочете тези файлове заедно с кода на приложението, който му е възложено да анализира. За един ИИ агент конфигурационният файл, съдържащ производствен (production) API ключ, все още е част от работната среда, така че освен ако достъпът не е изрично ограничен, идентификационните данни могат да станат достъпни за агента, дори и да са ирелевантни за задачата. Това променя предположенията за сигурност около работните станции на разработчиците: Локалните идентификационни данни в некриптиран текст вече не са достъпни само за разработчика и приложенията, които изрично ги цитират, но вече са потенциално достъпни и за софтуерни агенти, опериращи в същата среда.

Конфигурациите на агенти и MCP могат да съдържат твърдо кодирани идентификационни данни

Инструкциите за настройка на агенти и MCP сървъри рутинно опростяват начина, по който разработчиците свързват ИИ приложения с бази данни, API и други външни системи. Тъй като много интеграции изискват удостоверяване (автентификация), това опростяване често означава поставяне на идентификационните данни директно в конфигурационен файл. Тъй като този файл никога не влиза в контрола на версиите, лесно е да се предположи, че данните са безопасни. Въпреки това, идентификационните данни все още могат да съществуват в некриптиран текст на машината на разработчика, често на място, което агентът има разрешения да чете.

Тайните се дублират в повърхности, които екипите може да не сканират

Една тайна рядко живее на едно място; един и същ ключ се озовава в .env файл, променлива в CI/CD или дори в Jira тикет, докато инженерите отстраняват проблеми с неуспешно внедряване. ИИ агент за писане на код, свързан с тези системи, въвежда друга уязвимост: тъй като всяко копие на тайна прави автентификация, ротирането на това в хранилището оставя останалите да работят. Ето защо самото сканиране на хранилището не може да реши проблема с разрастването на тайните. Голям дял от инцидентите с тайни могат да произлязат изцяло извън хранилищата за код, с разкрития в инструменти за съвместна работа и управление на задачи (ticketing), поради което ротирането на копието, намерено в хранилището, има минимална полза, ако същите идентификационни данни са валидни drugде.

Идентификационните данни на агентите често са с прекомерни разрешения

Един агент се нуждае от достатъчно достъп, за да извършва работата си, което създава натиск за предоставяне на широки разрешения, за да се гарантира, че задачите му са полезни. Разрешенията, предоставени по време на прототипирането, за да се избегнат грешки, могат да станат част от производствения процес, така че първоначалните разрешения с временни намерения остават — никой не се връща към тях, след като работният процес вече работи. Рискът нараства допълнително в среди с множество агенти. Слой за оркестрация, държащ ключове за няколко агента, може да предизвика ефект на доминото от компрометирани самоличности, като атакуващите наследяват достъп до всичко, до което оркестраторът е бил упълномощен да достигне.

Пропуските в управлението вече могат да бъдат измерени. В проучването на Keeper Security за RSAC 2026, 46% от анкетираните казват, че инструментите, задвижвани от ИИ, имат достъп до критични системи и чувствителни данни, но 76% от анкетираните казват, че тези самоличности не се управляват последователно съгласно политиките за привилегирован достъп. Дори когато достъпът е предоставен, контролите, които обикновено придружават това ниво на достъп, често не съществуват.

Как да защитим тайните при разработка с помощта на ИИ

Пълната забрана на ИИ инструментите за писане на код не е реалистична за повечето организации, а и честно казано не е необходима. Вместо това организациите трябва да разглеждат ИИ агентите като още една самоличност, работеща в средите за разработка, и да предоставят достъп съответно. Ето няколко начина за защита на тайните при разработка, подпомогната от ИИ:

  • Премахване на статичните идентификационни данни от средата за разработка: Вместо да съхраняват пароли и ключове в .env файлове, MCP конфигурации или настройки на IDE, организациите трябва да извличат идентификационните данни от централизирана платформа за управление на тайни, когато те са необходими. Ако идентификационните данни в прав текст не са на работната станция, даден агент не може случайно да ги прочете от средата за разработка.
  • Замяна на дълготрайните ключове с краткотрайни, автоматично ротирани идентификационни данни: Статичен ключ, който изтича, остава рисков ресурс за толкова дълго време, колкото е валиден — което може да бъде месеци или години. Краткотрайните идентификационни данни, които изтичат за минути и се ротират по определен график, значително стесняват този прозорец и премахват необходимостта да се открива всяко копие преди атакуващият да го направи.
  • Предоставяне на собствен дефиниран профил (самоличност) за всеки агент: Споделените сервизни акаунти правят почти невъзможно да се установи кой агент какво действие е извършил, и гарантират, най-широкото право за достъп да бъде наследено от всеки агент. Организациите трябва да дават на всеки AI агент само правата, необходими за неговата задача, и да правят тези права временни, когато е възможно. Третирайки AI агента като външен изпълнител, организациите му позволяват да управлява конкретни ресурси и да предприема конкретни действия в рамките на определен период от време.
  • Разширяване на управлението на тайни отвъд хранилищата за код: CI/CD инфраструктурата, работните станции на разработчиците, MCP конфигурациите, системите за билети и инструментите за сътрудничество съдържат идентификационни данни, които сканирането на хранилища никога не вижда, а голяма част от инцидентите с тайни вече произлизат от тези повърхности за атака. Екипите по сигурността трябва да имат по-голяма видимост отвъд контрола на изходния код.
  • Изискване на човешка намеса (human in the loop) за чувствителни операции: Достъпът до идентификационни данни, внедряването в продукционна среда и промените в привилегиите не трябва да стават автономни, а вместо това трябва да включват изрично одобрение. Режимите за автоматично одобрение трябва да бъдат съзнателно решение за политика с дефиниран обхват, а не настройка по подразбиране, която разработчикът включва веднъж и никога повече не преглежда.
  • Инвентаризация на вече работещите агенти и MCP сървъри: Повечето организации имат повече работещи агенти, отколкото си мислят, инсталирани от отделни разработчици без подходящ преглед. Организациите трябва да знаят кои агенти и MCP сървъри оперират в техните среди, кой е техен собственик, кои самоличности използват и до какво имат достъп тези самоличности.
  • Логване и одит на цялата активност на агентите: Нечовешките самоличности (NHIs) се нуждаят от същата следа за достъп, както и човешките самоличности. Без запис за това кои идентификационни данни е използвал даден агент и до какво е стигнал, реакцията на инциденти не може да помогне за възстановяването на пробив и няма какво да докаже при одити за съответствие.

Разрастването на тайните е проблем на самоличността, а не на изкуствения интелект

Разработката на софтуер е един от основните корпоративни случаи на използване на AI и нито един екип по сигурността няма да промени това само с политики. AI агентите не създадоха разрастването на тайни; те разкриха колко много организации имат лоши стратегии за сигурност на машинните идентификационни данни. Реалистично погледнато, целта е да се гарантира, че тайните, на които се появяват пред AI агентите, не си струва да бъдат откраднати. Това означава елиминиране на ненужните статични идентификационни данни, премахване на постоянните привилегии, съкращаване на продължителността на живота на идентификационните данни, разделяне на самоличностите и поддържане на видимост за това как се използват машинните самоличности. Повече сканиране не решава този проблем, защото то открива идентификационните данни едва след като те вече са разпространени; това, което помага, е централизиран контрол с нулеви познания (zero-knowledge) върху начина, по който тайните се съхраняват, ограничават и изтичат. Keeper Secrets Manager позволява на организациите централизирано да защитават инфраструктурни тайни, да премахват твърдо кодирани идентификационни данни от работните процеси за разработка и да контролират използването на тайни като част от платформа с доверие нула (zero-trust) и нулеви познания (zero-knowledge). AI агентите ще продължат да работят по-бързо и по-ефективно, но идентификационните данни зад тях трябва да станат с по-кратък живот и с по-тясно дефиниран обхват, за да помогнат за управлението на техния достъп.

Забележка: Тази статия беше внимателно написана и предоставена за нашата аудитория от Ashley D’Andrea, старши специалист по SEO и маркетинг на съдържанието в Keeper Security.