Production guardrails за AI агенти за безопасна автономност

Production guardrails за AI агенти трябва да издържат на повече от любезен prompt. Автономен coding агент може да разбере погрешно target, да повтори операция, да разкрие credential в обяснението си или да продължи след нееднозначен отговор. Затова безопасността в production трябва да съществува в executable interface-а, authorization модела и audit trail-а, а не само в инструкциите.

Dockup комбинира поведенчески насоки в skill-а си за Claude Code и Codex с enforcement на ниво CLI: secrets се маскират, destructive operations изискват --yes, грешките връщат стабилни кодове, deploy-ите могат да изчакват terminal state, а mutations се появяват в audit log-а.

Защо guardrails трябва да се налагат под prompt-а?

Prompt-ът е полезна policy, но не е security boundary. Agent context-ът може да бъде съкратен, инструкциите могат да си противоречат, а моделът може да избере неправилна интерпретация. Базовият tool трябва да прави unsafe поведението трудно или невъзможно.

Нека разгледаме заявка за изтриване. При слабия дизайн се предоставя команда, която изтрива незабавно, и се разчита агентът да не забрави да попита. По-силният дизайн отказва операцията, освен ако не е подаден отделен flag за потвърждение.

Dockup използва по-силния модел:

dockup up production/api --prune --json

Без изрично потвърждение destructive cleanup-ът се отказва, а JSON-ът включва code:"needs_confirm". Нищо не се премахва. Агентът трябва да покаже резултата на човек, да получи одобрение и след това съзнателно да изпълни отново:

dockup up production/api --prune --yes --json

Това е defense in depth. Dockup skill-ът указва на агента да спре, а CLI предотвратява случайното изпълнение дори ако инструкцията бъде пропусната.

Как secret masking-ът защитава автономните агенти?

Агентите често включват изхода от командите в reasoning-а или във финалния си отговор. Ако read операция върне production token, secret-ът може да попадне в chat history, logs, telemetry, screenshots или копирани incident notes.

Безопасният configuration interface разделя metadata-та на secret-а от самите secret values. Dockup връща ключовете на environment variables и маркера isSecret, но съхранените secret values са null или маскирани.

dockup env list -s production/api --json

Агентът може да зададе secret, без по-късно да го извлича:

dockup env set API_KEY="$API_KEY" \
  --secret \
  -s production/api \
  --json

Secret masking-ът не отменя необходимостта от внимателно обработване на процесите. Оригиналната стойност все още съществува в shell environment-а по време на set операцията. Избягвайте set -x, не извеждайте променливата с echo и не създавайте command strings, които се прихващат от verbose logging.

Паролите за databases, API keys, registry tokens, SSH credentials и Windows RDP credentials трябва да се третират като outputs за еднократна употреба или с ограничен достъп. Агентът трябва да ги съхранява в одобрен secret manager или да ги подава директно към следващия процес, без да ги възпроизвежда в prose.

По-широкият подход на ниво application е разгледан в security best practices.

Как трябва да работи одобрението на destructive actions?

Не всяка mutation заслужава еднаква процедура. Полезният модел за автономност разделя операциите според обратимостта и blast radius-а им:

Ниво	Пример	Поведение на агента по подразбиране
Само за четене	Извеждане на списък със services, четене на status, преглед на logs	Изпълнява и обобщава
Обратим write	Задаване на variable, стартиране на deploy	Изпълнява в рамките на одобрения scope
Operational recovery	Restart, повторно изпълнение на по-стар deployment	Изпълнява, ако runbook-ът го позволява; отчита evidence
Destructive	Унищожаване на service, изтриване на database, напускане на project	Спира и изисква изрично одобрение
Broad destructive	Прилагане на --prune, прехвърляне на ownership	Изисква потвърждение от човек, специфично за target-а

Изричното одобрение трябва да включва точния target и последицата. „Да, продължи“ е по-слабо от „Изтрий staging/old-api и свързаните с него service resources“. Агентът не трябва да използва повторно одобрение, дадено за друга команда или target.

Dockup config as code е additive по подразбиране. dockup up няма да премахне environment variables или domains, които липсват в manifest-а. Изтриването изисква изричния flag --prune:

dockup plan production/api --json
dockup up production/api --prune --json

Plan-ът е read-only и трябва първо да бъде прегледан. Дори с --prune secrets, services, databases и volumes са защитени от този manifest cleanup path. Вижте dockup.yaml config as code за целия workflow.

Как structured errors поддържат ограничена автономност?

Агентът се нуждае от краен набор безопасни branches. Свободно форматираните съобщения са полезни за хората, но стабилните error codes правят първата реакция детерминистична.

Код	Правилна реакция
not_logged_in	Спри и получи валиден credential
not_linked	Разреши target-а или го подай изрично
no_target	Стартирай service discovery; никога не измисляй slug
needs_confirm	Поискай одобрение от човек
deploy_trigger_failed	Докладвай защо операцията не е могла да стартира
deploy_failed	Провери build logs
deploy_timeout	Докладвай не-terminalна несигурност

При deployment трябва да се изчаква terminal state:

dockup deploy production/api --wait --json

Timeout-ът по подразбиране е 900 секунди. Exit 0 доказва, че deployment-ът е достигнал успешно състояние. Non-zero exit предотвратява продължаването на агента към domain changes, migrations или announcements, сякаш production вече е готов.

Този дизайн е разгледан в AI agent CLI design. Принципът е прост: tool-ът трябва да прави нееднозначния резултат явен.

Какво трябва да записва audit log-ът?

Автономността без attribution е operational debt. Production audit trail трябва да отговаря кой е извършил действието, кой interface е използван, кой target е променен, дали операцията е била read или write, кога се е случила и дали е била успешна.

Dockup записва actions от CLI, UI и API. Операторите могат да преглеждат последните mutations:

dockup audit --writes --json
dockup audit --number 30 --json
dockup audit --search domains --json

Собственият report на агента трябва да допълва platform record-а. Включете:

1. Разрешения project/service target.
2. Категорията на командата, без secret values.
3. Deployment или resource IDs, върнати от platform-а.
4. Exit code и structured status.
5. Evidence, събрано след mutation-та.
6. Всички получени одобрения за destructive work.
7. Оставаща несигурност или follow-up.

Audit logs не са само за търсене на вина след incident. Те позволяват на втори агент или human operator да възстанови състоянието, без да повтаря рискови команди.

Как екипите могат безопасно да увеличат автономността на агента?

Започнете с read access и една service с нисък риск. Разширявайте достъпа само когато агентът демонстрира правилно target discovery, добра secret hygiene, коректно branching при failures и качествено reporting.

Практическата прогресия е:

Етап 1: Наблюдение

Разрешете service listing, status, deployment history, build logs, runtime logs, uptime, usage и security scan reads. Сравнете обобщението на агента със суровия JSON.

Етап 2: Deploy към фиксиран target

Позволете deployment на една service с --wait. Изисквайте health check и structured completion report. Не предоставяйте права за изтриване или управление на team permissions.

Етап 3: Управление на обратима configuration

Позволете updates на non-secret и secret variables, конфигуриране на health checks и настройване на custom domains съгласно прегледан runbook. Изисквайте redeployment след промени в environment-а.

Етап 4: Изпълнение на recovery actions

Позволявайте restart или rollback само когато агентът избере точен, известен deployment ID и запази evidence за failure-а.

Етап 5: Destructive work с изискване за одобрение

Дръжте destructive flags зад изрично одобрение от човек, дори когато credential-ът технически позволява използването им. Използвайте scoped API keys, когато е възможно, и редовно преглеждайте audit trail-а.

Инсталирането на agent skill-а подсилва тези поведения:

npm install -g dockup-cli
dockup skill install
dockup skill status --json

Dockup CLI reference документира enforced поведението на командите. Агентът трябва да проверява локалната си schema, вместо да разчита на запомнен пример.

Checklist за преглед на guardrails

Преди да предоставите production access, отговорете на всеки въпрос:

• Може ли агентът да открива точните targets, без да гадае?
• Маскират ли се secret values във всички read paths?
• Връща ли всяка неуспешна mutation non-zero?
• Могат ли дългите операции да изчакват terminal state?
• Блокират ли се destructive actions без изрично потвърждение?
• Scoped ли са credentials и подават ли се извън prompts?
• Може ли всяка mutation да бъде открита в audit log?
• Има ли тествана процедура за rollback или recovery?
• Възможно ли е версиите на skill-а и executable-а да се разминават?
• Разделя ли финалният report фактите от несигурността?

Отговорът „не“ е design task, а не task за писане на prompt. Production autonomy трябва да нараства само с нарастването на базовите гаранции.

Тествайте guardrails като failure cases

Прегледът е непълен, докато екипът умишлено не задейства граничните сценарии. Изпълнете deploy с невалиден token, поискайте неизвестен target, позволете на тестов build да се провали, задайте много кратък timeout и опитайте destructive command без потвърждение. Всеки случай трябва да произведе non-zero exit, стабилен code, никакво изтичане на secret и никаква непредвидена mutation.

Тези тестове превръщат production guardrails за AI агенти в наблюдаеми гаранции. Повтаряйте ги след updates на CLI или policy, както бихте повторили authentication и authorization тестовете за application. Guardrail, който съществува само в презентация, няма да защити unattended release.

Въведете workflow-а в production

Инсталирайте skill-а, прегледайте инструкциите му и тествайте всеки guardrail — включително блокирана destructive command — преди да издадете production token.

npm install -g dockup-cli
dockup skill install

Първата команда инсталира CLI. Втората инсталира съответния Dockup skill за Claude Code и Codex. Започнете безплатно в app.dockup.ai.

FAQ

Достатъчни ли са prompt инструкциите, за да бъде AI агентът безопасен в production?

Не. Prompt-овете помагат за насочване на поведението, но критичните контроли като secret masking, потвърждение, authorization, exit codes и audit logging трябва да се налагат от tool-а и platform-а.

Как Dockup блокира destructive operations?

Destructive commands отказват да се изпълнят без изричния flag --yes и връщат structured code needs_confirm, което позволява на агента да спре и да попита човек.

Може ли AI агент да прочете secret environment values от Dockup?

Съхранените secret values са маскирани в output-а. Агентът може да види key-а и secret marker-а и да замени стойността, но не получава съхранения secret.

Защо structured error codes са важни за автономността?

Те ограничават агента до известни recovery branches, като заявяване на authentication, откриване на точния target, прочитане на build logs или искане на потвърждение.

Как екипът трябва да започне да предоставя production access?

Започнете с read-only operations, след това разрешете deployment към един target с нисък риск и разширявайте към reversible configuration и recovery едва след като агентът последователно отчита проверими evidence.