Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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.

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.

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.

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.

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.

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.

Next up is ggshield secret scan ci, the mode built for continuous integration, not your local machine. In this section, we’ll show how CI scanning works and why it’s different. Instead of scanning your whole repo, it scans the set of commits that triggered your pipeline, whether that build came from a direct push or a pull request. That means you catch secrets at the exact moment they’re introduced, before they get merged or released.

Now we’re getting to the heart of ggshield: secret scanning. In this section, we jump into ggshield secret and its two subcommands, ignore and scan. Ignore makes a lot more sense once you’ve seen scan in action, so we start by learning what ggshield can scan and why it’s so flexible across the development lifecycle. We’ll open the help menu so you can see every scan target available: ggshield secret scan -h.