Quick Take: Don’t Prohibit AI—Pave Approved Pathways

If you’re short on time, here’s the gist of my position:

  • personal subscriptions work well for learning, but they aren’t automatically suitable for proprietary code
  • the phrase “not used for training” doesn’t imply “not stored”
  • secrets, production data, customer information, and regulated personal data demand explicit policies
  • agents don’t only read code; they execute commands and can be manipulated into revealing it, so keep them on a short leash
  • organizations should green-light a handful of secure tools rather than push people toward shadow workarounds
  • every proposed diff still needs a human sign-off

You know the routine: this reflects my current view as of June 2026, formed after extensive digging through vendor documentation.

And the landscape shifts quickly. Vendors tweak plans, defaults, retention policies, enterprise controls, and subprocessors—sometimes within weeks. During the writing of this series alone, three fresh models appeared (Gemini 3.5 Flash, Composer 2.5, and Opus 4.8). The next one will probably drop any day now (holding out for GPT 5.6?). Google is merging Gemini CLI and Gemini Code Assist for individual users into Antigravity CLI, while enterprise offerings stay as they are. So revisit the official pages before making any real decisions, and treat this as a hands-on field report rather than a fixed reference.

What Exactly Leaves Your Machine?

This area demanded the most digging because it’s easy to hold a firm opinion without grasping the specifics. When you fire up an AI coding agent, you may be transmitting far more than the text in the chat box.

Depending on the tool and its configuration, the provider or vendor could see:

  • your prompts
  • chosen code excerpts
  • open files and adjacent ones
  • repository search results
  • proposed diffs
  • shell commands and their output
  • stack traces
  • package IDs and dependency versions
  • file paths
  • screen captures
  • browser state
  • issue, pull request, and review text
  • telemetry on which suggestions you accept

None of this automatically means the provider trains on that material. Training is a distinct question. But AI coding is undeniably a genuine data-processing operation.

For an Angular project, that could encompass product logic, internal architecture, API names, feature toggles, business logic, test data, local logs, screenshots, and occasionally personal information.

So the core guideline is straightforward:

Never feed secrets, production data, customer details, or regulated personal data to AI tools unless your legal and technical framework explicitly permits it.

Agents have eyes on terminal output and files. If your .env files, logs, database dumps, screenshots, or test fixtures carry sensitive information, the agent may spot them too—researchers have shown that Codex, Claude Code, and Cursor scan the working directory and can access .env files that .gitignore would otherwise keep hidden.

Beyond Reading: Breach Risks and Corporate Spying

Here’s what keeps me up at night more than training data concerns. These tools aren’t passive chat interfaces. They execute commands, reach out to the network, and hook into MCP servers, plugins, and connectors. Codex advertises an OS-level sandbox with approval modes, while Claude Code offers sandboxing via bubblewrap and seatbelt. Solid engineering—but a sandbox is a barrier, not an immutable rule.

Simon Willison labels the risky combination the "lethal trifecta": a tool with access to private information, exposure to untrusted content, and a route to push data outward. A coding agent in your repository lands squarely in all three zones by default. And the fences aren’t perfect: one team demonstrated Claude Code bypassing its own denylist and turning off its sandbox, and researchers have flagged protocol-level weaknesses in MCP that open the door for prompt injection and tool poisoning.

Let me be blunt. For an enterprise Angular project, the real concern isn’t that the model picked up a generic pattern. It’s data leakage and industrial espionage: your architecture, business rules, unreleased features, and customer data winding up somewhere they shouldn’t.

Even the labs aren’t immune. In April 2026, Anthropic inadvertently leaked Claude Code’s own source code via a source-map file in an npm package—a human misconfiguration, not an assault, and no customer data was affected. But the lesson stings: if the company building the agent can accidentally expose code, your proprietary material is likewise just data on someone else’s infrastructure, governed by their policies. Throw in a prompt-injection vector—a tainted dependency, a hostile issue, a booby-trapped page the agent reads—and the same agent that sees your code can be manipulated into broadcasting it.

The answer isn’t fear. It’s threat modelling: where does my code reside, who can get at it, how long is it retained, and what can the agent be coaxed into doing? That’s why limiting the agent’s reach—command execution, network access, MCP, connectors—matters just as much as ticking the training box.

Findings From Vendor Documentation

The precise language varies depending on the vendor, plan, product, and geographic region. Treat the links provided here as a snapshot rather than permanent legal guidance. What they reveal is that teams must carefully separate the concepts of model training, data retention, product telemetry, enterprise agreements, and the actual code context an agent sees.

Consumer Versus Business Offerings

The most critical separation I encountered is between consumer and business tiers. Consumer plans generally include some data-related controls, but they require you to locate and actively enable them. Business, enterprise, and API products tend to ship with stronger privacy defaults, especially with regard to model training.

OpenAI's documentation on data usage for model improvement notes that consumer-facing products like ChatGPT and Codex may use your content for training unless you actively turn it off. It explicitly states that business products, ChatGPT Enterprise, and API access are not trained on by default. The Codex plan usage limits page repeats this stance for Codex specifically.

Anthropic's Claude Code data usage page draws an almost identical line. Users on Free, Pro, and Max plans have the option to permit data usage for model improvement. For Team, Enterprise, API, third-party platforms, and Claude Gov, Anthropic states it does not train generative models on Claude Code prompts or code under commercial terms unless the customer explicitly opts in.

Cursor's pricing page describes Privacy Mode, which when toggled on by an individual user or enforced by a team admin, prevents model providers from storing code data or using it for training. The security page elaborates that this mode is accessible to everyone, is turned on by default for team members, and is reinforced by technical measures and contractual guarantees like zero data retention with model providers. The data-use overview breaks down precisely what is stored and what is not.

Google's consumer Gemini offering tells a different story from its Google Cloud counterpart. The Gemini Apps Privacy Hub advises users to avoid entering confidential information that they would not want reviewed or used to enhance services. On the other hand, the Gemini for Google Cloud data governance docs affirm that prompts and responses are not used to train models. Furthermore, the Gemini Code Assist security docs classify coding context as Customer Data.

GitHub Copilot recently made this consumer-business divide very tangible. In March 2026, GitHub altered its default settings so that interaction data from Free, Pro, and Pro+ users can be used to train its models unless a user chooses to opt out. Business and Enterprise accounts remain excluded from this practice. Independent reporting examined the implications for regulated sectors, while the Copilot Trust Center maintains the latest details. It is the same lesson, delivered with a fresh example.

My pragmatic takeaway is this:

A personal €20 per month subscription is excellent for personal learning and experimentation, but it is not automatically suitable for handling proprietary corporate code.

Perhaps your company allows it after a formal opt-out and a review process. Perhaps not. The key is that you should not make the assumption on your own.

Lack of Training Does Not Imply Lack of Retention

Another concept that gets conflated frequently: "not used for training" is not the same as "not stored".

Providers can still hang onto your data for reasons like abuse prevention, security assurance, debugging, billing, compliance with legal mandates, or to make their product function. Some enterprise plans offer customizable retention periods, certain API tiers advertise zero data retention, and some consumer products keep your chat history unless you manually erase it or switch to a temporary mode.

For instance, Anthropic's privacy center specifies that consumer users who decline to allow data use for model improvement have their data retained for 30 days. Those who consent to it see a 5-year retention period.

OpenAI indicates that individual users can opt out of training. It also mentions that Temporary Chat will not show up in your history, will not create memories, and will not be used for training purposes, although feedback data might still be collected.

Google Cloud states that Gemini Code Assist Standard and Enterprise function as stateless Google Cloud services, meaning prompts and responses are not stored in Google Cloud unless you deliberately set up logging.

For a comprehensive corporate deployment, I would recommend asking every vendor these seemingly boring yet vital questions:

  • Is our code used for training by default?
  • Can we disable this on an organization-wide level?
  • What exactly is stored, in which location, and for what duration?
  • Is there an option to change retention policies or use zero data retention?
  • Do you support processing in the EU or other specific regions?
  • Which subprocessors are part of your chain?
  • Do human reviewers ever have access to our data?
  • How do you handle prompts, responses, diffs, screenshots, terminal outputs, and telemetry?
  • Can administrators turn off connectors, browser access, MCP servers, cloud agents, or external network calls?

If a vendor cannot provide straightforward answers to these, I would hesitate to push their tooling across a regulated company.

Regulatory and EU Angle

Given my location in Europe, the EU dimension is a primary concern. For many organizations, GDPR compliance takes center stage. But depending on the situation, you might also have to deal with works councils, vendor management procedures, data residency requirements, contractual confidentiality clauses, and the new EU AI Act.

The EU AI Act came into force in 2024 and is being phased in over time. The European Commission's implementation timeline indicates that requirements for general-purpose AI models took effect in 2025. The Commission's full enforcement powers kick in on August 2, 2026 — a deadline that is approaching quickly. For a typical Angular developer using a coding assistant, GDPR and confidentiality agreements will probably affect daily work more than the AI Act will.

In the DACH region specifically, the typical concerns revolve around data processing agreements (Auftragsverarbeitung) and ensuring data residency stays within the EU. German-language resources like this DSGVO comparison of ChatGPT, Copilot, and Gemini and this Claude Code AVV walkthrough serve as reasonable jumping-off points. However, if your company integrates AI features into its own products, deploys agents in regulated workflows, or allows AI systems to impact decisions, the AI Act becomes significantly more applicable.

For utilization of coding agents within an organization, I would advocate for a pragmatic policy that includes:

  • classifying which code repositories are permitted to be used with which AI tools
  • prohibiting the inclusion of secrets and production data in any AI context
  • mandating approved business, team, enterprise, or API agreements for any proprietary code
  • maintaining a formal record of approved vendors and their subprocessors
  • requiring human oversight and review of all generated code
  • training developers on prompt confidentiality and the permissions granted to their tools

The aim is not to create more red tape — there is plenty of that already.

The aim is to enable the safe use of AI so that developers do not feel compelled to resort to unapproved methods.

A Simple Green, Yellow, Red System

To make a policy memorable for developers, I would rely on a straightforward traffic-light model.
It may not address every legal nuance, but it is a framework that people retain.

A Simple Traffic-light Rule for Agentic Coding Tools

  • Green: learning, experimentation, and work on public or open-source projects – a personal subscription is adequate.
  • Yellow: proprietary code – acceptable, but exclusively under authorized business, team, enterprise, or API terms.
  • Red: secrets, credentials, production data, customer data, or regulated personal information – strictly forbidden from entering the AI context, without exception.

A large portion of real-world enterprise Angular work falls into the yellow zone. This is precisely why a total ban feels too heavy-handed, while a "use anything" attitude is dangerously naive.

When Policy Becomes a Blanket Ban

At this point, I think it is fair to voice a clear opinion.

I frequently encounter the sentiment, "AI is prohibited for us." Sometimes this is perfectly justifiable: if a company has skipped vendor assessments, lacks a DPA, has no data policy, has weak security, and developers are pasting confidential code into arbitrary online tools, then shutting it down is the correct call. However, trying to ban AI universally is not a viable strategy for the long term. The hidden consequence is that your organization gets slower while your rivals learn to leverage these tools in a safe manner. Ultimately, I do not consider that approach to be sustainable.

My firm belief is that professional software teams must adopt agentic coding to remain competitive. This is not because AI magically replaces talented engineers. It does not. It is because the baseline pace of software development is shifting under our feet.

If one team can handle code modernization, test creation, change review, and refactoring exploration at a faster rate, the other team cannot simply continue at their old speed without facing consequences.

This is particularly true for Angular teams. Their projects are frequently characterized by large, intricate codebases, aging RxJS patterns, inconsistent test suites, slow framework migrations, and plenty of technical debt. It is mundane but crucial modernization work. Agentic coding is a genuine asset for these tasks – as long as we maintain strict human-in-the-loop reviews and adhere to a well-defined Angular Coding Style Guide.

My stance is not to simply allow everything for everyone. It is more nuanced:

Do not issue a blanket ban. Instead, sanction a small set of safe, approved pathways and educate your team on how to use them properly.

In the long run, that is a more effective security strategy.

Drafting a Straightforward Company Policy

In drafting an initial AI coding policy for an Angular firm, I would prioritize brevity:

  1. Use only sanctioned tools (this may first require an approval process, which is a task in itself, but AI can help with that too 😏).
  2. Conduct all work on proprietary code under business, team, enterprise, or approved API agreements.
  3. Reserve personal consumer accounts for educational purposes, public code, or explicitly sanctioned use cases.
  4. Never transmit passwords, tokens, production data, customer information, or sensitive personal data in any prompt or context.
  5. Make human review of every generated code change non-negotiable.
  6. Consider AI-generated tests as helpful, but do not treat them as verification that the implementation is right.
  7. Maintain strict control over command execution, browser use, network access, MCP servers, plugins, and connectors.
  8. Monitor both cost and usage metrics as you begin the rollout.
  9. Re-evaluate the policy each quarter, as the tooling landscape shifts too fast for anything less.

This approach is not flawless, but it is preferable to the extremes of "all is banned" or "use anything you like".

My Final Assessment

For the individual developer, my advice is straightforward: go ahead and use a personal subscription for learning, experiments, work on public code, and any approved aspects of your job. But do not operate under the assumption that this same subscription is perfectly fine for proprietary corporate systems.

For organizations, I would steer clear of an immediate ban. The best starting point is the most secure option that your developers will actually adopt: one or two approved business or enterprise tools, a transparent data policy, and a well-monitored pilot program.

For anyone handling policy, resist the temptation to try and legislate for every imaginable AI use case. Instead, establish a few clear, safe pathways, invest in developer education, and schedule a policy review every quarter.

A Workshop on Agentic Engineering

This entire discussion reinforces a central theme: treat agentic coding as a coherent system, not just another tool. The model, the application, my Angular Guardrails, my Angular Coding Style Guide, the review process – and definitely the data policy – must synergize. If any one component is not aligned, the whole setup develops a leak.

If your goal is to leverage agentic coding securely with proprietary Angular code – complete with transparent data flows, meaningful guardrails, and a policy your developers will follow rather than circumvent – consider our Agentic Engineering Workshop, conducted in both English and German. This program guides advanced Angular developers from improvised, often called 'vibe', coding to structured, traceable Agentic Engineering workflows. The curriculum covers building an AI-ready project setup, implementing guardrails, moving to spec-first and plan-first methodologies, UI/UX and component prototyping, conducting code reviews, writing tests, and tackling brownfield refactoring.

Final Thoughts

Agentic coding assistants go far beyond simple conversational interfaces. They are capable of loading files, scanning codebases, reviewing patches, executing shell commands, parsing terminal output, interfacing with external services, and untangling messy conflict situations. These capabilities drive their utility—but they equally raise the stakes for security and compliance.

For solo developers, the guideline is straightforward: steer clear of sending credentials, live data, client information, or sensitive regulated records unless the environment is explicitly configured for it. For organizations, the advice is equally direct: avoid a blanket ban. Endorse a limited set of permitted workflows, spell out the guardrails precisely, and ensure the sanctioned path is more convenient than the shadow process.

The reason is simple: teams that embrace agentic tooling deliberately—safely, using approved routes rather than shortcuts—will decisively outperform those that prohibit it. The gap widens quietly at first, until a competitive slide becomes a financial one.

In the personal verdict, I connect the full narrative of the preceding series—models, setups, costs, and data handling—into the cocoon of a practical agentic development environment I would endorse.

Appreciation for reading 🙏 this content originates from Alexander Thalhammer. For thoughts, corrections, or questions, please don’t hesitate to contact me ❤️