API keys, OAuth, tokens — what NEVER to paste into ChatGPT and AI agents

Jakub Pytlik | May 15, 2026 | 8 min read

What is actually happening in 2026

Three concrete events from recent months show the scale of the problem.

February 2026: critical ChatGPT vulnerability (Check Point Research)

Check Point Research identified a hidden outbound channel in the ChatGPT runtime. A specifically crafted prompt could pull: user messages, uploaded files, sensitive content from the isolated execution environment. OpenAI confirmed the vulnerability and shipped a patch on February 20, 2026. From a user's perspective: for weeks the vulnerability was live, and hundreds of companies that uploaded files with keys or configurations during that time had no signal that their data may have been compromised.

This is not speculation — it is a documented vulnerability in the prompt injection class (a technique where specially crafted instructions hidden in inputs make the AI reveal or send out data it should not), rated as critical by Check Point.

8,000+ ChatGPT API keys publicly exposed (GitHub + production sites, Vicarius)

Vicarius in 2026 identified:

• 5,000+ public GitHub repositories with hardcoded ChatGPT API keys
• 3,000+ live production sites with keys in client-side JavaScript
• Automated scanners harvest keys in minutes after a commit — not hours

These are not pro forma ChatGPT keys. They are keys with full permissions, used to steal free LLM traffic on somebody else's money. Keys to Google Ads API, Meta Ads API, Microsoft Ads — they live in the same ecosystem and are equally vulnerable.

12,000 API keys in AI training data

Polish-language industry publications (TechSetter, ITHardware) covered an audit of the Common Crawl dataset, which is used to train modern LLMs: roughly 12,000 active API keys and passwords were found. Common Crawl indexes public web pages. If anybody ever posted a key in a public repository, on a pastebin, or on a blog — Common Crawl may have absorbed it, and the key can be part of the training data of a model.

That means: AI literally trains on data that contains other people's secrets. Despite efforts by OpenAI, Google, and Anthropic, no model can guarantee 100% that it will not "remember" a specific key in response to a clever prompt.

7 data types you NEVER paste into AI

Full explanation of each category:

1. Ad platform API keys

These are the keys that open the door to your (or your clients') ad accounts. Specifically: developer_token for Google Ads API, client_secret for OAuth, access_token and refresh_token. Plus equivalents for Meta Business API, Microsoft Advertising API, TikTok Business API.

Concrete abuse scenarios: an attacker can redirect traffic from your ads to phishing pages, run campaigns that inject fake ads into your clients' partner networks, drain budget slowly over weeks (e.g. +5% daily spend on empty clicks), or pump competitor impressions through your account. Each scenario means real financial and reputational damage.

2. OAuth refresh tokens

A refresh token is a long-lived "key to the key" — it lets you generate hourly access tokens. An attacker with your refresh token can maintain access for weeks, until you manually revoke the application in your Google / Meta account panel. Most users do not even know that this option exists.

3. Credential files in full form

Files like google-ads.yaml, service-account.json, .env, credentials.json. These files contain a complete authentication set — login, key, sometimes refresh tokens. Pasting them into ChatGPT "to help configure" means handing over the complete set on a plate.

4. Client ad account identifiers

A Google Ads customer_id alone (e.g. 123-456-7890) or a Meta ad_account_id — without keys — looks harmless. The problem appears in combination: account ID + client company name + spend values + campaign structure = a complete client profile ready for competitive analysis.

5. CRM exports and conversion data with PII

Lead lists with names, emails, phone numbers. Order exports from e-commerce with customer addresses. Newsletter subscriber lists with corporate data. These are personal data — GDPR. Pasting them into public AI is not only a business risk, it is a legal risk.

6. Internal pricing strategies and margins

Margin per category, cost structure, pricing plan for new products, ad budgets per client. This data has value only for your company and your competitors. AI has no "intent" — but data once put into the system can be used to train the next version of the model or leak through a security vulnerability.

7. Legal and contractual documents

NDAs, draft contracts, correspondence with legal counsel, documents containing confidentiality clauses. Pasting them into public AI is often a direct breach of contractual obligations, regardless of whether the data "leaks."

4 signs your credentials are compromised — plus one preventive check

Four real signals that your credentials are compromised — plus one preventive item worth checking at the same time:

1. Unusual spend on Google Ads / Meta accounts — CPC growth without a business reason, campaigns you do not remember, conversion tracking pinging from an unknown source.
2. Connected apps in Google Account (Security → Third-party apps with account access) — review the list. Disconnect anything you do not recognize.
3. API logs in Google Cloud Console (Logs Explorer) — look for queries from IPs you do not use, or at hours when you do not work.
4. Notifications of changes in Google Ads — Tools → Change history. Any change you do not remember is a signal.

Plus preventive — check at the same time:

• 2FA / two-step verification — this is not a compromise signal, but if you do not have it enabled, do it now. This is the first filter that limits the blast radius of any abuse.

"I pasted a key, what now" procedure

If you have ever pasted a key, a YAML file, a refresh token, or a client identifier — assume the data is compromised and act. Five-step procedure:

1. Revoke the key or token — two different mechanisms:
   • API keys (developer_token, Google Cloud API key): Google Cloud Console → APIs & Services → Credentials → pick the key → Delete.
   • OAuth refresh tokens (connected apps): Google Account → Security → Third-party apps with account access → find the application → Remove access. For Meta: Business Settings → Apps → Revoke.
   These are two different places and two different mechanisms — check both if you do not know exactly what you pasted.
2. Notify clients immediately if the key was tied to accounts you run for them — do this in parallel with revoking, so the client can take their own protective steps (e.g. force account-level password reset, review their own connected apps). Reporting the incident promptly is also the difference between a managed event and a discovered breach.
3. Generate a new key with restrictions: IP whitelist (if possible), application restrictions (web/Android/iOS), API restrictions (only the APIs you actually use).
4. Check the last 30–90 days of history in API logs and the Google Ads / Meta panel. Every unknown operation = proof somebody used the key.
5. Audit your processes: where else do you store keys (in a .env in a public repo? in a script comment? in an email?). Key + process configuration is foundation work, not a one-off action.

Safe patterns for working with AI

You can use AI in advertising work without pasting credentials. Four patterns I use:

Redacted prompts

Instead of: "I have refresh token X, customer_id 123-456-7890 for client Y, how do I…" write: "I have a refresh token (replaced), customer_id (replaced) for an e-commerce client, how do I…" AI does not need the specifics to give a useful answer.

Anonymized exports

Export from Google Ads to CSV → run it through a script that swaps campaign names for C1/C2/C3, customer_id for 000-000-0000, lead emails for hashes. Only then paste into AI for analysis.

Read-only MCP / agents

If you use AI agents connected to the Google Ads API, use a read-only service account with minimal permissions. (MCP — Model Context Protocol — is a standard that lets AI agents connect to external tools like the Google Ads API. "Read-only" means the agent can read data and generate recommendations, but has no way to change anything on the account.) I describe the detailed pattern in a separate article in the series about safe AI integration with an ad account.

Local LLMs for the most sensitive data

For very sensitive operations (CRM analysis, contract drafts) you can run a local model (open-source models like Llama or Mistral) on your own hardware — the data never leaves your machine. Weaker than GPT-4 / Claude and requires comfort with developer tools, so practical mainly for legal, financial, and medical agencies. In marketing you usually do not need that much — treat this as a future option.

What Google, Meta, Microsoft can do — and will not

Three realistic expectations from ad platform vendors over the next year:

• Real key restrictions — IP whitelist, app restrictions, scope limitation. Partially already in place (Google API restrictions), but poorly communicated. You have to configure it manually.
• Better audit panels — who, when, with which key, which API endpoints. Today these are raw logs in Cloud Console; what is needed are friendly dashboards with alerts.
• Forced token rotation — refresh tokens auto-expiring after N days. This is standard in banking and healthcare; in advertising — still an exception.

What they probably will not do quickly: fully block sending keys to AI. That is technically not feasible from the platform side. The responsibility for credential security is on you — and that will not change in 2027 or 2028.

About the sources: Check Point Research — ChatGPT vulnerability of February 2026; Vicarius — 8,000+ ChatGPT API keys publicly exposed; Cyble — the rising risk of exposed keys; Polish-language publications TechSetter and SecurityBezTabu on Common Crawl and keys in AI training data. Plus observations from accounts run by JP Ads — where a recent audit of applications connected to client accounts systematically found 3–5 unknown tokens per account. Numbers from my own practice are marked as "I observe" or "in audits" — distinguish them from hard security research data.