GOOGLE JULES SECURITY CHECKLIST

Jules is an asynchronous agent — you file a task, it clones your repo into a Google Cloud VM, works unsupervised, and comes back with a pull request. That model makes the security posture different from a terminal agent you watch in real time: there is no per-command approval, no session to interrupt. Everything hinges on two things — what the GitHub App integration can reach, and how seriously you review the PR that comes back. The checklist below is what we look for first when we audit a repo with active Jules use.

Treat Critical as blocking (or “before you connect a production repo”). High is week-one. Medium is the cleanup once Jules is part of your team’s flow.

How to use this checklist

Walk it on a representative repo that Jules has access to, then fold the per-PR items into your review template. The integration-scope and branch-protection items only need to be set once per repo; the review items apply to every agent PR.

Critical (fix before connecting)

1. Scope the GitHub App to selected repositories only

Why it matters. The Jules GitHub App integration is the agent’s entire reach into your code. An all-repositories grant means every private repo in the account is readable by the agent — and by extension, exposed to anything that manages to steer the agent through injected content.

How to check. In GitHub, review the app installation under your account or org settings → Applications. Confirm repository access is “Only select repositories” and the list is exactly the repos you intend.

How to fix. Switch to per-repo access and prune the list. Re-audit whenever someone on the team adds a repo “just to try something.”

2. Confirm branch protections and required reviews exist

Why it matters. An agent that opens PRs against a repo with no branch protection is one distracted click from shipping unreviewed code to main. The async model means nobody watched the work happen; the PR gate is the only gate.

How to check. For each connected repo, check main (and any release branches) for: required pull-request reviews, required status checks, force-push disabled, direct pushes disabled.

How to fix. Enable branch protection with at least one required human review before connecting the repo. Do this first — it is the backstop for every other item on this list.

3. Scrub committed secrets before the first task

Why it matters. Jules clones the full repo into its VM. Every secret in the working tree — the .env someone committed once, the API key in an old config — is visible to the agent, can end up referenced in its reasoning, and can propagate into diffs, commit messages, and PR descriptions.

How to check. Run gitleaks detect or trufflehog git file://. across the repo, including history.

How to fix. Rotate anything found, purge it from history if practical, and move live credentials out of the repo entirely. A secret the clone cannot see is a secret the agent cannot leak.

4. Treat repo content and issue text as untrusted input

Why it matters. The agent reads READMEs, config files, comments, and the issue or task text you point it at. All of it lands in the model’s context — which means a crafted README in a vendored directory or a poisoned issue body can carry instructions the agent may follow. This is indirect prompt injection, and repo-reading agents are its natural target.

How to check. Before pointing Jules at an issue filed by an outside contributor, read the issue body as if it were a prompt. Before connecting a repo with vendored third-party content, skim that content for imperative instructions aimed at an agent.

How to fix. Only hand the agent tasks and issues you have read. Keep vendored dependencies out of scope where possible. Review agent PRs with extra suspicion when the task touched externally-authored content.

5. Never merge an agent PR on green CI alone

Why it matters. Jules runs tests in its VM and opens the PR when they pass — which trains reviewers to rubber-stamp. But the agent that wrote the code often wrote or modified the tests; green CI proves internal consistency, not correctness or safety. The recurring shape we see is a “fixed” failing security test where the fix was relaxing the assertion.

How to check. Sample recent merged agent PRs: was every changed file actually reviewed, or just the summary and the checks tab?

How to fix. Required human review on every agent PR, with an explicit reviewer norm: read the full diff, diff the dependency manifests, and re-run security-relevant tests from a clean checkout.

6. Audit every dependency the agent adds

Why it matters. AI agents suggest packages that do not exist, or almost-right names that a typosquatter has registered. A hallucinated dependency in a merged PR is remote code execution at install time.

How to check. In each PR, diff package.json / requirements.txt / go.mod. For each new entry: does the package exist, is it the canonical name, does it have real history and maintenance?

How to fix. Make dependency-diff review a required PR step. The Package Hallucination Scanner automates the AI-specific check; a lockfile plus npm audit covers the rest.

High (fix in the first week)

7. Constrain tasks in writing

The task prompt is the only steering input before code exists. Ship a team task template that includes standing constraints: parameterized SQL only, no new dependencies without flagging, no edits to CI workflows or auth middleware. An underspecified brief produces underspecified security.

8. Review the plan before the agent runs with it

Jules plans before it edits. Reading the plan is the cheapest point to catch scope creep — “also refactor the auth module” — before any code exists. Reject and re-scope at plan time, not at PR time.

9. Keep agent PRs off auto-deploying branches

Point tasks at feature branches. Never let an agent PR target a branch where merge triggers a production deploy without a human in between.

10. Read the agent’s commit messages and PR description

Jules writes these from what it saw in the clone. Check them for echoed secrets, internal URLs, and environment details — especially before they land in a public repo’s permanent history.

11. Test authorization on every route the PR adds

Unauthenticated request, wrong-user authenticated request, correct-user request — for every new endpoint. Agent-generated CRUD routinely filters by ID without checking ownership; see BOLA in AI-generated CRUD.

12. Re-check the GitHub App scope after team changes

App installations outlive intentions. When repos are added, archived, or transferred, re-audit which ones the integration can reach. Quarterly at minimum.

Medium (fix when you can)

13. Add CI checks that fail on agent-introduced dangerous patterns

Lints that fail the build on eval(, exec(, os.system(, subprocess.call(shell=True, dangerouslySetInnerHTML, string-concatenated SQL, and cors() with no args catch the most common agent regressions before review even starts.

14. Protect CI workflow files from agent edits

Use a CODEOWNERS rule requiring a designated human approval for changes under .github/workflows/. An agent PR that edits the pipeline that validates agent PRs deserves a second set of eyes by construction.

15. Label agent PRs distinctly

A jules label or a PR-title convention makes it possible to audit agent contributions later — and keeps reviewers in the right frame of mind when they open the diff.

16. Keep a lockfile and commit it

Lockfiles pin exactly what installs. An agent-added dependency range without a lockfile can resolve to something different in CI than it did in the agent’s VM.

17. Periodically diff agent-touched security surfaces

Once a month, review the cumulative diff of agent PRs against auth middleware, session handling, and input validation. Individually-reasonable edits accumulate into drift.

18. Document the review norms where reviewers will see them

Put the agent-PR review checklist in the PR template itself. Norms that live in a wiki do not survive contact with a Friday afternoon.

After every Jules PR

• Read the whole diff — the agent edits adjacent files when it thinks they are related.
• Diff the dependency manifests and lockfile.
• Search the diff for hardcoded keys (grep -E 'sk_|sk-proj-|eyJ' -r . on the branch).
• Re-run security tests from a clean checkout; check that no assertion was relaxed.
• Read the commit messages and PR description for leaked internals.

Common attack patterns we see in Jules-connected repos

The all-repos install. The app was installed org-wide “to save time.” A prompt-injected task in one low-stakes repo now has read access to every private repo in the org’s context.

The green-checkmark merge. Reviewer sees passing CI and an articulate PR description, merges without reading the diff. The diff relaxed a security test assertion to make it pass.

The poisoned issue. An external contributor files a plausible bug report whose body includes instructions aimed at the agent. The maintainer points Jules at the issue; the resulting PR includes an unrelated “cleanup” that weakens input validation.

The hallucinated package. The PR adds a dependency whose name is one character off the canonical package. It exists on the registry — because someone squatted it.

Related Resources

How to Secure Google Jules

Step-by-step guide for hardening a Jules workflow — integration scope, branch protections, task constraints, and the PR review discipline that the async model demands.

Is Google Jules Safe?

In-depth analysis of the agent’s security model — what runs in the VM, what the integration can reach, where the trust boundaries actually are.

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 app Jules helped build, attempts the most common agent-introduced regressions, and reports what got through — with file and line numbers to fix.