Everyone talks about giving AI agents more access. Almost nobody talks about what the agent does with what it finds on the way.

Here’s the thing — an agent doesn’t have to be hacked to leak your secrets. It only has to be helpful. Ask it to debug a deploy and it prints your environment. Ask it why a login fails and it opens the file where the credentials live. Ask it to write up what it found and the token it found lands in the commit message. Nobody attacked anything. The agent did exactly what it was asked.

The reality is that most teams treat this as a trade. More access, or more safety. Pick one. That’s a false choice. An agent that can’t touch anything isn’t safe — it’s useless. And an agent that touches everything unchecked is a leak waiting for a bad afternoon.

The answer isn’t less access — it’s a layer that watches what moves. That’s what the Guards are, and this month they went open source. Let me explain what they do, why we opened them, and what happened when one of them got it wrong.

What the Guards do

They sit between the agent and your secrets and hold one rule: no secrets.

  • They redact secrets in tool output before the model reads it.
  • They stop an agent from reading credential files — by name and by what’s inside.
  • They block a credential from being published, whether in a commit, a pull request, an issue or a comment.
  • They check outbound commands that would send credential material to a remote host.

They also flag possible personal data and prompt injection in what the agent reads. Those two are best-effort notices, and we say so every time. The hard rule is no secrets. Everything past it is a judgment call.

Two pieces ship together: guards-unified, a server that does the detection, and claude-plugin-guards, a Claude Code plugin that wires it into a session.

Why open

A lock you can’t inspect is a promise, not a lock.

Just think about it — a tool sits between your agent and your secrets, and the only evidence that it works is the vendor’s word. That isn’t security. That’s faith. A tool in that position doesn’t get to ask for belief — it has to earn it, and the only way to earn it is to let you check.

So the code is readable. Every release since v0.2.10 ships with signed build provenance, a software bill of materials and a full vulnerability scan, and the verification guide shows how to confirm that what you pull is what we built.

And the misses are written down. A limits page, a trade-offs page and a threat model. A bare, high-entropy value with no key name or prefix next to it? Nothing detects it. Indirect prompt injection — hostile text in a web page or a file telling the agent what to do? Mostly not detected. You should read that before you rely on a tool, not after.

When one of them got it wrong

Here’s what surprised me most about running this in the open. In October our own scanner was missing things. In older releases, about one scan in 155 could hand back text with a secret still in it. No error. No warning.

It wasn’t failing — it was scanning nothing. The tool we use to find secrets decides a file is an archive from the file’s name, and when it does, it skips the contents. About one random temporary name in 155 happened to look like an archive. Ten of 1,600 scans left a fabricated token in the output. After the fix, none of 1,600 did.

We published an advisory that says which versions to update and what to treat as suspect. The bottom line: a tool you can inspect can be wrong in public — and that is exactly why you can trust it more the next time.

Where the Guards fit

The Guards are a protection layer, not a policy engine. They tell you the truth about what your agents touch, and they hold the line on secrets. What to do about a finding past that line is the call of whichever platform adopts them.

grāmatr, our AI platform, is one of those. Any other platform can be. Additive, not zero-sum: the Guards work on their own, and they work alongside whatever you already run.

Try it, and tell us what breaks

In Claude Code:

/plugin install guards --marketplace gramatr/claude-plugin-guards

You also need Docker, jq, curl and uv, plus a Hugging Face token whose account has accepted the prompt-injection model’s licence. Without that token the service doesn’t start, and personal-data detection goes with it — secret detection keeps working through a local fallback. The plugin README lists everything you need and what survives without each piece.

Questions go in Discussions. Bugs and ideas go in issues. For changes to the code, propose first — code is reviewed only for changes agreed beforehand, and the contributing guide explains how. If you find a security problem, report it privately through the repository’s Security tab or at [email protected].

The bottom line: an agent is only as safe as what it can leak, and you shouldn’t have to take our word for it.