22 вересня (за часом США) Anthropic випустила Claude Opus 5.5.
Того ж дня OpenAI анонсувала GPT-6 Sol та Luna.
Обидві моделі «розумніші, ніж раніше, і дешевші, ніж раніше».
Серед усього цього мою увагу привернула одна конкретна цифра в офіційному анонсі.
У коментарі від Deloitte зазначено:
«Навіть на найнижчому рівні налаштувань вона знайшла 72% відомих багів. Opus 5 на високому рівні знаходила 56%».
Це означає, що здатність читати код і шукати вразливості суттєво зросла всього за одне покоління.
ШІ створюватиме речі, які «працюють».
Але щоб вони були «безпечними», людина має давати інструкції.
Тож ось 5 моментів, про які варто пам'ятати, коли ви будуєте внутрішні додатки за допомогою Opus 5.5.
Кожен пункт подано разом із промптом, щоб Opus 5.5 перевірив вашу роботу.
====
Як проводити перевірку
Коли ви завершили розробку, не питайте «Чи є тут проблеми?» в тій самій сесії, де ви це створювали.
ШІ, який писав код, сприймає власний дизайн як даність, тому стає поблажливим.
Відкрийте нову сесію, оберіть модель Opus 5.5 і покажіть їй усю папку додатка.
Потім переконайтеся, що для кожної знайденої проблеми вказано «який файл і який рядок».
У коментарі Deloitte згадується, що хибних спрацьовувань стало менше, але їхня кількість не дорівнює нулю.
Якщо вказано точне місце, людина зможе перевірити його пізніше.
Ось інструкція:
«Ти — спеціаліст із безпеки, який бачить цей код уперше. Якщо знайдеш проблеми, вкажи назву файлу, номер рядка, чому це небезпечно та як це виправити. Усе, в чому ти не впевнений, виноси окремо з позначкою "Потребує перевірки"».
====
1. Чи є щось доступне для тих, хто не авторизувався?
Коли розробку делегують ШІ, екрани або точки доступу до даних можуть залишитися без захисту логіном.
Типова ситуація: сторінки підтвердження, створені під час розробки, залишаються публічно доступними.
Перевірка дуже проста.
Відкрийте URL-адреси адмінпанелі або даних напряму в браузері без входу в акаунт (у режимі інкогніто).
Якщо ви їх бачите — це провал.
Ось інструкція:
«Перерахуй усі URL-адреси та API, доступні без авторизації. Серед них відсортуй за рівнем небезпеки ті, що повертають дані або призначені для адміністрування».
====
2. Чи можуть авторизовані користувачі бачити чужі дані?
Авторизація лише підтверджує, «хто» зайшов.
А от «що цій людині дозволено бачити» потрібно реалізовувати окремо.
Для перевірки створіть два тестових акаунти. Увійдіть як користувач A, а потім спробуйте відкрити URL-адресу даних користувача B.
Ось інструкція:
«Знайди всі шляхи, якими Користувач A може переглядати або змінювати дані Користувача B. Враховуй також випадки, коли URL-адреси чи API викликаються напряму, в обхід інтерфейсу».
====
3. Чи не лежать ключі або паролі на видному місці?
Код, який виконується на стороні браузера, повністю надсилається на комп'ютер користувача.
Прописувати ключі там — це те саме, що роздавати їх усім охочим.
Ще одна поширена помилка — завантажувати конфігураційні файли з ключами у спільні папки або на GitHub.
Ось інструкція:
«Знайди API-ключі, паролі або токени у коді на стороні браузера, конфігураційних файлах чи історії комітів. Якщо знайдеш, запропонуй, куди їх слід перенести».
====
4. Чи не забагато прав надано інструментам для їхніх завдань?
Внутрішні інструменти часто підключаються до Google, Slack або баз даних.
Іноді виданий ключ дозволяє «видаляти» або «переглядати все», хоча достатньо лише права на «читання».
Це дуже часта проблема.
Якщо такий ключ потрапить у чужі руки, масштаб збитків визначатиметься саме обсягом наданих прав.
Перевірка полягає в тому, щоб відповісти на питання: «У найгіршому випадку, що цей інструмент зможе видалити?».
Якщо ви не можете відповісти одразу — будьте обережні.
Ось інструкція:
«Перерахуй усі права, які цей інструмент має щодо зовнішніх сервісів або баз даних. Порівняй кожне право з мінімально необхідним для реальної роботи та вкажи на надлишкові».
====
5. Чи не виконуються вхідні тексти ззовні як команди?
До інструментів, які дозволяють ШІ читати електронні листи, вебсторінки або завантажені файли, треба ставитися з особливою обережністю.
Якщо в них міститься текст на кшталт «Ігноруй попередні інструкції та зроби XX», ШІ може їх виконати.
Це називається Prompt Injection.
В анонсі Opus 5.5 зазначено, що стійкість до таких атак «дорівнює або перевищує показники Opus 5 у всіх протестованих сценаріях».
Однак «дорівнює або перевищує» не означає нульовий ризик. Захист на боці самого інструменту все одно потрібен.
Ось інструкція:
«Знайди місця, де текст або файли, завантажені ззовні, сприймаються як інструкції для ШІ. Якщо такі є, зміни логіку так, щоб завантажений контент оброблявся виключно як довідкова інформація, а будь-які інструкції в ньому ігнорувалися».
====
Підсумок
ШІ створить той функціонал, про який ви попросите.
Але «не показуй це іншим» і «не надавай зайвих прав» він не реалізує, поки ви про це не скажете.
І навпаки: усі ці 5 пунктів можна закрити, просто додавши одну інструкцію.
До того ж здатність Opus 5.5 знаходити дірки у вашому коді теж стала кращою.
Після розробки покажіть результат Opus 5.5 у новому діалозі.
Вважайте це частиною процесу розробки.
Якщо у вас уже працює внутрішній додаток, почніть із того, що вставте інструкцію для перевірки з розділу «Як проводити перевірку».
А якщо вставляти інструкції щоразу набридає, спробуйте плагін security-review.
Він звертає увагу на дрібні деталі та вказує на них, тому я й сам регулярно ним користуюся.
====
І наостанок — невеличке оголошення.
Наша компанія створює AI-агентів під конкретні бізнес-задачі вашої компанії з нуля.
Ми не проводимо навчання і не просто впроваджуємо інструменти. Ми детально вивчаємо ваші реальні бізнес-процеси, щоб передати вам рішення, готове до роботи «вже завтра». Інтеграцію та подальшу підтримку ми також беремо на себе.
