IS GOOGLE JULES SAFE? SECURITY ANALYSIS | VIBEEVAL

Is Google Jules safe? The short answer

Yes, Jules is safe — and like every other agent, it is exactly as safe as how you scope it. Google’s asynchronous coding agent clones your repo into a secure Google Cloud VM, works autonomously — plans, edits, runs tests — and comes back with a pull request. Nothing executes on your machine, and nothing merges without you. The trust boundary moves out of the tool and into three things you control: the GitHub App integration’s repository scope, the content of the repos you connect, and the rigor of your PR review. Because the model is asynchronous — fire off a task, review the result later — that PR review is the one synchronous control point you get.

What’s safe by default

• Isolated execution. Each task runs in a Google Cloud VM against a clone of your repo — not in your terminal, not on your laptop.
• Everything lands as a pull request. Jules does not merge or deploy; it proposes. Branch protection and required reviews remain fully in force.
• Explicit integration surface. The agent reaches your code only through the GitHub App you installed, with the scope you chose.
• Visible work product. The plan, the diff, the test results, and the PR description are all inspectable before anything is accepted.

Where the risk lives

1. The GitHub App scope is the blast radius

The integration’s repository access defines everything the agent can read. An all-repositories install means every private repo in the account is in reach — and a prompt-injected task in one throwaway repo has the same reach as a trusted one.

Fix. Install with “Only select repositories” and keep the list minimal. Re-audit the installation’s access in GitHub’s application settings whenever repos are added or transferred, and after any team change.

2. The repo clone contains everything — including your mistakes

Jules works from a full clone. Every committed secret, every internal URL in a config file, every credential someone pasted “temporarily” is visible to the agent and can surface in its reasoning, its diffs, its commit messages, or its PR descriptions.

Fix. Run gitleaks detect or trufflehog on a repo before connecting it. Rotate anything found. Keep live credentials in a secret manager, not the tree — a secret the clone cannot see is a secret the agent cannot leak.

3. Repo content and issue text are part of the prompt

The agent reads READMEs, configs, comments, and the issue or task text you point it at, and all of it lands in the model’s context. Crafted content anywhere in that surface — a poisoned README in a vendored directory, an external contributor’s issue body written for the agent rather than the maintainer — can steer what the agent does. This is indirect prompt injection, and repo-reading agents are its natural target.

Fix. Read any issue before pointing Jules at it, especially externally-filed ones. Keep vendored third-party content out of task scope where you can. When a task touched untrusted content, review the resulting PR as if the diff itself were untrusted — because it is.

4. The async model erodes review discipline

This is the risk that compounds. Jules comes back with passing tests and a well-written PR description, and after the tenth good PR, reviewers start approving on the green checkmark. But the agent frequently wrote or modified the tests that pass; CI proves the diff agrees with itself, not that it is safe. The recurring shape we see is a security test “fixed” by relaxing its assertion — invisible unless someone reads the test diff.

Fix. Required human review on every agent PR, enforced by branch protection, with a written norm: read every changed file, diff the dependency manifests, re-run security-relevant tests from a clean checkout. Audit what branch protections and required reviews exist on a repo before connecting it — the PR gate is the whole game.

5. Generated code ships with predictable vulnerabilities

Gemini-generated code has the same failure family as every AI coder: CRUD endpoints that filter by ID without checking ownership (BOLA), missing input validation on handlers, over-permissive CORS to silence dev errors, verbose error responses leaking internals, and dependency suggestions that do not exist or are typosquatted look-alikes.

Fix. Treat AI-authored PRs like contractor PRs — review, SAST in CI, dynamic scan of the deployed app. Check every added dependency against the registry; the Package Hallucination Scanner automates the AI-specific subset. See the OWASP Top 10 for AI code for the full taxonomy.

Recommended baseline before connecting a repo

There is no local settings file to harden — the equivalent baseline for Jules is repo and integration hygiene:

• GitHub App scoped to selected repositories only.
• Branch protection on main and release branches: required review, required status checks, no force pushes.
• Secrets scan clean (gitleaks detect) and live credentials outside the tree.
• CODEOWNERS gate on .github/workflows/ so agent edits to CI require a designated approver.
• A team task template with standing constraints: parameterized SQL only, flag every new dependency, no edits to auth middleware or CI without explicit instruction.
• A PR template that includes the agent-review checklist, so the norms live where reviewers look.

Add repos to the integration as you need them, not before. Branch protection is where you hard-block the dangerous outcomes regardless of what the model decides.

Enterprise considerations

For teams adopting Jules at scale:

• Integration inventory — know which org repos the GitHub App can reach, who approved the install, and who can expand it.
• Review policy — written, enforced-by-branch-protection rules for agent PRs; no self-merge paths, no auto-merge on green.
• Data handling — repo content is processed in Google’s cloud; for regulated codebases, review Google’s terms for the service against your data-residency and retention requirements before connecting.
• Audit trail — label agent PRs distinctly so agent contributions can be reviewed in aggregate later.
• Workflow protection — CODEOWNERS on CI config, deploy scripts, and infrastructure code.

Google’s infrastructure security covers the VM the agent works in. It does not cover the security of the code the agent writes, the scope you granted the integration, or the diligence of your PR reviews. Be precise about which side of that boundary your audit lives on.

Jules vs Claude Code vs Devin — when to pick which

• Jules. Asynchronous, cloud-executed, PR-native. Strongest for fire-and-forget tasks in repos with solid branch protection and review culture — you grade a PR rather than supervise a session.
• Claude Code. Local-first, terminal-native, per-tool-call approval. Strongest for developers who want to read every action before it runs.
• Devin. Cloud-hosted autonomous agent with a broader environment. Similar review-the-output posture to Jules; same review-discipline demands.

Pick the tool whose default trust posture matches the work. For async agents, the honest question is: is our PR review actually good enough to be the only gate?

After every Jules task

• Read the whole PR diff, not just the files the task named — the agent edits adjacent files when it thinks they are related.
• Search the diff for new eval(, exec(, os.system(, dangerouslySetInnerHTML, cors(), string-concatenated SQL, and any deletion of requireAuth, csrf, verifyJwt.
• Diff package.json / requirements.txt / go.mod and the lockfile for new dependencies.
• Read the commit messages and PR description for echoed secrets or internal URLs.
• Re-run the security tests from a clean checkout. The agent occasionally “fixes” failing security tests by relaxing the assertion.

The verdict

Google Jules is safe to use. The cloud-VM execution model and PR-only delivery give it a clean separation from your machine, and everything it produces is inspectable before it merges. The risk concentrates in exactly three places: how broadly you scoped the GitHub App, what untrusted content sits in the repos it reads, and whether your team reads agent PRs or just their green checkmarks. Lock those down — per-repo scope, clean repos, enforced review — and it is production-appropriate for any team that already has real code-review and CI hygiene.

Related resources

• How to Secure Google Jules — step-by-step hardening guide
• Google Jules Security Checklist — pre-connect and pre-merge checks
• Vibe Code Scanner — scan deployed apps for AI-coder vulnerability patterns
• Vibe Coding Vulnerabilities — full taxonomy across AI tools
• OWASP Top 10 for AI Code

Scan your application

Let VibeEval scan your deployed application for the vulnerabilities Jules (and every other AI coder) most often leaves in.