At Greptile, we help our customers review and test pull requests with the full context of the codebase. That means we hold access to their private code and, through integrations, to their Jira, Confluence, and Linear workspaces. If someone gets our secrets, they can get into our customers' code too. That's why every secret we use lives in Infisical.
Why an AI code review company is a hard place to manage secrets
We have two kinds of users with different needs: our review agents and our engineers.
Our review agents call our customers' services while reading and running code we didn't write. Any of it can carry a prompt injection, and an agent holding a real credential could be tricked into giving it up.
Our engineers had a more ordinary problem: keeping secrets in sync. Before our Series A, secrets moved around through one-time shares, .env handoffs, 1Password and a few other tools. That stopped working as the team grew. Someone would rename a variable, and a teammate's local setup would quietly fail. (Our original case study with Infisical goes into this.)
We wanted one store for every secret, with a way for agents to use credentials without ever holding them.
What Infisical does
Infisical is an open source secrets management platform that teams can run themselves. We give each developer, machine, and AI agent its own scoped identity in Infisical, so we can grant access narrowly and revoke it just as easily.
Before choosing Infisical, we considered AWS Secrets Manager, 1Password and Bitwarden. AWS Secrets Manager would have tied us to one cloud, and we need to run on our own stack and on others like GCP. 1Password and Bitwarden are built for people copying values out of a vault; we needed services to pull them without a person in the loop. Infisical solves both problems. It's open source, so we can host it anywhere, and it's built around environments and machine identities.
We run a monorepo, with cloud services on AWS (ECS) and the frontend on Vercel. Infisical holds our application secrets for development, staging and production, and there's no other secrets store behind it. Our services pull credentials from the right environment when they start, so nobody maintains .env files by hand. It also backs machine identities in production and feeds our CI checks in GitHub Actions. Engineers sign in with SSO.
Not every agent should see everything
We give each of our own agents an Infisical role that can read only the variables it needs, the same way we'd limit who can read sensitive code.
While scoping limits the damage, even one leaked token is enough to cause trouble. Infisical's Agent Vault docs show how simple the attack can be: a routine-looking bug report with a fake "verification" step that asks the agent to send its GitHub token to an outside server. If the agent holds the token, it can leak in a single request.
Our review agents never hold the customer's credential at all. When one calls Linear, Jira or Confluence, it holds a placeholder. The Agent Vault proxy checks the agent's session, attaches the authorization header, and forwards the request. If a prompt injection tricks the agent into sending its token somewhere, all it can leak is the placeholder.
The integration also fails closed. If Agent Vault is down, we disable the tool rather than hand the agent the original token.
One store for shared and personal secrets
Every engineer needs a local setup that works. Most values are shared across the team, but some, like a local database, are personal. We use Infisical's Personal Overrides to handle this.
Each of our engineers overrides their own GitHub App, Hatchet, LLM and local database credentials. The shared values the rest of the team relies on stay untouched, and onboarding and local config still live in one place.
We rotate a credential when it may have been exposed, or when we replace a provider's API key. We update the value in Infisical, and our production services and GitHub deployment workflow pick it up on their next restart or deploy. Nobody chases down separate copies.
Where this fits with AI agents
Agents now read tickets and open pull requests on their own, and each of those calls needs a credential. Every agent holding one is another place for it to leak.
Infisical's team has a line we agree with: "An agent's output and an agent's access should be checked by something that isn't the agent." Greptile checks the output by reviewing what coding agents write before it merges. On the access side, Infisical is why our review agents can use customer credentials without ever holding them.
Infisical also runs on Greptile. It has reviewed more than 2,800 pull requests in their main repository, which they wrote up in How Infisical Uses Greptile for AI Code Review.