# Gemini Code Assist security: what to check before you migrate Google has ended new subscriptions. Existing teams need a clear account of data, permissions, and the transition ahead. agentlist.iosecurityUpdated Oct 12, 20268 min read Gemini Code Assist security now starts with a lifecycle question. [Google stopped selling new Standard and Enterprise subscriptions on October 9, 2026](https://docs.cloud.google.com/gemini/docs/codeassist/sunset). Existing subscriptions remain supported through their contractual term. If you are considering a new purchase, evaluate the proposed successor and its terms; do not treat an old Code Assist privacy summary as approval for another product. For an existing deployment, the practical review covers what code is sent, what is retained, who can access it, and what the agent can execute. A statement about model training answers only one of those questions. ## Identify the account and transition dates Google’s [consumer-account notice](https://developers.google.com/gemini-code-assist/docs/deprecations/code-assist-individuals) says the individual, Google AI Pro, and Google AI Ultra Code Assist tiers stopped serving requests on June 18, 2026, and points users toward Antigravity. Standard and Enterprise follow a separate schedule: additional licenses and annual renewals are available until January 31, 2027; monthly renewals continue until December 31, 2027. Inventory the extension, account, subscription, Cloud project, and contract end date actually used by each developer. An organization can have approved paid seats and an unreviewed personal setup on the same team. Make the migration owner explicit before an engineer changes products just to restore access. ## Separate training, storage, and access | Question | Documented boundary | Team check | | --- | --- | --- | | Does Google train on our prompts? | Google says prompts and responses are not used for training without permission | Review any opt-in or preview terms separately | | Is only my typed prompt sent? | Context can include open and adjacent files and cursor position | Inspect context and use a sanitized repository for the first review | | Are prompts retained? | The service is described as stateless; optional logging can retain inputs and responses | Check logging configuration, readers, retention, and exports | | Must processing stay in a region? | The security documentation does not guarantee regional processing | Do not infer residency from the Cloud project location | These boundaries come from [Google’s Code Assist security and privacy documentation](https://docs.cloud.google.com/gemini/docs/codeassist/security-privacy-compliance) for Standard and Enterprise. They do not establish that every connected tool, plugin, or successor product has the same policy. ## Review repository indexing separately [Enterprise code customization](https://docs.cloud.google.com/gemini/docs/codeassist/code-customization-overview) indexes private repositories to inform suggestions. That is a different data flow from a stateless prompt request. Review the repositories selected, who can use the index, and what happens when access is revoked. Google documents file exclusions with `.aiexclude`; check the scope of the exclusion you configure rather than assuming it governs all tools. Create a harmless canary file containing an invented identifier. Exclude it, then verify the documented indexing and context behavior without putting a real secret in the experiment. If you cannot establish the boundary, keep sensitive repositories out of the rollout until you can. ## Review actions as well as data Run the first task with a disposable branch, a test account, and no production write credentials. A model’s data policy does not limit the authority of a shell command or a connected service. List every integration that can read files, send messages, access a database, or publish a change. 1. Give the agent a small change with a known failing check and a clear acceptance condition. 2. Include an action that should need approval. Confirm it stops before execution. 3. Inspect the patch and the commands that ran. Verify the result independently. 4. Revoke a test integration and confirm the agent can no longer use it. 5. Record which checks could not be verified. Do not turn an unanswered question into a passing score. ## Build a data-flow record you can inspect Take a single ordinary task, such as changing a validation rule, and follow its inputs. Record which files supply context, which account sends the request, where any private-code index lives, which logs are enabled, and which connected tools receive arguments. Give each row an owner. A policy paragraph cannot tell you whether a developer has also attached an unapproved tool. | Boundary | Evidence to retain | Decision if unresolved | | --- | --- | --- | | Account and edition | Assigned seat, organization, project, and contract end date | Keep the rollout limited to identified accounts | | Prompt and response logs | Actual logging settings, retention period, readers, and export destinations | Keep sensitive inputs out until storage and access are understood | | Private repository index | Included repositories, exclusions, and a harmless access-revocation test | Do not add another repository to the index | | Shell and connected tools | Installed tools, their credentials, and the observed approval behavior | Use read-only or test credentials for the unresolved integration | | Replacement product | Its own terms, data-flow record, and task results | Keep approval separate from the old product’s approval | Use invented customer records and a synthetic secret marker for the first pass. Check the context shown by the tool and any logs your administrators can inspect. An agent failing to repeat a marker does not prove that the marker was never transmitted or indexed. Combine observations with the product’s documented controls; label transmission or deletion behavior as unverified when you cannot observe it. Google’s [security documentation](https://docs.cloud.google.com/gemini/docs/codeassist/security-privacy-compliance) is a starting point for the service boundary. Your review also needs the configuration your team actually uses. For instance, “no training without permission” does not answer who can read an exported log, and an access restriction on one repository does not establish the permissions of a separate tool server. ## Rehearse the migration with one repository Choose a repository with ordinary code and a working acceptance suite. Run one bug fix and one code-understanding task with the currently approved configuration. Save the accepted changes, incorrect answers, review time, and any missing evidence. Then repeat from the same starting commit using the proposed replacement, with its own permission and data settings recorded. Include a deliberate interruption: revoke a test integration or remove repository access during the trial. Confirm how the replacement reports the loss of access and whether the operator can recover without granting broader permissions. This tests the operating procedure your team will need when an employee leaves or an integration is compromised. Keep a fallback the team can actually use: an ordinary editor, local build instructions, and a human owner for blocked work. Migrate the next repository only after someone other than the person who configured the pilot can reproduce the checks. That makes the evidence reusable instead of leaving the company dependent on one person’s successful demo. ## Make the migration review portable Keep a one-page record: owner, product and edition, approved repositories, excluded data, logging and retention settings, tool permissions, contract dates, and unresolved questions. When evaluating Antigravity or another replacement, rerun those checks against its current documentation. Product continuity is not evidence of identical data handling. Our [agent permissions guide](https://www.agentlist.io/learn/guides/set-agent-permissions) helps define the access boundary, and the [coding-agent trial scorecard](https://www.agentlist.io/articles/coding-agent-trial-scorecard) separates successful output from the work needed to verify it. Approve a specific configuration for a specific class of tasks, then revisit it when either changes. Agentlist editorial review. Sources checked October 12, 2026. This is a documentation-based buying guide, not a hands-on performance benchmark. Trial procedures and recommendations are our analysis. ## Write down the access boundary. Keep the fieldbook’s permissions and evaluation exercises beside your next coding-agent trial. [Get the permissions fieldbook](https://www.agentlist.io/ebook?from=gemini-code-assist-security) --- Source: [Gemini Code Assist security: what to check before you migrate | agentlist.io](https://www.agentlist.io/articles/gemini-code-assist-security). This is the public page rendered as Markdown; interactive controls require the website.