Shadow AI: the AI use the company never authorised

// 00

Nobody at Vercel bought the tool

the thesis of this edition

In April 2026, Vercel published a security bulletin saying that an outsider had got into its internal systems and read environment variables belonging to a subset of its customers. In the sentence on the origin, Vercel wrote "The incident originated with a compromise of Context.ai, a third-party AI tool used by a Vercel employee."

Context.ai, in its own statement, added the detail that matters. "Vercel is not a Context customer." An employee had signed up for a consumer AI product using their corporate Google Workspace account and, according to Context, accepted every permission the tool asked for. When Context was breached, the authorisation that employee had given became the way into Vercel.

The company was opened by a click on "allow", in a tool that never went through procurement or security.

This is a case of shadow AI, the name the market gives to AI used at work without the company having approved it. It is the person who gets the report done in ChatGPT on a personal account, installs an extension that summarises meetings or hooks an assistant up to their corporate email, because it is quicker than asking IT. The intention is almost always good. The company simply does not know it exists, and so it decides nothing about what passes through it.

Shadow AI comes in through two doors. The first is what the person pastes into the chat, such as code, a spreadsheet or meeting minutes. The second is what they connect to the company's accounts, such as a browser extension, an app that asks for access to email and drive, an agent that starts acting on their behalf. The first door is the one the public debate knows, the one that shows up in internal policy and in training. Almost nobody inventories the second, and that is the door the Vercel case came through.

This edition gives both the same weight. No source I read measures which of them causes more damage, and I will not claim it. With primary sources, something else can be shown. The second door is granted with less ceremony, stays open for longer and almost never makes it onto the list of whoever looks after security.

The most recent figure on the subject comes from IBM's annual study of data breaches, published on 29 July 2026. Among the 602 organisations studied, all with a confirmed breach in the period, the share of incidents involving shadow AI rose from 20% to 43% in one year. In the 2026 report, IBM describes shadow AI as the case "where workers use unapproved AI". IBM itself changed the way it describes that denominator from one edition to the next, so I quote the figure the way it wrote it. Reading it as "43% of companies" would be wrong.

// 01

What shadow AI is, and what connecting means

without this, the rest of the edition makes no sense

The name comes from shadow IT, which is what we called, fifteen years ago, the spreadsheet in a personal Dropbox and the system bought on a manager's credit card.

The difference is that the spreadsheet in Dropbox just sat there. An AI tool reads, writes and, more and more, does things on behalf of whoever connected it. That changes what "using an unapproved tool" means.

The first door, what gets pasted

This is the form everyone already pictures. The person opens an AI chat, pastes in a piece of code, a customer spreadsheet or a meeting transcript, and asks for help. The content leaves the company and goes to a vendor's server.

What defines the risk of this door is the account's contract. The same tool, with the same screen, runs under two different contracts, and the person picks which one applies at the moment they sign up. The table below summarises what the OpenAI and Anthropic pages say.

Sources: OpenAI, training and privacy pages (30.04.2026) and statement on the NYT case (05.06.2025, updated 22.10.2025); Anthropic, consumer terms (28.08.2025), privacy policy (in force since 08.07.2026) and commercial terms.

Paying does not change this. Plus, Pro and Max are consumer plans. And even the commercial contract comes in degrees. OpenAI's Team, now called ChatGPT Business, is a business plan and does not train on content by default, but it fell under the preservation order in the New York Times case, which left out only Enterprise, Edu and the API with zero retention.

The second door, what gets connected

Through this door, what the person hands over is access to the accounts. Almost every modern AI tool offers "sign in with Google" or "sign in with Microsoft". Along with the login comes a second screen, listing what the tool wants to do. Read your emails, send emails on your behalf, see and edit your files, access your calendar. The person clicks allow, and the tool now has ongoing access to those accounts.

In the previous edition I explained the token as a badge that has no photo, does not expire on its own and is already the authorisation. That badge had been issued to an official integration, installed by the company. Here it is the same badge, and the one who signs off on issuing it is the employee, alone, in thirty seconds, with the corporate account.

The analogy I use is the power of attorney. The permissions screen is a power of attorney you sign for someone you have just met. It gives them the power to act on your behalf, it stays valid when you close the browser, it stays valid when you forget you signed it, and it is kept in the files of whoever received it. If those files are stolen, whoever holds the paper acts as if they were you.

Two variations of the second door

• The browser extension is an even broader power of attorney. Once installed, it can read what appears on every page the person opens, including the corporate AI chat, the CRM and email. It does not need OAuth for that. It only needs someone to click "add".
• The agent is the power of attorney that works on its own. When a developer connects an MCP server to their coding assistant, or a manager hooks an agent up to their inbox, whatever is connected has the same permissions as the assistant, and none of them shows up in an asset inventory.

// 02

The path of the power of attorney

the mechanism, step by step

The two doors follow different paths, and the points where you can intercept sit in different places.

The top track has one point where what goes out can be intercepted, which is the person's machine, at the moment of sending. The bottom track has two, and both sit outside the machine. One is the setting that defines whether the person can sign the power of attorney alone. The other is the list of what has already been signed.

What most surprises administrators is the factory default. In Google Workspace, the option that controls unconfigured third-party apps comes set to "Allow users to access any third-party apps (default)". At Microsoft, the default changed in 2025. Entra ID switched to a policy managed by Microsoft itself, which applies to new tenants and to those that had never touched the setting. Under it, users can consent on their own to almost everything except reading email, calendar, chat and all files, which now require an administrator. Anyone who had previously chosen to let users consent to any app stays that way. At Google, unless someone has changed the setting, any employee can grant an AI tool the access the Vercel case showed. At Microsoft, the vendor itself has already closed part of that door, and the question becomes whether your tenant ended up with the new default or with an old choice.

Microsoft adds a detail that holds for both worlds. Changing the consent setting "only affect[s] future consent operations". What has already been granted stays valid until someone revokes it.

// 03

Seven cases, two doors

each one for what it actually was

The cases below were chosen because they have a primary source. Each one carries its type, because a real compromise, a coordinated disclosure, a proof of concept and an operational failure are different things, and I insist on not mixing them.

The second door, what gets connected

The first door, what gets pasted

// 04

How it happened on the inside

the Vercel case, with the time each company published

I picture the scene like this, and it is my imagination. Someone needs a presentation for tomorrow, finds a tool that builds it with agents, clicks "sign in with Google" and, on the next screen, "allow all", because it is the button that lets them carry on. Thirty seconds.

Two companies published, and each tells the part it saw. The times below are the ones they recorded themselves, in Pacific time, and dates without a time are as the sources give them.

Two details I would not let slide

The first is the sentence in which Vercel describes Context. "A small, third-party AI tool whose Google Workspace OAuth app was the subject of a broader compromise, potentially affecting its hundreds of users across many organizations." Hundreds of users, across many organisations. Vercel was the one that found out and published. From the sources, there is no way to know how many of the others know, even today, that they had someone connected to Context.

The second is the path the warning took. Context detected and stopped the intrusion in March. It knew it had been breached, hired forensics and notified the customer it identified. But it only learned that tokens from users of the consumer product had been used against Vercel "based on information provided by Vercel". Context warned those who were customers. Vercel was not one, and only entered the story because it found out on its own.

Sources: Vercel, Vercel April 2026 security incident, bulletin of 19.04.2026 updated through 24.04.2026; Context, Security Incident Response Statement, 19.04.2026, updated on 21.04.2026, offline since May 2026 and read in an archived copy.

// 05

What was taken is bigger than it looks

one person's access reached the credentials of many companies

Vercel says that "non-sensitive" environment variables were read, and that sounds small. But Vercel itself, in its recommendations, describes what usually lives in them. "API keys, tokens, database credentials, signing keys." These are the credentials Vercel's customers use so that their applications can talk to databases, to payment providers, to other services.

It is the same chain as in the previous edition, from a different starting point. A token led to an account, the account led to an environment, and the environment held other people's tokens. What began as a power of attorney signed by one person ended in the credentials of companies that had never heard of Context.

The access that remains after the use ends

Material Security published a report in June 2026 on OAuth authorisations in corporate Google Workspace environments. The sample is small and the publisher sells the solution, but the numbers give the size of the residue.

Material Security, The Access You Forgot You Granted, 23.06.2026. 21 Google Workspace environments belonging to the vendor's own customers, and the vendor sells the solution. Read it as an order of magnitude.

On the first group, Material writes that "in every one of these cases, the OAuth authorization is still intact".

Under Brazilian law, the company is answerable

The guide from the ANPD, Brazil's data protection authority, on processing agents is explicit. Employees are neither controllers nor processors, because they "act under the directive authority of the processing agent", and the company "assumes responsibility for the acts performed by its agents and representatives". When an employee connects a tool the company never contracted to the email account that holds customer data, the processing is the company's.

Here comes a reading of my own, one the ANPD has never made. Resolution CD/ANPD No. 19/2024 defines transfer as the operation by which an agent "transmits, shares or makes available access to personal data to another processing agent". An OAuth authorisation given to a vendor abroad is, in the most literal form possible, making access available. No document from the National Data Protection Authority has applied this definition to AI tools used by employees, and I would hear a lawyer before treating it as settled.

Recognition of the problem already appears in a document from the agency itself. The ANPD's Radar Tecnológico No. 3, on generative AI, which presents itself as a technical study and not as an institutional position, writes that shifting responsibility to the user "does not seem to be sufficient". The text deals with prompts and attachments. Connectors and agents do not yet appear in any Brazilian primary source I have found.

// 06

Nobody noticed on their own

the uncomfortable part

Vercel has a security team, publishes timestamped bulletins and worked with Mandiant on the investigation. I do not think it was careless. The second door is hard to see for four reasons that add up.

1. Consent goes past nobody. The tool was not bought, so it never went through procurement, legal or vendor assessment. Context was not a Vercel vendor.
2. The access looks legitimate. Whoever uses the stolen token presents a valid authorisation, granted by the account owner. No wrong-password or login-from-another-country alarm goes off. The second factor protects the moment of login, and here the login had happened earlier, on the day of sign-up.
3. Notification follows the contract. When a vendor is breached, it notifies its customers. An employee using a consumer account is not a business customer, and their company is on no list at all. In the Vercel case the sequence ran the other way, and it was the victim that notified the vendor.
4. The first door has a name, the second does not. Among the organisations IBM studied in 2026 that had some AI governance policy, only 29% run regular audits looking for unsanctioned AI, against 34% the year before. The requirement for IT approval to deploy AI fell from 45% to 38%.

Okta's May 2026 survey points the same way. Among workers who use AI, 52% said they had used some tool without IT approval, and only 6% gave not knowing they needed approval as the reason. The reasons cited most were others. Using their own account was easier (80%), the team already used it (78%), approval was too slow (57%).

// 07

The pattern that repeats

putting the three editions together

Side by side, the three editions show a sequence I have not seen anyone write down.

1. 01

   The instruction

   who handed it overthe agent's owner, by connecting tools to it

   the attacker usedan instruction written where the agent would read it

   what holdswell-maintained conventional controls and an architecture that separates instruction from data
2. 02

   The vendor's badge

   who handed it overthe company, by installing a vendor's integration

   the attacker usedthe integration's token, stolen from the vendor

   what holdsIP restriction and minimum scope on the connected app
3. 03

   The badge handed out by the employee

   who handed it overone employee, alone, on the permissions screen

   the attacker usedthe token of a vendor the company never hired

   what holdstaking away the employee's power to authorise alone

What the third edition adds is where the authority comes from. In the first two, someone in the company decided to connect the agent, whether a product team or a CRM administrator. Here the decision was one person's, alone, and the company only learned of it after the incident.

This takes apart a common defence

In almost every company I know, the answer to shadow AI is a written policy and a list of approved tools. Those two things cover the first door, where the act is visible and the person knows they are sending something. At the second, the act looks harmless. The screen says "sign in with Google", the person signs in, and the power of attorney comes with it.

In 2025 the Google Threat Intelligence Group documented a campaign, attributed to UNC6040, in which employees were talked by phone into authorising "a malicious connected app" in Salesforce. GTIG's conclusion holds here too, swapping the platform's name. "In all observed cases, attackers relied on manipulating end users, not exploiting any vulnerability inherent to Salesforce." That was social engineering. At Vercel, from what both companies describe, nobody had to talk anybody into anything, and the employee signed up on their own.

// 08

The question nobody could answer

and what third-party numbers say about it

When Vercel published the identifier of the Context app, it asked every Google Workspace administrator to check "for usage of this app immediately". To meet that request in minutes, a company needs to be able to answer three things. Which AI tools have delegated access to the company's accounts today. Who granted each one, and when. With what scope.

Push itself warns that the number of grants is higher, because it counts each product only once. "The total number of individual consent grants across users is larger."

And the first door is still open. The same Verizon report says 67% of users access AI services with non-corporate accounts on company devices, and that the type of data most often sent to external models, across a base of 858,440 data loss prevention events, was source code.

// 09

What holds

sorted by level of assurance, across both doors

It is worth separating what prevents the act from what only limits the damage afterwards.

Taking away the employee's power to sign alone

In Google Workspace, under Security, Access and data control, API controls, the setting for unconfigured third-party apps can move from "Allow users to access any third-party apps" to "Allow users to access third-party apps that only request basic info needed for Sign in with Google" or to "Don't allow users to access any third-party apps". At Microsoft, in Entra ID, Enterprise applications, Consent and permissions, user consent can be switched off, limited to apps from verified publishers and low-impact permissions, or left on the Microsoft-managed policy, which already blocks email, calendar and files. Both platforms have a flow for the employee to request approval of an app they cannot authorise alone, and it is that flow that turns an individual power of attorney into a company decision.

With that setting active, the employee's sign-up to Context would have stopped at the permissions screen, or would have become an approval request. This is my inference. Neither company says how Vercel's tenant was configured.

Restricting high-risk services

Google Workspace lets you mark Gmail and Drive as restricted services. The documentation says that, when you do, "any previously installed apps that you haven't trusted stop working and tokens are revoked". It is the only control on this list that also cleans up the past.

Extension allowlist

Chrome and Edge can, through enterprise policy, block every extension that is not on an approved list. It is an identifier comparison, which assesses neither intent nor behaviour.

Classification on the machine, before sending

For the first door, the strongest control is the one that looks at the text at the moment it is about to leave, with a deterministic rule (ID numbers with check digits, key patterns, entropy), and masks or blocks it before it reaches the vendor.

Business account instead of consumer account

Offering the tool people already use, under a business contract, swaps the training and retention clause without changing the screen the person sees. In Okta's survey, 80% of those who used AI without approval said it was because using their own account was easier.

Variables marked as secret

The environment variables Vercel says were decrypted were the ones not marked as sensitive. In its bulletin, Vercel itself recommended using the feature, so that values "are protected from being read in the future". Since August 2026 the option is called Secret, and variables marked as sensitive have moved to that type.

Periodic review of the list of apps with access

The Google console lists the "accessed apps", the third-party applications that have already accessed company data, with the scopes each one requested. Entra has the review of permissions granted to enterprise applications. The information exists in both. What is usually missing is someone with a set date to open the list.

Revocation when the employee leaves

Material states that the standard suspension of an account "does not revoke third-party OAuth grants". Google's documentation says otherwise, that suspending "resets the user's sign-in cookies and OAuth tokens", and other vendors say the authorisations come back if the account is reactivated. I have not tested which holds in practice. Either way, the offboarding checklist should include revoking grants, and almost none does.

Alert on a new grant with broad scope

An unknown app receiving full access to someone's Gmail is an event worth an alert. A badly calibrated rule turns into noise nobody reads.

Written policy and a list of approved tools

In Okta's survey, only 6% of those who used AI without approval cited not knowing they needed approval. Not knowing the rule barely shows up among the reasons, and the written policy did not change the act.

Banning it

Samsung restricted generative AI on company devices and networks in May 2023. Banning it on the corporate network does not reach the personal phone or the personal account, and pushes use to where the company sees even less. Here I am giving an opinion, with no data to back it.

Multi-factor authentication

It protects the login. The power of attorney is issued after the login and works without it.

Awareness training

It teaches people to recognise phishing. From what the sources describe, the Vercel employee was not deceived by anyone and simply signed up to a tool.

// 10

Checklist for decision-makers

ordered from highest to lowest return

This week

1. Open the list of third-party apps with access in the Google Workspace console and in Entra ID, and look for the OAuth app identifier Vercel published. If the list does not exist ready-made, or nobody knows where it is, that is the most important finding of the exercise.
2. Check the user consent setting in both environments. In Google, the factory default lets anyone sign the power of attorney. At Microsoft, check whether the tenant is on the Microsoft-managed policy or on an old choice that allows everything.
3. Mark as secret every environment variable and every secret the platform allows.

This quarter

1. Switch consent to prior approval, with a request flow that answers in days, not weeks. In Okta's survey, 57% of those who used AI without approval blamed the slowness of the process. If approval takes longer than the shortcut, the shortcut wins.
2. Offer, under a business contract, the tool people already use on their own. The list of which ones they are is, for the most part, in the apps with access you opened this week.
3. Put revocation of OAuth grants into the offboarding checklist.
4. Adopt an extension allowlist in the corporate browser, starting with the teams that handle customer data.
5. Put local classification before sending on the machines that access personal data, for the first door.

In the contract

1. With an AI vendor, require in writing the commitment not to train on the company's content and the retention period, as they appear in the OpenAI and Anthropic business terms.
2. Require incident notification that also reaches your company's users on accounts linked to your domain, not only the contracting account. OpenAI and Anthropic already provide for linking, or informing the organisation of, accounts created with a corporate email. Ask for that to apply to incidents too.
3. For every approved app, ask for the list of scopes and the justification for each one before authorising.

// 11

Where we differ from what circulates

seven corrections, each with the source that supports it

// 12

What I did not verify

stated, so it does not look as if I know more than I do

• The exact scopes the Vercel employee granted to Context. Neither company published the list.
• When the employee signed up, and when the token was used against Vercel. The sources give the month in which Context detected the breach and the publication dates, not the date of use.
• How the Context breach began. There are reports of an infostealer and of a Chrome extension, and none of them is in the companies' statements.
• The name of the fake tool in the Disney case and the password manager involved. The plea agreement names neither, and nor does the US Department of Justice press release, going by the reproductions I found (the site was blocked). I did not read the sentence.
• Whether Samsung's code was ever used in training. Nobody has shown it, and OpenAI has not commented on the case.
• What happens to OAuth authorisations when a Google Workspace account is suspended. Material says they persist, and Google's documentation says the tokens are reset. I did not test it.
• A Brazilian shadow AI case with data exposure. I searched the courts, the ANPD (Brazil's data protection authority) and company statements, and found none. That does not mean one does not exist.

// 13

What this would require operationally

from here on I talk about what we do at Jump

Three questions came up along the way in this edition, and none of them is about Vercel.

1. What leaves through your machines, and under which contract, when someone pastes client data into an AI chat.
2. How many AI tools have delegated access to your company's accounts today, and who authorised each one.
3. Whether an employee can, on their own, give a tool full access to corporate email.

If you answered all three without needing to ask anyone, skip this section. It will not add anything for you.

If you did not, this is what we deal with at Jump. From here on I talk about our product, separating what exists today from what is on the plan.

Every level 1 control in section 09 already exists, in the Google console, in Entra ID and in browser policy. What a company lacks is someone who knows, before the incident, which powers of attorney were signed, by whom, and what each one can do today.

What RADAR·AI does today

answers 01 Endpoint layer, at the first door. A browser extension and an agent on the machine classify the text right there, with deterministic rules (Brazilian ID numbers such as CPF, CNPJ and CNH, and card numbers, checked by their check digit, secrets by pattern and entropy), and mask or block the submission according to policy, before it leaves. Without verification, nothing leaves. The content does not leave the machine; only the event goes up, with the data type, the rule and the action.

answers 02 Discovery and an inventory with owners. 29 connectors read only metadata across code, cloud, data, AI providers and identity. Whatever shows up goes into an inventory with an owner and a risk level, and a system without an owner goes in as critical. In the identity connectors (Okta, Entra ID and AWS IAM), the platform reads the AI apps registered with the identity provider and the permissions they inherit.

answers 02 Reporting for the board and the regulator, generated from the recorded state, with exportable evidence and no number typed in by hand.

answers 03 Exceptions with an expiry date. Whoever requests an exception does not decide on it, and every exception expires. It is the approval flow from section 09 applied to what the policy blocked.

What is on the plan, stated as a plan

Three items on the product plan answer what this case exposes, and I name them by the names they have there.

The limit, said out loud

// 14

Primary sources

all read directly; no third-party summary was used as a source

• Vercel · Vercel April 2026 security incident · 19.04.2026, updated through 24.04.2026
  vercel.com · vercel.com/changelog
  The origin at Context, the path to the environment variables, the OAuth app identifier, the timing of the updates and the recommendations. The changelog records the replacement of "Sensitive" by the Secret type.
• Context · Security Incident Response Statement · 19.04.2026, updated 21.04.2026
  web.archive.org (offline at context.ai since May 2026; archived copy of 21.04.2026)
  The consumer product, the AWS intrusion in March, the "allow all", the sentence "Vercel is not a Context customer" and the stated purpose of the permissions.
• IBM and Ponemon Institute · Cost of a Data Breach Report 2026 · 29.07.2026; and Cost of a Data Breach Report 2025 · 30.07.2025
  ibm.com
  The 43% of incidents involving shadow AI, the decline in prior approval and in audits, the definition of shadow AI, and the origin of the 2025 figures that circulate in distorted form.
• Google · Control which apps access Google Workspace data; Control which third-party & internal apps access Google Workspace data; Identify and secure compromised accounts · read on 03.10.2026
  support.google.com · support.google.com · support.google.com
  The default setting for third-party apps, the restriction options, the list of apps that have already accessed data, token revocation when services are restricted, and what account suspension does to tokens.
• Microsoft · Configure how users consent to applications; Manage app consent policies · read on 03.10.2026
  learn.microsoft.com · learn.microsoft.com
  The Microsoft-managed policy as the default and the permissions it blocks, the restriction options, the approval workflow and the fact that the change does not reach what has already been granted.
• Verizon · 2026 Data Breach Investigations Report · 2026
  verizon.com
  Unauthorised AI extensions on more than 15% of users, 67% of access through non-corporate accounts, and source code as the data most often sent to external models.
• Push Security · Shadow AI: what Push data reveals about the scale of the problem · 28.05.2026
  pushsecurity.com
  The 17 AI apps with OAuth access in the average organisation, and the caveat that it counts products, not grants.
• Material Security · The Access You Forgot You Granted: Material's OAuth Risk Report · 23.06.2026
  material.security
  Access that persists after use, across 21 Google Workspace environments, and the claim about account suspension.
• LayerX · Enterprise GenAI Security Report 2025 · 02.2025
  layerxsecurity.com
  AI-enabled extensions on 20.63% of users, 58% of them with high or critical permissions.
• Okta · AI Agents at Work 2026: Securing the agentic enterprise · 27.05.2026
  okta.com
  The 52% of AI users who use it without approval, the 6% who did not know the rule, and the reasons given.
• OpenAI · How your data is used to improve model performance; Privacy policy, 30.04.2026; How we're responding to The New York Times' data demands, 05.06.2025, updated 22.10.2025
  help.openai.com · openai.com
  Training on consumer and business accounts, Team (now Business) as a business plan, linking the account to a corporate email address, the scope of the preservation order and its end on 26.09.2025.
• Anthropic · Updates to Consumer Terms and Privacy Policy, 28.08.2025; Privacy Policy, in force since 08.07.2026; Commercial Terms of Service
  anthropic.com · anthropic.com/legal
  Training on consumer accounts, the prohibition in the commercial terms and linking the account to a corporate email address.
• US District Court for the Central District of California · United States v. Ryan Mitchell Kramer, plea agreement · 01.05.2025
  courtlistener.com
  The Disney case: the fake AI tool, the work credentials and the 1.1 TB from Slack.
• Koi Security · First Malicious MCP in the Wild, 25.09.2025; 8 Million Users' AI Conversations Sold for Profit by "Privacy" Extensions, 15.12.2025
  web.archive.org · web.archive.org
  The postmark-mcp package and the Urban VPN extensions. Published on koi.ai, which now redirects to Palo Alto Networks, Koi's acquirer; read in archived copies.
• Postmark · Information Regarding Malicious "postmark-mcp" Package · 25.09.2025
  postmarkapp.com
  The vendor's confirmation that the package was not theirs.
• Radware · ShadowLeak · 18.09.2025
  radware.com
  The demonstration with ChatGPT connected to Gmail.
• Invariant Labs · GitHub MCP Exploited: Accessing private repositories via MCP · 26.05.2025
  invariantlabs.ai
  The proof of concept with private repositories and the authors' statement about the server code.
• Google Threat Intelligence Group · The Cost of a Call: From Voice Phishing to Data Extortion · 04.06.2025, updated 08.08.2025
  cloud.google.com
  UNC6040 and the employees persuaded to authorise a connected app.
• Economist Korea · exclusive report on ChatGPT use at Samsung · 30.03.2023
  economist.co.kr
  The origin of the Samsung case: the three incidents, the go-ahead in the semiconductor division and the conditional memo.
• Wiz Research · Wiz Research Uncovers Exposed DeepSeek Database Leaking Sensitive Information · 29.01.2025
  wiz.io
  The exposed database, what it contained and the coordinated disclosure.
• ANPD · Guia de agentes de tratamento e do encarregado (versão 2); Resolução CD/ANPD nº 19, 23.08.2024; Radar Tecnológico nº 3, 11.2024
  gov.br/anpd
  The company's responsibility, the definition of transfer and the acknowledgement of the problem in a technical study by the agency, Brazil's data protection authority.
• Microsoft and LinkedIn · 2024 Work Trend Index Annual Report · 08.05.2024
  microsoft.com
  The 78% of AI users using tools not provided by their company, and the exact survey question.
• Cyberhaven · 11% of data employees paste into ChatGPT is confidential · 28.02.2023, later updated
  cyberhaven.com
  The origin of the figure that circulates in distorted form.
• Gartner · Gartner Identifies Critical GenAI Blind Spots That CIOs Must Urgently Address · 19.11.2025
  gartner.com
  The 2030 prediction and the measured figure that accompanies it.