Przejdź do głównej zawartości
AI Developer Toolkit

Bramki bezpieczeństwa dla kodu pisanego przez agentów: Semgrep, Gitleaks, TruffleHog, Snyk i Claude Security Review

Bramki bezpieczeństwa dla kodu pisanego przez agentów to deterministyczne skanery i agenci review ustawieni w czterech miejscach: w sesji agenta, przy git commit, w CI i na pull requeście. Gitleaks i TruffleHog zatrzymują sekrety, Semgrep i Snyk wykrywają podatny kod i zależności, a security review od Claude dodaje ocenę modelu. Obowiązkowe dla każdego, kto wnosi zmiany, może być tylko CI.

Agent podpina płatności Stripe w 12 minut, testy przechodzą, a w diffie siedzi new Stripe("sk_live_…"), bo klucz był w pliku .env, który agent przeczytał jako kontekst. Nikt nie czyta 40. linii z 600-liniowego diffu, a agent commituje co kilka minut. Ta strona jest dla programistów, którzy chcą, żeby agent został zatrzymany, zanim sekret albo injection trafi do main, i dla tech leadów, którym ta blokada ma działać dla ośmiu osób i trzech różnych agentów.

Co skonfigurujesz dzięki tym bramkom bezpieczeństwa

Dział zatytułowany „Co skonfigurujesz dzięki tym bramkom bezpieczeństwa”
  • Hook pre-commit z Gitleaks, który blokuje commit agenta zawierający sekret.
  • Czterowarstwowy workflow z narzędziem dla każdej warstwy w Claude Code, Codeksie i Cursorze.
  • Dwa przetestowane hooki Claude Code: jeden skanuje każdy zapisany plik, drugi nie pozwala agentowi pominąć hooków commita.
  • Workflow CI dla TruffleHog, Semgrepa i utwardzonego claude-code-security-review.
  • Trzy prompty do skopiowania, metryki, które dowodzą, że bramki działają, i pułapki.

Ta strona dotyczy skanerów. Boty, które czytają diff pod kątem błędów logiki, porównuje strona boty do AI code review, a procedurę, którą człowiek przechodzi na pull requeście agenta, opisuje review pull requesta od agenta.

Która bramka bezpieczeństwa łapie co?

Dział zatytułowany „Która bramka bezpieczeństwa łapie co?”

Każde narzędzie poniżej sprawdziliśmy 2026-09-26 w jego README, w rejestrze npm lub PyPI, w pliku marketplace’u wtyczek Anthropic albo w zainstalowanych CLI (Claude Code 2.1.283, Codex CLI 0.157.1).

WarstwaNarzędzieCo łapieGdzie działaCzy blokuje?Koszt
1. Sesjawtyczka security-guidance (Anthropic)ok. 25 niebezpiecznych wzorców przy edycji; review diffu przez LLM na koniec tury; agentowe review przy git commithooki Claude CodePrzekazuje uwagi Claude’owi; możesz ją wyłączyćTokeny modelu za każde review
1. SesjaSemgrep Guardian (wtyczka: serwer MCP, hooki, skille)Wyniki Semgrep Code, Supply Chain i Secrets dla każdego pliku zapisanego przez agentaClaude Code, Cursor; semgrep mcp w dowolnym kliencie MCPKaże agentowi poprawiać kod, aż skan będzie czystyDarmowe CLI; reguły Pro wymagają semgrep login
1. Sesja/security-review (wbudowane w Claude Code)Ryzyka injection, autoryzacji i ujawnienia danych w diffie gałęziTwoja sesjaNie, raportujeZwykłe zużycie
2. Commithook pre-commit z GitleaksZaszyte na sztywno sekrety w zmianach w stageTwoja maszyna, dowolny agentTak, chyba że ktoś go pominieZa darmo
3. CITruffleHogSekrety zweryfikowane na żywo u wystawcyGitHub Actions lub dowolne CITak, --fail kończy z kodem 183Za darmo
3. CISemgrepPodatne wzorce w kodzie, tylko nowe wynikiDowolne CITak, --error kończy z kodem 1Darmowe CLI
3. CISnyk MCP i CLI; SonarQube MCPPodatne zależności i kod; quality gatesSesja agenta i CIPrzez bramkę Snyka lub SonarQubePlan dostawcy
4. Pull requestanthropics/claude-code-security-reviewPodatności semantyczne, z filtrowaniem fałszywych alarmówGitHub ActionsTylko przez check, który sam zbudujeszTokeny API
NarzędziaSnyk Agent ScanPrompt injection i tool poisoning w konfiguracjach MCP i skillachTwoja maszyna lub CI--ci kończy z niezerowym kodemToken Snyka

Najważniejszy podział: warstwy 1 i 2 działają na maszynie programisty, gdzie agent albo człowiek może je wyłączyć. Warstwa 3 działa tam, gdzie nikt tego nie zrobi, więc tylko ją ustawiasz jako wymagany check. Warstwy 1 i 2 istnieją po to, żeby warstwa 3 była nudna.

Popularność na dzień 2026-09-26: gitleaks/gitleaks miał 29,5 tys. gwiazdek na GitHubie, trufflesecurity/trufflehog 28,1 tys., a semgrep/semgrep 16,8 tys.; w katalogu wtyczek Anthropic (claude.com/plugins) security-guidance miała 241 800 instalacji. Gwiazdki i instalacje mierzą zainteresowanie, a nie skuteczność wykrywania.

Przykład: hook pre-commit z Gitleaks zatrzymuje commit agenta

Dział zatytułowany „Przykład: hook pre-commit z Gitleaks zatrzymuje commit agenta”

To najmniejsza bramka o największym zysku i działa tak samo w Claude Code, Codeksie i Cursorze, bo każdy agent commituje przez git.

  1. Zainstaluj Gitleaks i framework pre-commit (PyPI pre-commit 4.6.2 na dzień 2026-09-26):

    Okno terminala
    # Terminal
    brew install gitleaks
    pipx install pre-commit

  2. Dodaj .pre-commit-config.yaml w katalogu głównym repozytorium. Poniższy rev to wersja przypięta w README Gitleaks; pre-commit autoupdate przestawi go na najnowsze wydanie.

    repos:
      - repo: https://github.com/gitleaks/gitleaks
        rev: v8.24.2
        hooks:
          - id: gitleaks

    Hook gitleaks uruchamia gitleaks git --pre-commit --redact --staged --verbose, więc skanuje tylko to, co jest w stage, i nigdy nie wypisuje sekretu. Jeśli Gitleaks jest już zainstalowany przez Homebrew, identyfikator hooka gitleaks-system użyje tej binarki zamiast budować własną.

  3. Zainstaluj hook i przestaw go na najnowsze wydanie:

    Okno terminala
    pre-commit autoupdate
    pre-commit install

    pre-commit install zapisuje .git/hooks/pre-commit, który istnieje osobno w każdym klonie. Każdy programista uruchamia to raz, a każdy nowy worktree dzieli hook przez wspólny katalog .git.

  4. Pozwól agentowi zrobić commit. Gdy diff w stage zawiera prawdziwy klucz Stripe, commit się nie udaje, a agent czyta w wyjściu powłoki (blok z wynikiem to prawdziwe wyjście Gitleaks 8.24.2):

    Detect hardcoded secrets.................................................Failed
    - hook id: gitleaks
    - exit code: 1
    

    Finding:     ...tripe = new Stripe("REDACTED");
    Secret:      REDACTED
    RuleID:      stripe-access-token
    Entropy:     5.280395
    File:        src/billing.ts
    Line:        1
    Fingerprint: src/billing.ts:stripe-access-token:1

  5. Sprawdź, co agent zrobi dalej. Właściwa reakcja: zastąpić literał przez process.env.STRIPE_SECRET_KEY, zdjąć plik ze stage i zrobić commit ponownie. Złe reakcje to git commit --no-verify, SKIP=gitleaks git commit albo komentarz #gitleaks:allow — wszystkie trzy opisuje dokumentacja Gitleaks. Drugi hook Claude Code z następnej sekcji blokuje dwie pierwsze, a warstwa CI łapie dwie pierwsze, a komentarz #gitleaks:allow także wtedy, gdy TruffleHog potrafi zweryfikować klucz albo gdy dodasz do CI Gitleaks z --ignore-gitleaks-allow (warstwa 3).

  6. I tak zrotuj klucz. Sekret był w pliku, który agent przeczytał, więc trafił do kontekstu modelu i do zapisu sesji. Zablokowany commit oznacza, że klucz nie trafił do historii Gita, a nie że pozostał prywatny.

Zbuduj czterowarstwowy workflow bezpieczeństwa

Dział zatytułowany „Zbuduj czterowarstwowy workflow bezpieczeństwa”

Każda warstwa jest tańsza od następnej i łapie to, co przepuściła poprzednia:

  1. Hook w sesji. Każdy zapisany plik jest skanowany, a uwagi wracają do agenta, zanim skończy się tura.
  2. Pre-commit na maszynie. Gitleaks blokuje commit, niezależnie od tego, czy zrobił go agent, IDE czy człowiek.
  3. CI przy każdym pushu i pull requeście. TruffleHog i Semgrep działają tam, gdzie żaden agent ich nie pominie. To jest wymagany check.
  4. Security review na pull requeście. Model czyta diff pod kątem błędów, których nie złapie żaden wzorzec, na przykład sprawdzenia uprawnień na złym obiekcie, a jego uwagi czyta osoba z twojej listy eskalacji.

Warstwa 1: skanuj w sesji agenta

Dział zatytułowany „Warstwa 1: skanuj w sesji agenta”

Warstwa w sesji najbardziej różni się między narzędziami, więc wybierz swoją zakładkę.

Wtyczka security-guidance od Anthropic uruchamia trzy warstwy jako hooki: ostrzeżenia regex przy Edit i Write dla około 25 niebezpiecznych wzorców (yaml.load, pickle.load, surowe innerHTML, zaszyte sekrety), review diffu przez LLM, gdy Claude kończy turę, oraz agentowe review przy git commit, które czyta powiązane pliki, żeby prześledzić przepływ danych. Wymaga Claude Code 2.1.144 lub nowszego i Pythona 3.8 lub nowszego.

Okno terminala
# Terminal
claude plugin install security-guidance@claude-plugins-official

Reguły specyficzne dla twojego kodu zapisz w .claude/claude-security-guidance.md i zacommituj. Pliki użytkownika, projektu i lokalny mają łącznie budżet 8 KB, a review przy commicie ich nie czyta. W konfiguracjach, w których kilku agentów dzieli jeden worktree, ustaw ENABLE_STOP_REVIEW=0, bo inny agent może przesunąć HEAD między turami.

Semgrep Guardian łączy serwer MCP Semgrepa, hooki i skille i ponownie skanuje każdy plik zapisany przez agenta regułami Semgrep Code, Supply Chain i Secrets:

# W Claude Code
/plugin install semgrep@claude-plugins-official
/setup-semgrep-plugin

/setup-semgrep-plugin instaluje też CLI Semgrepa. Przed pushem uruchom /security-review, które przegląda diff między twoją gałęzią a domyślną gałęzią na origin.

Dwa własne hooki. Pierwszy skanuje każdy zapisany plik Gitleaksem, więc agent dowiaduje się o sekrecie kilka sekund po jego wpisaniu, a nie dopiero przy commicie. Zapisz go jako .claude/hooks/scan-secrets.sh i nadaj prawo wykonywania:

#!/usr/bin/env bash
# .claude/hooks/scan-secrets.sh (PostToolUse, matcher "Edit|Write")
set -uo pipefail
command -v gitleaks >/dev/null || { echo "gitleaks not installed; secret scan skipped" >&2; exit 0; }
file=$(jq -r '.tool_input.file_path // empty')
[ -z "$file" ] || [ ! -f "$file" ] && exit 0


if ! out=$(gitleaks dir "$file" --redact --no-banner --verbose 2>&1); then
  echo "Gitleaks found a hardcoded secret in $file:" >&2
  echo "$out" | grep -E '^(RuleID|Line):' >&2
  echo "Remove the literal. Read the value from an environment variable instead, and do not add gitleaks:allow." >&2
  exit 2
fi
exit 0

Kod wyjścia 2 przekazuje komunikat Claude’owi, który w następnym kroku poprawia plik. Drugi hook blokuje polecenia, które omijają warstwę pre-commit. Zapisz go jako .claude/hooks/guard-commit.sh:

#!/usr/bin/env bash
# .claude/hooks/guard-commit.sh (PreToolUse, matcher "Bash")
set -uo pipefail
cmd=$(jq -r '.tool_input.command // empty')


deny() {
  jq -nc --arg r "$1" '{hookSpecificOutput: {hookEventName: "PreToolUse",
    permissionDecision: "deny", permissionDecisionReason: $r}}'
  exit 0
}


[[ $cmd =~ git[[:space:]] ]] || exit 0
[[ $cmd =~ --no-verify|(^|[[:space:]])-[a-zA-Z]*n[a-zA-Z]*([[:space:]]|$)|SKIP=|core\.hooksPath ]] &&
  [[ $cmd =~ git[[:space:]]+(-c[[:space:]]+[^[:space:]]+[[:space:]]+)*(commit|push|config) ]] &&
  deny "Commit hooks must run. Fix what the hook reported and commit again without --no-verify, -n, SKIP= or a hooksPath override."
exit 0

Przetestowany na ośmiu poleceniach: blokuje git commit --no-verify, git commit -nm, SKIP=gitleaks git commit, git -c core.hooksPath=/dev/null commit, git push --no-verify i git config core.hooksPath, a przepuszcza git commit -m "fix n+1 query" i git log -n 5. Może dać fałszywy alarm, gdy wiadomość commita zawiera osobne słowo -n albo gdy polecenie jest złożone; agent wtedy przeformułowuje polecenie, a to bezpieczny kierunek błędu. Zarejestruj oba w .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      { "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/guard-commit.sh", "args": [] }] }
    ],
    "PostToolUse": [
      { "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/scan-secrets.sh", "args": [], "timeout": 30 }] }
    ]
  }
}

Format hooków i działanie decyzji deny opisuje strona hooki Claude Code w automatyzacji.

Warstwa 2: zablokuj commit na maszynie

Dział zatytułowany „Warstwa 2: zablokuj commit na maszynie”

Warstwa 2 to hook Gitleaks z przykładu powyżej; dopisz pre-commit install do skryptu konfiguracji repozytorium, żeby nowy klon albo sandbox agenta też go dostał.

Warstwa 3: skanuj w CI, gdzie żaden agent tego nie pominie

Dział zatytułowany „Warstwa 3: skanuj w CI, gdzie żaden agent tego nie pominie”

Ten workflow działa przy każdym pull requeście. Nie ma w nim sekretów, używa tokena tylko do odczytu i nie zostawia tokena w .git/config. Zapisz go jako .github/workflows/security-gates.yml:

name: Security gates
on:
  pull_request:
  push:
    branches: [main]
permissions:
  contents: read
jobs:
  secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          persist-credentials: false
      - uses: trufflesecurity/trufflehog@main # przypnij do SHA commita wydania
        with:
          extra_args: --results=verified,unknown
  sast:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    container: semgrep/semgrep # przypnij tag wersji albo digest sha256
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          persist-credentials: false
      - name: Semgrep, new findings only
        env:
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
        run: semgrep scan --config p/default --error --metrics=off --baseline-commit "$BASE_SHA"

Akcja TruffleHog sama przekazuje --fail, więc zweryfikowany, działający sekret zmienia zadanie na czerwone z kodem wyjścia 183. --results=verified,unknown odrzuca niezweryfikowanych kandydatów, co ogranicza szum. --error w Semgrepie kończy z kodem 1, gdy są wyniki, a --baseline-commit raportuje tylko te wprowadzone przez pull request. Jeśli chcesz uruchamiać w CI także Gitleaks, gitleaks git --redact --ignore-gitleaks-allow --log-opts="$BASE_SHA..HEAD" skanuje zakres commitów pull requesta i ignoruje komentarze #gitleaks:allow, więc łapie też wyciszony klucz, którego TruffleHog nie potrafi zweryfikować, na przykład unieważniony albo testowy.

Potem ustaw secrets i sast jako wymagane checki; zadanie, które się nie udaje, ale nie jest wymagane, niczego nie blokuje.

Warstwa 4: security review na pull requeście

Dział zatytułowany „Warstwa 4: security review na pull requeście”

anthropics/claude-code-security-review uruchamia Claude Code na diffie pull requesta i publikuje uwagi jako komentarze review. Jego README mówi, że akcja „is not hardened against prompt injection attacks and should only be used to review trusted PRs”. Poniższy workflow, zaadaptowany z tego README, dodaje cztery zabezpieczenia: pomija pull requesty z forków, nie zostawia tokena w .git/config, usuwa konfigurację agenta z samego pull requesta, zanim wystartuje Claude Code, i jawnie ustawia model:

name: Security review
on:
  pull_request:
permissions:
  contents: read
  pull-requests: write
jobs:
  security:
    if: github.event.pull_request.head.repo.full_name == github.repository
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
          fetch-depth: 2
          persist-credentials: false
      - name: Drop the pull request's agent config so the reviewer loads none of it
        run: rm -rf .claude .mcp.json CLAUDE.md CLAUDE.local.md
      - uses: anthropics/claude-code-security-review@main # przypnij do SHA commita
        with:
          comment-pr: true
          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
          claude-model: claude-opus-5-5

Krok rm -rf jest ważny, bo akcja uruchamia CLI claude w pobranym drzewie, gdy klucz API jest w środowisku jako ANTHROPIC_API_KEY, więc hooki albo serwery MCP zacommitowane w pull requeście wykonałyby się z tym kluczem. Akcja pobiera diff z API GitHuba, więc review nadal widzi zmiany w tych plikach. Ustaw claude-model: kod akcji w razie braku używa claude-opus-4-1-20250805, a Anthropic w 2026 roku wycofał Claude Opus 4.1 z Claude API. Wybór modelu i ceny znajdziesz w hubie modeli.

Żeby bramkować na wyjściu findings-count, dodaj krok, który kończy się błędem, gdy jest większe od zera, i ustaw zadanie jako wymagane; w przeciwnym razie zostaw je doradczym. run-every-commit: true przegląda każdy push zamiast raz na pull request, drożej i, według README, z większą liczbą fałszywych alarmów. Denial of service, limity żądań, ogólna walidacja wejścia i open redirect są domyślnie pomijane; to, na czym zależy twojemu systemowi, dopisz w pliku wskazanym w custom-security-scan-instructions.

Skanuj narzędzia samego agenta przez Snyk Agent Scan

Dział zatytułowany „Skanuj narzędzia samego agenta przez Snyk Agent Scan”

Sam agent jest powierzchnią ataku. Opis narzędzia w serwerze MCP albo SKILL.md w skillu może zawierać instrukcje, których agent posłucha. Snyk Agent Scan (dawniej mcp-scan; PyPI snyk-agent-scan 0.6.4 na dzień 2026-09-26) odnajduje na maszynie harnessy agentów, serwery MCP i skille i skanuje je pod kątem prompt injection, tool poisoning i toksycznych przepływów. Wymaga tokena API Snyka i istnieje tylko w Pythonie:

Okno terminala
# Terminal, z SNYK_TOKEN wyeksportowanym z magazynu sekretów
uvx snyk-agent-scan@0.6.4 ~/.claude/skills
uvx snyk-agent-scan@0.6.4 ./vendor-skill/SKILL.md
uvx snyk-agent-scan@0.6.4 --ci

Uruchamiaj go przed instalacją skilla albo wtyczki z marketplace’u i cyklicznie na maszynach zespołu. --dangerously-run-mcp-servers pomija pytanie o zgodę dla każdego serwera i uruchamia każdy skonfigurowany serwer stdio, więc używaj tej flagi tylko tam, gdzie sprawdziłeś każde polecenie. Szerszą procedurę opisują bezpieczeństwo MCP i bezpieczeństwo skilli.

Jeśli twoja organizacja już bramkuje na SonarQube, jego oficjalny serwer MCP (obraz Dockera sonarsource/sonarqube-mcp) pozwala agentowi odczytać quality gate i naprawić nowe problemy w sesji; konfigurację dla Claude Code, Codeksa i Cursora opisuje README serwera.

Ile kontekstu kosztują narzędzia bezpieczeństwa?

Dział zatytułowany „Ile kontekstu kosztują narzędzia bezpieczeństwa?”

Wtyczka security-guidance działa jako hooki, więc nie dodaje nic do okna kontekstu, dopóki nie wróci uwaga, ale każde review na koniec tury i przy commicie kosztuje tokeny modelu. Wtyczka Semgrepa oraz serwery Snyka i SonarQube dodają definicje narzędzi MCP, które Claude Code i Codex ładują przez tool search. Mierz zamiast zgadywać: claude plugin details semgrep wypisuje komponenty wtyczki i prognozowany koszt w tokenach, a /context przed instalacją i po niej pokazuje różnicę. Pre-commit, CI i review na pull requeście nie kosztują kontekstu sesji — to kolejny powód, żeby obowiązkowe bramki stały właśnie tam.

Prompty do skopiowania dla bramek bezpieczeństwa

Dział zatytułowany „Prompty do skopiowania dla bramek bezpieczeństwa”

Jak udowodnić, że bramki bezpieczeństwa działają?

Dział zatytułowany „Jak udowodnić, że bramki bezpieczeństwa działają?”

Bramka, której nigdy nie widziałeś w akcji, to założenie. Udowodnij działanie każdej warstwy ćwiczeniem, a potem obserwuj cztery liczby.

Raz na kwartał przeprowadź ćwiczenie z kanarkiem. Na jednorazowej gałęzi każ agentowi zacommitować fałszywe dane uwierzytelniające w formacie, który wykrywają skanery, i dodać jeden znany podatny wzorzec, na przykład polecenie powłoki złożone z danych z żądania. Zapisz, która warstwa zatrzymała każde z nich. Jeśli CI zatrzymuje coś, co powinien był zatrzymać pre-commit, komuś brakuje hooka; jeśli nic tego nie zatrzymuje, znalazłeś lukę przed atakującym. Do testu w formacie prawdziwego klucza użyj klucza testowego wydanego przez dostawcę i unieważnij go po ćwiczeniu.

MetrykaDefinicjaKiedy działać
Warstwa pierwszego wykryciaDla każdego wyniku najwcześniejsza warstwa, która go złapałaWykrycia przesuwają się później (CI zamiast sesji); sprawdź, czy hooki i pre-commit są zainstalowane na każdej maszynie
Sekrety, które uciekłySekrety znalezione w historii main albo zgłoszone przez GitHub secret scanning po merge’uKażda wartość niezerowa: zrotuj, potem dodaj przeoczony format do konfiguracji Gitleaks
Dodane wyciszeniaNowe wpisy #gitleaks:allow, nosemgrep, .gitleaksignore lub .semgrepignore w miesiącuWyciszeń przybywa szybciej niż wyników; sprawdź, kto je dodał i dlaczego
Precyzja security reviewKomentarze security review, które doprowadziły do zmiany kodu, podzielone przez wszystkie opublikowane komentarzePrecyzja spada; zaostrz custom-security-scan-instructions albo plik z fałszywymi alarmami

Kto zatwierdza. Bramką zarządza CI: wymagane checki decydują, czy pull request może zostać zmerge’owany. Agent odpowiada za naprawę wyników. Wskazany w CODEOWNERS właściciel bezpieczeństwa zatwierdza każdą zmianę w .gitleaksignore, .gitleaks.toml, .semgrepignore, .pre-commit-config.yaml, plikach workflow i .claude/, bo to właśnie te pliki wyłączają bramki. Ta sama osoba czyta każdy pull request z listy eskalacji (uwierzytelnianie, płatności, dostęp do danych), niezależnie od tego, co powiedziały skanery. Lista eskalacji jest na stronie review pull requesta od agenta.

Co się psuje, gdy agenci trafiają na bramki bezpieczeństwa?

Dział zatytułowany „Co się psuje, gdy agenci trafiają na bramki bezpieczeństwa?”

Agent omija hook flagą --no-verify. Jak wyjść: guard-commit.sh w Claude Code i wymagane zadania CI wszędzie. Hook oparty na regexie łapie literówki; polecenie opakowane w skrypt przejdzie. Granicą jest CI.

Agent wycisza zamiast naprawiać przez #gitleaks:allow, nosemgrep albo linię w .gitleaksignore. Jak wyjść: CODEOWNERS na plikach z wyjątkami, metryka „dodane wyciszenia” i przebieg Gitleaks w CI z --ignore-gitleaks-allow (warstwa 3).

Sekret trafił do modelu, choć commit został zablokowany. Agent przeczytał .env jako kontekst, więc wartość jest w zapisie sesji i być może w telemetrii. Jak wyjść: zrotuj klucz, potem zablokuj agentowi odczyt plików .env* w uprawnieniach; reguły deny i opcje sandboxa opisuje strona uprawnienia i sandboxing.

Semgrep wywraca każdy pull request w starej bazie kodu, a ludzie zaczynają merge’ować z uprawnieniami admina. Jak wyjść: --baseline-commit, a zaległości spłacaj osobno.

Recenzent pull requesta wykonuje instrukcje podrzucone w diffie, na przykład komentarz, że plik jest już zatwierdzony. Jak wyjść: warunek dla forków i krok usuwający konfigurację opisane wyżej, z deterministycznymi skanerami jako wymaganymi checkami i review przez LLM jako poradą.

Review w sesji kłóci się z równoległym agentem w tym samym worktree i zgłasza jego zmiany w niewłaściwej sesji. Jak wyjść: ENABLE_STOP_REVIEW=0 albo osobny worktree dla każdego agenta, jak w uruchamianiu agentów równolegle.

Zmyślony pakiet przechodzi przez wszystkie skanery. Skanery sekretów i kodu nie sprawdzają, czy zależność istnieje i jest zaufana. Jak wyjść: bramka na diffie lockfile’a opisana w weryfikacji zależności w zmianach agentów.

Dokąd dalej z bezpieczeństwem agentów

Dział zatytułowany „Dokąd dalej z bezpieczeństwem agentów”
Porównanie botów do AI code review Warstwa review obok skanerów: Claude Code Review, codex review, Bugbot i inne.
Review pull requesta od agenta Triaż wykonywany przez człowieka i klasy eskalacji ponad bramkami.
Hooki Claude Code w automatyzacji Zdarzenia hooków, decyzje deny i testowanie hooków, zanim na nich polegasz.
Weryfikacja zależności w zmianach agentów Zmyślone i podszywające się pakiety, których nie widzą skanery sekretów i kodu.
Bezpieczeństwo MCP Weryfikacja i zawężanie uprawnień serwerów MCP, z których korzystają agenci.
Skanowanie bezpieczeństwa i testy podatności Skanowanie podatności, audyt zależności i wzorce testów penetracyjnych poza bramkami przy commicie.
Pomiar pracy z agentami Gdzie wyniki bezpieczeństwa trafiają w cotygodniowym raporcie o agentach.

Autor:

Zobacz co nowego na platformie.

Polityka prywatności Regulamin Ustawienia cookie