SOURCEGRAPH CODY SECURITY CHECKLIST

Cody’s defining feature is its context model: it pulls relevant code from across your Sourcegraph-indexed repos and feeds it to the LLM. That’s the strength and the security risk — the wider the context, the more chance that secrets, internal URLs, or unreleased code from a different repo end up in a prompt and, in some configurations, in provider transcripts. The checklist below is what we look for first when we audit a Cody-using engineering org.

Treat Critical as launch-blocking. High is week-one. Medium is the cleanup once Cody is part of your team’s flow.

How to use this checklist

Walk it once at the org / Sourcegraph instance level, then make the relevant items part of your developer onboarding. The Cody-specific items are mostly about scope — what Cody can see, what it can send, and what it should never touch.

Critical (fix before launch)

1. Audit Cody’s context-fetching scope

Why it matters. Cody Enterprise pulls context from any indexed repo the user has access to. Combined with cross-repo embeddings, a developer asking about “how do we authenticate users” can pull code from auth services in repos they have read-but-not-write access to — and that code, including any secrets it contains, ends up in the prompt sent to the LLM.

How to check. Run a representative Cody chat session and inspect the context it pulled. Confirm it’s only from repos the user should be able to surface code from. Check the embeddings configuration for repos that should not be indexed.

How to fix. Restrict Cody embeddings to repos that are safe for cross-repo context. Exclude security-sensitive repos (secrets, infra, customer-data ingestion) from embeddings entirely.

2. Strip secrets from indexed repos before enabling embeddings

Why it matters. Embeddings index every line of code in the repos you allowlist. Secrets in those repos — committed for any reason, in any branch — become part of the context Cody can serve up. Even cleaning the secrets later doesn’t remove them from the embeddings index until you re-index.

How to check. Run gitleaks detect and trufflehog filesystem against every repo you’ve indexed for embeddings. Audit the embeddings index status; confirm re-index has happened since any secret cleanup.

How to fix. Rotate any secret that ever lived in an indexed repo. Re-index after cleanup. Add gitleaks to the pre-commit flow on every indexed repo.

3. Review Cody-generated auth code for missing checks

Why it matters. Cody, like other assistants, scaffolds auth that “looks right” but skips checks specific to your codebase’s patterns. The risk is amplified by Cody’s cross-repo awareness — if your org has one auth service that does it correctly and twelve that don’t, Cody might pattern-match on the twelve.

How to check. Diff Cody-generated auth code against your reference auth service. Confirm token verification, session handling, and authz checks match the reference.

How to fix. Document your “canonical” auth pattern in a CONTRIBUTING.md that Cody can read. Add CI lints that compare new auth code against the reference.

4. Verify enterprise Cody is scoped to allowed repos only

Why it matters. A misconfigured Sourcegraph instance can grant Cody access to repos that should be off-limits — typically because a permissions sync broke or because a repo was added without explicit scoping. Once it’s in the index, every Cody user can pull from it.

How to check. In Sourcegraph admin, audit the repos visible to Cody. Cross-reference against your “Cody allowed” list. Investigate any unexpected repos.

How to fix. Restrict Cody scope explicitly. Audit on a schedule, not just when you think to.

5. Disable Cody for customer-data repos unless contract allows

Why it matters. Repos that contain customer data (database dumps in fixtures, redacted production logs, support tickets) need explicit contractual coverage before any LLM sees them. Default Cody Enterprise settings may send context to model providers in ways that violate your DPA.

How to check. List every repo with customer data. Cross-reference against your model provider DPAs. Confirm those repos are excluded from Cody embeddings and Cody chat context.

How to fix. Use Cody’s per-repo policy to exclude customer-data repos. If your contract requires it, run Cody fully air-gapped (Sourcegraph self-hosted with a self-hosted model).

6. Confirm Cody’s chat does not echo source-code secrets to other users

Why it matters. Shared chat threads — especially in team contexts — can include excerpts Cody pulled from indexed code. If those excerpts contain secrets, every chat participant now sees them.

How to check. Audit recent shared Cody chats. Search transcripts for sk_, eyJ, Bearer , and connection-string patterns.

How to fix. Train developers to delete or redact shared chats containing sensitive context. Rotate anything found.

High (fix in the first week)

7. Pin Cody model version in production

Cody can switch between models (Anthropic, OpenAI, self-hosted). Pin a specific model in instance settings so behavior is reproducible and any model change is intentional.

8. Require PR review on Cody-authored changes

Even with Cody’s better-than-average context, the reviewer sees a diff, not the context. Require human review on every PR with substantial Cody contribution, especially in auth/payment/crypto paths.

9. Audit dependency adds introduced via Cody

Cody will suggest new packages to solve small problems. Audit package.json / requirements.txt / go.mod diffs on every PR. Ban transitive dependencies you don’t recognize.

10. Configure Cody’s “ignore” list for sensitive paths

.cody/ignore (and equivalent) keeps files out of context. Use it on infra/, secrets/, customer-data fixtures, and anything covered by a DPA.

11. Verify Sourcegraph permissions sync is current

Cody respects Sourcegraph repo permissions, which mirror your code host (GitHub, GitLab, Bitbucket). If the sync is stale, Cody may grant access to repos a user lost access to weeks ago. Run the sync on a schedule.

12. Audit Cody’s outbound traffic

Cody Enterprise sends context to model providers. Confirm the destination matches what you expect (your contracted provider, not a default). Network monitoring is the backstop.

Medium (fix when you can)

13. Document Cody usage policy for the team

A short policy document covers: which repos are Cody-allowed, which models are approved, what data must never go into prompts, and how to report a leak.

14. Disable Cody telemetry on sensitive projects

Cody sends usage telemetry to Sourcegraph. For sensitive deployments, disable telemetry or self-host so telemetry stays internal.

15. Re-test security after Cody refactors

Cody refactors that span repos can have wide blast radius. Run security tests after each.

16. Pin the Cody client version

Cody’s IDE plugins evolve. Pin versions in your team’s onboarding setup so behavior is consistent.

17. Audit who can change Cody admin settings

Sourcegraph admins can change Cody scope, models, and policies. Restrict admin access; require change approval.

18. Set up alerting on Cody usage anomalies

Cody usage spikes correlate with incidents (developer trying to ship a fix at 2am) or with credential abuse (someone exfiltrating via Cody chat). Alert on outliers.

After every Cody-heavy session

• Read the diff in full — Cody’s context-rich suggestions can pull patterns from unexpected places.
• Search the diff for hardcoded secrets and string-concatenated SQL.
• Re-run security tests separately.
• Audit for new cross-repo dependencies that snuck in.
• Confirm no Cody chat contained or echoed secrets.

Common attack patterns we see in Cody-using orgs

The cross-repo secret leak. Developer asks Cody to “show me how we connect to the database”. Cody pulls a db.ts from a sister repo that has the production connection string hardcoded (committed years ago, never rotated). String now in chat history and provider transcripts.

The pattern-matched insecure auth. Cody scaffolds auth based on what’s already in the repo. The repo had one bad auth example (forgotten test code); Cody propagates the pattern across new services.

The scope-creep PR. Cody-assisted refactor “improves consistency” by pulling patterns from a different service — including its insecure SQL. PR is large, reviewer skims, regression ships.

The stale permissions sync. Developer leaves the team but their Cody session keeps working for hours. They pull internal source via chat before access is revoked.

Related Resources

How to Secure Sourcegraph Cody

Step-by-step guide for hardening Cody at the instance level — embeddings scope, model selection, permissions sync, and the per-repo policy patterns above in long form.

Is Sourcegraph Cody Safe?

In-depth analysis of Cody’s data flow — what context it pulls, what leaves your network, and what the practical failure modes look like at enterprise scale.

Automate Your Checklist

A checklist tells you what to look for. A scanner tells you what’s actually broken in the deployed app right now. VibeEval drives a real browser through the deployed result of Cody-assisted work, attempts the missing-auth and SQL-injection attacks above, and reports what got through.