Lesson 03 of 5 in Module 03
⏱️ 04 Mins readPrivacy, policy, and workplace reality
IDE extensions and CLIs feel local because they run on your computer. But many features send prompts to cloud models or sign in through OAuth. That is fine when the content is generic practice. It is not fine when the content is secret.
This lesson is short on purpose: one clear rule set you can remember under stress.
What should not go into cloud tools (typical list)
Unless your employer has written approval and a data agreement, treat these as do not paste / do not index:
- Customer or client names, account numbers, private messages.
- Unreleased products, roadmaps, or financial numbers.
- Personally identifying information about staff or the public (beyond what is already public).
- Credentials: passwords, API keys, private keys—never in chat, even “just to debug.”
- Internal URLs, ticket dumps, or log files that describe production systems.
Safe practice examples: generic HTML exercises, fake “Acme Corp” copy, public tutorial snippets, your own hobby text you are happy to publish later.
Workplace reality
Many organisations have:
- An approved software list (what you may install).
- Rules for customer data (health, finance, government).
- Blocks on certain cloud regions or vendors.
Your job: if unsure, ask IT or your manager before you sign an extension into a work Google/GitHub/Anthropic account.
Gemini CLI note
Signing in with a personal Google account on a work laptop can still be a policy issue. Use work-approved accounts and machines only.
Extension and CLI hygiene (practical)
- Install from official marketplace listings and verified publishers where possible.
- Read what the extension sends (telemetry, code snippets)—use product docs.
- Revoke tokens when you leave a project or shared machine (account settings on the provider).
- Prefer separate work vs personal accounts if your employer requires it.
If you need to ask IT for permission (template)
Use plain language. Example message you can adapt:
“I am taking a short course on static HTML. The suggested tools are VS Code/Cursor extensions from GitHub/Google/Anthropic publishers and optionally Google Gemini CLI (terminal) signed in with a Google account. I will not paste client data. Does our policy allow OAuth sign-in for these tools on a work device? If not, may I use a personal device for practice files only?”
Adjust names to match what you actually install. Keep the message short—security teams appreciate clarity.
Students and side projects
If you are learning on a personal laptop, you still have a privacy job: your own address, phone, and financial details should only appear when you choose to publish them. Do not paste them into prompts “just to test” unless you intend them to be public on the final site.
Red flags (stop and ask someone)
- The tool asks you to disable security or “run as administrator” without a clear reason.
- An extension has few installs and a vague publisher name.
- A website tells you to paste an API key into a random form.
Use official docs and marketplaces only.
Example — safe vs unsafe
Unsafe: Pasting a client’s draft privacy policy into browser ChatGPT to “improve wording” without legal review and client permission.
Safer: Rewrite your own hobby “About” paragraph in generic terms, or use synthetic text for layout practice.
Corporate accounts vs personal accounts
Signing into Gemini or GitHub Copilot with a work email may put prompts under organisational controls—retention, monitoring, or allowed-model lists. Signing in with a personal account on a work machine may still violate policy. There is no universal rule except: read what your employer publishes and ask when unclear.
If you are a contractor, contracts sometimes say who owns prompts and code suggestions. When in doubt, use your own device and non-confidential practice sites until terms are clear.
Data residency (high level)
Some organisations care where data is processed (country or region). Cloud AI providers may route traffic globally. If your contract mentions data residency, assume cloud AI needs explicit approval—even if the tool is “free.”
After you leave a job
Sign out of IDE extensions and revoke tokens for work accounts on personal machines. Uninstall work-only extensions if you no longer have permission to use them. This reduces accidental cross-leakage between employers.
Practice
One scenario — write six to eight sentences
Describe a realistic work situation where browser chat might feel tempting (speed), but IDE-only practice with non-sensitive files is the correct boundary. Name one risk if confidential text leaks to a cloud model.
Second prompt — short checklist
Write five yes/no questions you will ask yourself before clicking Send in any cloud AI tool. Example shape: “Is this information already public on our website?” / “Would I put this paragraph in an email to a stranger?” If any answer feels uncomfortable, stop and get guidance.
Key takeaways
- Cloud-backed IDE AI and Gemini CLI still touch networks and accounts—they are not “offline magic.”
- Policy first, tool second.
- The next lesson gives a technical checklist; this lesson gives a human one.
When you feel rushed, slow down once for privacy—the minute you spend deciding what not to paste is cheaper than the day you spend explaining a leak. That minute is part of professional craft, not bureaucracy for its own sake.
Finally, remember Module 2: your folder layout is a form of safety. Keeping public experiments in a clearly named directory (for example practice-static-site) reduces the chance you mix play files with anything that could be mistaken for official work.