AWS zmienia moment, w którym nowe środowisko chmurowe staje się odpowiedzialnością operacyjną. Nowe doświadczenie rejestracji ma pomóc twórcom przejść od pomysłu do działającego kodu bez wcześniejszego poznawania całego modelu kont AWS, IAM i organizacji. Nowy klient może użyć istniejącej tożsamości Google, GitHub, Apple lub Amazon, otrzymać wstępnie skonfigurowany projekt, zaprosić współpracowników e-mailem i połączyć agenta kodującego za pomocą instrukcji konfiguracji.

Laptop z ogólnym panelem chmurowym oraz elementami agenta kodującego, uprawnień i budżetu

To istotna zmiana w uruchamianiu chmury. Pierwszą decyzją w AWS nie musi już być wybór struktury kont, sposobu zarządzania tożsamością i konfiguracji usług. Może nią być krótka instrukcja, po której następuje wdrożenie aplikacji. AWS informuje, że nowy proces jest stopniowo udostępniany i na tym etapie dostępny tylko dla ograniczonej liczby klientów.

Dla zespołów IT najważniejszy wniosek nie brzmi: AWS usunął ryzyko związane z infrastrukturą chmurową. Kilka wczesnych decyzji przeniesiono za domyślne ustawienia. To może świetnie działać przy eksperymentach i w małych zespołach, ale zmienia miejsce, w którym powinien odbywać się przegląd. Pierwszy przegląd warto przeprowadzić od razu po utworzeniu projektu, gdy środowisko jest jeszcze wystarczająco małe, by je zrozumieć.

Co właściwie uruchamia AWS

Nowy proces, opisany jako Sign up for AWS (new), organizuje pracę w projektach. Projekt zawiera konto AWS, zasoby utworzone na tym koncie oraz ustawienia określające sposób udostępniania projektu współpracownikom. Projekty należące do jednej osoby tworzą organizację zarządzaną przez AWS Settings.

AWS opisuje to jako uproszczone środowisko dla twórców pracujących w rytmie rozwoju AI. W standardowym modelu AWS zespół zwykle podejmuje decyzje dotyczące konfiguracji konta, tożsamości, uprawnień, regionów, rozliczeń i usług jeszcze przed rozpoczęciem prac. W nowym procesie AWS tworzy początkową strukturę i stosuje ustawienia domyślne, których celem jest szybkie uruchomienie projektu.

Ogłoszenie AWS mówi, że nowi klienci mogą rozpocząć pracę ze 100 dolarami kredytów Free Tier. Dokumentacja AWS ostrzega jednak, że niektórzy klienci mogą zostać poproszeni o dane płatnicze albo od razu trafić do płatnego planu. Ścieżki z darmowym kredytem nie należy więc traktować jako powszechnej gwarancji. W ogłoszeniu podano, że płatny projekt może mieć miesięczny limit wydatków zaczynający się od 20 dolarów, a po osiągnięciu limitu AWS wstrzymuje projekt zamiast pozwalać na dalsze naliczanie opłat ponad ustalony pułap.

Środowisko obsługuje także przejście od małego projektu do bardziej zaawansowanego zarządzania AWS. Gdy obciążenie wymaga wielu regionów albo funkcji nadzoru, takich jak niestandardowe zasady w AWS Organizations, AWS twierdzi, że funkcje zaawansowane można włączyć bez migracji i przestoju. Ta ciągłość ma znaczenie: środowisko startowe nie jest zabawkowym kontem, które później trzeba koniecznie zbudować od nowa.

Nadal jest to odrębny model operacyjny. AWS zarządza w imieniu klienta częścią doświadczenia związanego z organizacją i dostępem. Porównanie opcji rejestracji mówi, że nowe środowisko zarządza zasadami organizacji, w tym zasadami kontroli zasobów i zasadami kontroli usług, a także rolami dostępu ludzi. Klienci, którzy muszą samodzielnie tworzyć zasady organizacji, powinni skorzystać z zaawansowanej ścieżki rejestracji.

Tę różnicę łatwo przeoczyć podczas prezentacji produktu. „Migracja nie jest wymagana” nie oznacza „nie jest wymagana decyzja architektoniczna”. Oznacza, że początkową architekturę można rozszerzyć do modelu zaawansowanego. Organizacja nadal musi zdecydować, czy model zarządzany odpowiada jej wymaganiom kontroli, granicom odpowiedzialności i procesowi audytowemu.

Połączenie z agentem kodującym jest najważniejszym szczegółem

Ogłoszenie AWS robi więcej niż upraszcza rejestrację w konsoli. Po utworzeniu projektu klient otrzymuje instrukcję przeznaczoną do konfiguracji narzędzia AI do kodowania. W przykładzie AWS agent instaluje AWS CLI i Agent Toolkit for AWS, loguje się do środowiska i dodaje do bazy kodu wskazówki dotyczące projektu. Następnie tworzy i wdraża API z użyciem Lambda, DynamoDB i API Gateway.

To nowy rodzaj skrótu przy uruchamianiu: dostawca chmury przekazuje programiście instrukcję, która zmienia ogólnego agenta kodującego w operatora infrastruktury nowego projektu. Taka instrukcja nie jest wyłącznie dokumentacją. Stanowi część ścieżki dostępu między człowiekiem, agentem i interfejsami API chmury.

Ma to znaczenie, ponieważ agent może robić więcej niż zapisywać pliki aplikacji. AWS opisuje połączonego agenta jako zdolnego do wdrażania zasobów, uruchamiania obciążeń i iterowania nad aplikacją zgodnie ze wskazówkami AWS. Przepływy usług mogą też automatycznie konfigurować uprawnienia między obsługiwanymi zasobami. Deweloper może więc widzieć rezultat jako „agent zbudował aplikację”, podczas gdy rzeczywista zmiana obejmuje konto, tożsamości, zasady zasobów, role wykonawcze, wybory sieciowe, konfigurację logowania i obciążenie generujące opłaty.

Wygoda jest celem tego produktu. Nie jest wadą, że twórca może w kilka minut utworzyć działający punkt końcowy. Pytanie operacyjne brzmi: co zespół może obserwować i ograniczać, gdy korzysta z tej szybkości? Instrukcja konfigurująca agenta zasługuje na taką samą uwagę jak skrypt startowy, poświadczenie CI czy moduł infrastruktury. Powinna mieć znane źródło, przejrzaną wersję i jasne wyjaśnienie, jakie tożsamości oraz narzędzia włącza.

Własne wytyczne bezpieczeństwa AWS pokazują ten sam problem z szerszej perspektywy. W ramach kontroli dla agentów AI do kodowania AWS wskazuje iniekcję w promptach i kontekście, zbyt liberalne konfiguracje, niekontrolowane zmiany produkcyjne, ryzyko łańcucha dostaw oraz niekontrolowany dostęp zewnętrzny jako zagrożenia występujące wtedy, gdy agenci czytają niezaufaną treść albo wywołują narzędzia. Wytyczne zalecają oddzielenie zaufanej orkiestracji od agentów wystawionych na niezaufane dane, dostęp zgodny z zasadą najmniejszych uprawnień, ludzką akceptację działań nieodwracalnych oraz deterministyczne bramki na etapie budowania.

Nowe środowisko dla twórców nie usuwa tych ryzyk. Sprawia, że stają się istotne wcześniej, także przy małym proof of concept.

Domyślne ustawienia pomagają, ale nie są zasadą najmniejszych uprawnień

Dokumentacja IAM firmy AWS mówi wyjątkowo wprost o jednym elemencie nowego modelu. Wytyczne dotyczące role manager stwierdzają, że gdy usługa automatycznie tworzy rolę, AWS zwykle może nadać jej odpowiedni zakres, ale niektóre role — szczególnie używane do obliczeń lub zarządzania infrastrukturą chmurową — mogą mieć szerokie uprawnienia, ponieważ AWS nie wie z wyprzedzeniem, co zrobi obciążenie.

To rozsądny kompromis inżynieryjny w środowisku, które ma pozwolić agentowi szybko budować. System, który musi przewidzieć przyszłe działania, nie zawsze utworzy wąską, ostateczną politykę, zanim aplikacja powstanie. Błędem byłoby uznanie automatycznie utworzonej roli za zakończoną decyzję bezpieczeństwa. To punkt wyjścia, którego zakres powinien zostać zawężony, gdy obciążenie stanie się znane.

Ta sama dokumentacja wyjaśnia, jak za pomocą IAM Access Analyzer przejrzeć nieużywane uprawnienia. Dla konta utworzonego w nowym środowisku AWS może udostępnić analizator nieużywanego dostępu na 90 dni po aktywowaniu funkcji zaawansowanych i wyłączeniu role manager. Analizator porównuje dozwolone działania z faktycznie używanymi i przedstawia zalecenia dotyczące ograniczenia uprawnień.

Istnieje jednak ważne ograniczenie: „nieużywane” nie znaczy „niepotrzebne”. AWS informuje, że w tym przepływie role manager zalecenie opiera się na aktywności z ostatnich 30 dni. Zadanie kwartalne, ścieżka odzyskiwania po awarii albo rzadka operacja administracyjna może wyglądać na nieużywaną, choć jest wymagana. Przed zastosowaniem zalecenia osoby oceniające potrzebują wiedzy o obciążeniu.

Rozsądna interpretacja domyślnej roli wygląda więc tak: jest wystarczająco szeroka, by uruchomić projekt, tymczasowa do czasu przeglądu i przypisana wskazanej osobie albo zespołowi. Pierwsze wdrożenie projektu powinno wygenerować krótki wykaz ról, zasad, relacji zaufania i uprawnień opartych na zasobach. Taki wykaz jest cenniejszy niż ogólne stwierdzenie, że konto utworzono z „kontrolami bezpieczeństwa”.

Zarządzana granica projektu zmienia sposób projektowania zespołu

Model projektowy daje małym zespołom wyraźną korzyść. Współpracowników można zapraszać e-mailem, a AWS twierdzi, że każda zaproszona osoba otrzymuje dostęp wyłącznie do projektów wskazanych w zaproszeniu. W nowym środowisku nie trzeba tworzyć użytkowników IAM do zwykłego dostępu ludzi.

Jest to prostsze niż wymaganie od każdego początkującego programisty znajomości pełnego rozróżnienia między użytkownikami IAM, rolami, zasadami tożsamości, zasadami zasobów i IAM Identity Center. Tworzy też wyraźniejszą granicę między eksperymentami. AWS informuje, że zasoby w różnych projektach nie mogą uzyskiwać do siebie dostępu, chyba że dla konkretnych zasobów włączono dostęp między projektami.

Granica projektu nie jest jednak automatycznie granicą biznesową. Zespół powinien zapytać, co reprezentuje projekt. Czy jest to jeden prototyp, jeden produkt, środowisko dla jednego klienta czy tymczasowe zadanie? Kto jest właścicielem danych? Kto otrzymuje alerty rozliczeniowe? Kto może zaprosić kolejną osobę? Co stanie się, gdy pierwotny twórca odejdzie?

Dokumentacja wymienia limity dla nowego modelu zarządzania kontami: do 29 projektów należących do właściciela w planie Free, 299 w planie Paid oraz do 500 osób udostępnionych projektowi. Dla wielu małych zespołów są to wystarczające wartości, ale nie zastępują projektu kont ani organizacji. Grupa, która potraktuje projekty jako nieformalny zamiennik kont deweloperskich, testowych i produkcyjnych, może z czasem odkryć, że granica nie odpowiada jej wymaganiom zgodności ani odzyskiwania.

Zarządzany model organizacji również wymaga wyraźnej decyzji centralnego IT. Jeśli firma potrzebuje własnych zasad kontroli usług, zasad kontroli zasobów albo scentralizowanego cyklu życia polityk, lepszym punktem wyjścia może być zaawansowana ścieżka rejestracji. Jeśli firmie chodzi głównie o bezpieczne miejsce dla odizolowanych prototypów, model zarządzany może być odpowiedni, o ile zasady klasyfikacji danych i własności konta są jasne.

Limity wydatków rozwiązują jeden problem, nie zarządzanie kosztami chmury

Limit wydatków na poziomie projektu jest jedną z najbardziej praktycznych funkcji ogłoszenia. Daje eksperymentowi określony pułap i pozwala AWS wstrzymać projekt po jego osiągnięciu. To lepsze niż wymaganie od programisty oszacowania ceny każdej usługi przed sprawdzeniem pomysłu, a finansom zapewnia konkretną kontrolę nad projektami niskiego ryzyka.

Limit nadal należy traktować jako wyłącznik awaryjny, a nie kompletny system FinOps. Wstrzymanie może przerwać prezentację, wyłączyć punkt końcowy, zatrzymać zaplanowane zadanie albo pozostawić wdrożenie w połowie zakończone. Zespół powinien wiedzieć, co „wstrzymanie” oznacza dla jego aplikacji i czy wznowienie wymaga decyzji człowieka. Powinien też wskazać zasoby, których koszty lub konsekwencje operacyjne mogą nie być oczywiste po pierwszym wywołaniu API.

AWS informuje, że klienci płacą za rzeczywiste użycie do wysokości limitu projektu i otrzymują powiadomienia, gdy zbliżają się do tego limitu. Tworzy to użyteczny wzorzec działania: wcześnie ostrzegać, sprawdzić zasób powodujący wzrost i zachować końcową część budżetu na zaplanowaną pracę. Zespół nie powinien czekać na twardy limit, by odkryć, że agent utworzył kosztowną albo dostępną z zewnątrz usługę.

Właściciel rozliczeń powinien być też oddzielony od programisty eksperymentującego z projektem, gdy projekt zawiera dane biznesowe albo jest dostępny dla klientów. Osoba, która może podnieść limit, powinna wiedzieć, jakie wdrożenie finansuje, dlaczego jest ono potrzebne i jak projekt zostanie wyłączony. Mały budżet również może stworzyć duży problem bezpieczeństwa albo dostępności, jeśli umożliwi niewłaściwe obciążenie.

Co naprawdę różni ten model od wcześniejszego uruchamiania chmury

Zmiana nie polega wyłącznie na wygodniejszej konsoli AWS. Tradycyjne uruchamianie chmury wymaga od ludzi przełożenia pomysłu na aplikację na zestaw decyzji infrastrukturalnych przed wdrożeniem. Nowy proces pozwala twórcy i agentowi podejmować wiele z tych decyzji interaktywnie, wewnątrz projektu z domyślnymi ustawieniami zarządzanymi przez dostawcę.

Zmienia to profil ryzyka na cztery sposoby.

Po pierwsze, skraca się czas między utworzeniem tożsamości a pojawieniem się infrastruktury przypominającej produkcję. Programista może mieć publiczne API, bazę danych i rolę wykonawczą, zanim zdąży się odbyć zwykłe spotkanie przeglądowe.

Po drugie, aktor dokonujący zmian jest mniej przewidywalny. Człowiek zwykle wie, z której strony konsoli albo z którego potoku wdrożeniowego korzysta. Agent może przejrzeć repozytorium, wybrać jedną z opcji architektury, zainstalować narzędzia, wywołać wiele interfejsów API i ponowić próbę po błędzie. Rezultat może być prawidłowy, ale bez logowania i przeglądu trudniej odtworzyć przebieg zmian.

Po trzecie, granica między aplikacją a pracą platformową staje się mniej widoczna. Zadanie programistyczne może w efekcie ubocznym utworzyć role IAM, magazyny danych i dostęp sieciowy. Sam przegląd kodu przestaje więc wystarczać. Diffs infrastruktury i zmiany uprawnień potrzebują własnego miejsca do oceny.

Po czwarte, środowisko startowe może nabrać znaczenia organizacyjnego, zanim ktokolwiek zdecyduje, czy nadal jest środowiskiem startowym, czy już środowiskiem produktu. Prototyp może zacząć gromadzić dane użytkowników, stać się podstawą demonstracji dla klienta albo otrzymać nazwę domenową. Moment, w którym jego kontrole muszą dojrzeć, może nadejść przed formalnym uznaniem go za produkcję.

Nie są to argumenty przeciwko nowemu środowisku. Są powodem, by połączyć je z szybką regułą awansu: każdy projekt, który obsługuje wrażliwe dane, służy użytkownikowi zewnętrznemu albo trwa dłużej niż krótki eksperyment, powinien przejść wyraźny przegląd bezpieczeństwa i własności.

Praktyczny przegląd w pierwszej godzinie

Zespół korzystający z nowego procesu może zachować większość szybkości, dodając niewielką dawkę dyscypliny. Przegląd nie musi odtwarzać całego procesu enterprise landing zone. Powinien odpowiedzieć, czy projekt ma wyraźne granice, daje się obserwować i można go odwrócić.

Potwierdź tożsamość i własność

Zapisz, jaka osobista lub organizacyjna tożsamość utworzyła AWS Builder ID i projekt. Jeśli projekt nie jest prywatnym eksperymentem, potwierdź, że adres e-mail jest kontrolowany przez firmę. Dodaj co najmniej jednego odpowiedzialnego współpracownika za pomocą obsługiwanego mechanizmu dostępu i udokumentuj, kto może zapraszać kolejne osoby.

Nie traktuj logowania społecznościowego jako dowodu, że organizacja jest właścicielem powstałego obciążenia. Własność jest procesem biznesowym. Rekord projektu, kontakt rozliczeniowy, repozytorium i właściciel danych powinny wskazywać ten sam odpowiedzialny zespół.

Zapisz początkowy region i granicę projektu

AWS udostępnia pierwszy projekt w jednym z trzech regionów i nadaje mu nową nazwę. Zapisz ten region przed wdrożeniem usług zależnych od danych. Sprawdź opóźnienia, rezydencję danych, dostępność usług, wymagania wsparcia i założenia dotyczące odzyskiwania. Domyślny region jest miejscem startowym, a nie globalną architekturą.

Wymień zasoby utworzone przez pierwsze wdrożenie i ustal, czy którykolwiek jest publiczny. W przypadku małego API zwykle oznacza to sprawdzenie punktu końcowego, konfiguracji API Gateway, dostępu do magazynu, ekspozycji bazy danych, miejsc docelowych logów oraz uprawnień używanych przez rolę wykonawczą.

Sprawdź role przed dodaniem danych

Przejrzyj automatycznie utworzone role i ich zasady zaufania. Ustal, który podmiot może przejąć każdą rolę oraz jakie usługi lub działania może ona wywoływać. Szczególną uwagę zwróć na role używane przez obliczenia, wdrażanie lub przepływy zarządzania infrastrukturą, ponieważ AWS zaznacza, że mogą być szersze, niż wymaga tego końcowe obciążenie.

Jeśli aplikacja ma działać dłużej niż eksperyment, zaplanuj przegląd Access Analyzer po przejściu obciążenia jego zwykłych ścieżek. Nie usuwaj automatycznie każdego działania oznaczonego przez analizator jako nieużywane. Porównaj zalecenie z wymaganiami dotyczącymi kopii zapasowych, utrzymania, reagowania na incydenty i zadań okresowych.

Wyraźnie określ uprawnienia agenta

Oddziel uprawnienia potrzebne do odczytywania kodu źródłowego od tych, które są potrzebne do zmiany infrastruktury. Jeśli agent może wdrażać, wymagaj zmiany możliwej do przejrzenia oraz ludzkiej akceptacji produkcji lub działań nieodwracalnych. Nie umieszczaj sekretów w promptach, repozytoriach ani wygenerowanej konfiguracji. Eksperymenty prowadź w osobnym projekcie, aby agent nie mógł przypadkiem dotrzeć do niepowiązanych środowisk.

Sam prompt konfiguracyjny powinien być przechowywany albo wskazywany w kontrolowanym miejscu. Przeglądaj aktualizacje AWS CLI, Agent Toolkit oraz wszelkich wskazówek repozytorium tworzonych przez agenta. Plik z instrukcjami projektu może poprawić spójność, ale nadal jest wejściem dla systemu automatycznego i powinien być chroniony przed nieprzejrzanymi zmianami.

Ustal warunek zatrzymania

Ustaw limit wydatków przed rozpoczęciem istotnej pracy. Dodaj odbiorców alertów, którzy nie są wyłącznie pierwotnym programistą. Zdecyduj, co ma się wydarzyć po osiągnięciu limitu: wstrzymanie, dochodzenie, zachowanie logów, podniesienie limitu czy zamknięcie projektu. Ustal termin zakończenia eksperymentu i wyznacz osobę odpowiedzialną za usunięcie niepotrzebnych zasobów.

Wewnętrzna notatka o projekcie może wyglądać tak prosto:

Właściciel: wskazany zespół, nie konto pojedynczego prototypu
Cel: jednozdaniowy opis obciążenia
Klasa danych: publiczne, wewnętrzne, poufne lub zastrzeżone
Region: początkowy region AWS i powód wyboru
Uprawnienia agenta: tylko odczyt, wdrażanie do testów lub zatwierdzona ścieżka produkcyjna
Budżet: limit projektu, odbiorcy alertów i data wygaśnięcia
Reguła awansu: przegląd wymagany przed udostępnieniem użytkownikom zewnętrznym lub użyciem wrażliwych danych

Wartość tej notatki nie wynika z jej formatu. Chodzi o to, że zespół ujawnia decyzje, zanim projekt stanie się trudny do odtworzenia lub zamknięcia.

Kiedy nowe środowisko jest dobrym wyborem

Uproszczona ścieżka dobrze pasuje do programisty sprawdzającego pomysł, małego zespołu budującego usługę przeznaczoną do szybkiego usunięcia, nauczyciela lub osoby uczącej się w ramach ograniczonego budżetu oraz organizacji, która chce odizolowanych prototypów bez kierowania każdego twórcy przez pełny proces wydawania kont. Model projektów, automatyczna konfiguracja i limit wydatków bezpośrednio zmniejszają tarcie, które często prowadzi ludzi do nieformalnego korzystania z zasobów chmurowych.

Mniej oczywistym wyborem jest to dla obciążenia, które od początku potrzebuje centralnie tworzonych zasad organizacji, złożonego rozdzielenia wielu kont, ścisłych kontroli regionalnych, ustalonej federacji tożsamości, obsługi danych regulowanych albo produkcyjnego wdrożenia o dużym promieniu rażenia. Takie zespoły nadal mogą użyć nowego procesu jako piaskownicy, ale nie powinny mylić szybkiej piaskownicy z produkcyjną płaszczyzną kontroli.

Czynnikiem rozstrzygającym nie jest to, czy zespół korzysta z AI. Połączenie z agentem sprawia, że zmiana jest bardziej widoczna, ale te same pytania dotyczą człowieka używającego konsoli. Kto może zmienić środowisko? Jakie uprawnienia są nadawane? Jakie dane mogą trafić do środowiska? Jak zmiany są przeglądane? Skąd organizacja wie, co istnieje? Jak zatrzyma obciążenie i odzyska dane?

Szersza lekcja dotycząca infrastruktury

Dostawcy chmury od lat ułatwiają korzystanie z pojedynczych usług. AWS sprawia teraz, że pierwsze konto i pierwsze wdrożenie przypominają bardziej przepływ pracy aplikacji. To logiczna odpowiedź na rozwój programowania wspomaganego przez AI, w którym osoba pisząca prompt może oczekiwać, że platforma automatycznie rozwiąże szczegóły infrastruktury.

Koszt tej zmiany polega na tym, że nadzór nad chmurą przesuwa się bliżej chwili utworzenia. Przegląd bezpieczeństwa przeprowadzony dopiero po utworzeniu zasobów przez agenta jest działaniem porządkowym. Krótka kontrola granicy projektu, uprawnień agenta, ról, regionu i budżetu jest mechanizmem umożliwiającym pracę: mówi twórcy, co może wydarzyć się bezpiecznie, a co wymaga eskalacji.

Opublikowane wytyczne AWS prowadzą właśnie do takiego warstwowego podejścia. Zacznij od ustawień domyślnych, a potem dodaj przegląd najmniejszych uprawnień, gdy obciążenie stanie się znane. Używaj automatycznego skanowania i deterministycznych bramek dla zmian wygenerowanych przez system. Zachowaj ludzką akceptację dla działań o dużym wpływie. Traktuj zewnętrzny tekst, instrukcje repozytorium i odpowiedzi narzędzi jako potencjalnie niezaufane dane wejściowe.

Nowe środowisko AWS dla twórców najlepiej rozumieć jako szybszy etap wejścia z nowym punktem kontrolnym, a nie jako zastępstwo praktyk operacyjnych chmury. Pierwszy projekt można utworzyć w kilka minut. Pierwszy przegląd nadzoru powinien odbyć się równie szybko.

Źródła

Artykuł opiera się na dokumentacji i materiałach AWS dotyczących nowego procesu rejestracji, zarządzania kontami, ról IAM, agentów kodujących i kontroli bezpieczeństwa. Wykorzystane odnośniki to: AWS reimagines the getting started experience, New AWS experience helps builders get started and ship faster, Sign up for AWS (new), Compare sign-up options, Apply least-privilege permissions to a role created automatically, Balancing speed and safety: A control framework for AI coding agents, Quotas for AWS Account Management oraz OWASP Top 10 for Large Language Model Applications v2.0.