Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Jeremy Brown, CTO at GitGuardian, on AI, NonHuman Identities, and the Governance Gap in 2026

AI isn’t creating new security problems, it’s exposing existing ones at scale. GitGuardian saw 24M secrets leaked on public GitHub last year (+25%), and private repos are far more likely to contain secrets because people get careless when they feel safe. AI also enables more non-developers to ship apps without security training and generates oversized PRs that can’t be realistically reviewed, increasing leak risk. Attackers increasingly don’t “hack”, they use leaked credentials to log in and blend in like normal users, making traditional incident response less effective.

Secrets in the Machine: Preventing Sensitive Data Leaks Through LLM APIs

In this webinar, we break down a simple but increasingly common problem: secrets leak wherever text flows, and modern LLM apps and agentic workflows are built to move text fast. We walk through concrete demos showing how API keys and passwords can surface through RAG-based assistants when secrets accidentally live in knowledge bases (tickets, docs, internal wikis). We also show why “just harden the system prompt” isn’t a reliable fix, and how output-only redaction can be bypassed (for example by simple formatting/encoding tricks). Most importantly, we explore real-world agent architectures.

Honeytokens with ggshield: plant tripwires that alert on secret use

In this video, we introduce ggshield honeytoken and why it’s one of the most powerful tools in the GitGuardian toolbox. A honeytoken is a decoy secret that alerts you the moment someone tries to use it or validate it. Think of it like a digital tripwire. In GitGuardian, honeytokens can be created through the dashboard or API, and they look like real AWS keys because they are valid credentials. The difference is they grant zero access and are isolated to an AWS account GitGuardian maintains specifically for this purpose.

Has My Secret Leaked (HMSL) with ggshield: check public GitHub exposure safely

Since 2018, GitGuardian has been scanning for secrets added to GitHub public repositories. When a secret is found, GitGuardian hashes it and stores only a fingerprint of the secret. That fingerprint is what you can search against to verify whether any of your secrets have leaked in public repositories, gists, or issues on GitHub. This service is called Has My Secret Leaked, and in ggshield you’ll see it as the HMSL commands. There’s also a web interface, but in this section we stay in the terminal and use ggshield end to end.

Ignore false positives safely with ggshield secret ignore

In this section, we cover what to do when ggshield finds something you don’t actually need to remediate, like a false positive, an intentionally fake credential in a demo repo, or a known non-sensitive test value. ggshield secret ignore lets you mark specific findings as ignored by adding them to the secrets.ignored_matches section of your local configuration. If your repo doesn’t already have a local config file, ggshield will create a.gitguardian.yaml file for you.

Stop secrets before they leave your laptop (Git hooks + ggshield install)

Let's look at Git hooks, which is where ggshield really starts paying off in day-to-day developer workflow. Git hooks are built-in automation in Git. When certain events happen, like committing or pushing, Git checks for specific files inside the.git/hooks folder. If a hook file exists, Git runs it automatically. For example, if there’s a file named pre-commit, Git will execute it every time you commit.