Architektura się zmieniła. Model odpowiedzialności nie.

Bezpieczeństwo chmury było kiedyś traktowane jako kolejne zadanie dla istniejącego zespołu. Potem architektura zmieniła się na tyle, że stary model odpowiedzialności przestał się skalować, a rola stała się odrębną funkcją. AI jest teraz w tym samym punkcie.

Agent może analizować dane, wybierać narzędzie, dziedziczyć uprawnienia i podejmować działania w innym systemie. Tożsamość agenta, ścieżki promptów, konfiguracja RAG i MCP, piaskownice oraz izolacja w czasie wykonywania pojawiają się teraz w opisach stanowisk w firmach, które wcześniej włączały to do AppSec. Luka organizacyjna, którą te role wypełniają, to odpowiedzialność za cały łańcuch. Luka w przeglądzie kodu jest węższa: uprawnienia, logi i ścieżki nadzoru ludzkiego, które sprawiają, że łańcuch staje się realny, są decydowane w pull requestach.

Łańcuch jest organizacyjny. Diff wciąż jest kontrolą.

Narzędzia runtime monitorują agenta. heygrc czyta zmianę, która nadała mu uprawnienia. Lintery i SAST nie są zbudowane po to, by wiedzieć, które frameworki stosujesz. Test na prompt injection nie widzi, że ostatni PR usunął ścieżkę interwencji lub poszerzył rolę wywoływania narzędzi. heygrc został zaprojektowany, aby czytać każdy pull request w odniesieniu do wybranych przez Ciebie frameworków i cytować kontrolę, której dotyczy zmiana: tożsamość i dostęp agenta, rejestrowanie operacji systemu oraz sposób interwencji człowieka.

Art. 12 i art. 14 to obowiązki reżimu wysokiego ryzyka. heygrc nie klasyfikuje poziomu ryzyka Twojego systemu i nie przeprowadza oceny zgodności. Czy te artykuły mają zastosowanie, to Twoja własna ocena. Nie izoluje agenta, nie testuje prompt injection ani nie powstrzymuje niekontrolowanego wywołania narzędzia w czasie wykonywania. Przegląda zmianę kodu w odniesieniu do wybranych frameworków i cytuje kontrolę. Ty decydujesz, co blokować, a co wdrażać.

• Kontrole zgodności dla kodu generowanego przez AI