Więcej kodu w Twoim repozytorium jest pisane przez agenta niż rok temu, a udział ten będzie tylko rósł. Agenci dobrze radzą sobie z tym, by coś działało. Dobrze radzą sobie z usuwaniem blokad. Nie są jednak świadomi, jakie ramy zgodności musi spełniać Twoja firma, ponieważ te informacje znajdują się w dokumencie polityki, który nie jest nigdzie w pobliżu ich okna kontekstu.
Rezultatem jest nowe i rosnące źródło ryzyka zgodności: kod, który jest poprawny, zmergowany i cicho niezgodny z kontrolą, o której nikt nie poinformował agenta.
Wygodny wieloznacznik
Agent podłącza nową usługę wewnętrzną, a żądanie międzyoriginowe nie powiodło się. Najszybszym sposobem na odblokowanie wywołania jest zezwolenie na wszystkie pochodzenia. Agent to robi, żądanie się powiodło, zadanie zostaje oznaczone jako ukończone. To rozsądny ruch dla czegoś, czego zadaniem jest sprawić, by kod działał.
app.use(cors({- origin: ["https://app.example.com"],+ origin: true, // reflect any origin credentials: true,}))Odbijanie dowolnego pochodzenia z uwierzytelnieniem poszerza zakres podmiotów, które mogą dotrzeć do uwierzytelnionej powierzchni, co jest dokładnie tym, czego dotyczy CC6.1 (logiczny dostęp): dostęp ograniczony do tego, co jest autoryzowane. Kod jest poprawny, a żądanie działa. Kontrola jest słabsza niż przed interwencją agenta.
Dlaczego to nowa granica
Niezgodność spowodowana przez człowieka zdarza się jeden nieostrożny PR po drugim. Niezgodność spowodowana przez agenta zachodzi z prędkością i na skalę, z jaką działają agenci, i bez żadnej ukrytej oceny, jaką wnosi doświadczony inżynier ('Czy naprawdę powinienem otworzyć to dla wszystkich?'). Agent optymalizuje zadanie przed sobą, a 'spełnienie SOC 2 CC6.1' nie jest zadaniem przed nim.
W miarę wzrostu udziału kodu pisane przez agenta rośnie także odsetek zmian, które żaden człowiek nie sprawdził dokładnie pod kątem zgodności. To jest ta niezgodność, i narasta.
Pull request to jedyny punkt kontrolny
Nie można umieścić pliku PDF z polityką w kontekście każdego agenta i oczekiwać, że będzie on przestrzegać zasad. Ale praca agenta nadal przybywa w postaci pull request, a pull request to jedyne miejsce w obiegu pracy, w którym zmiana może zostać sprawdzona przed wdrożeniem, niezależnie od tego, czy została napisana przez człowieka, czy agenta.
heygrc został zaprojektowany, aby sprawdzać każdy PR względem Twoich ram i wskazywać kontrolę, której dotyczy zmiana, niezależnie od tego, czy została napisana przez agenta, czy nie, dzięki czemu wygodny wieloznacznik zostanie zidentyfikowany jako problem CC6.1 bezpośrednio w diffie.