Nearly a third of employees surveyed shared work logins, keys and access credentials with AI

A developer copies an error log into an AI chat and asks it to find the cause of a failure. The log contains an active work key. It is a routine task that takes a few seconds, yet access to the system has already been handed to an external service. These are exactly the situations teams should discuss before the next urgent fix.

According to RB.RU, nearly one in three employees surveyed at Russian companies shared work logins, keys and folder access with AI systems in the past six months. The publication cites research by Kiberdom. Only 5% of respondents reported written rules for AI use at their company, while nearly one in five does not know which work data they are allowed to share with AI systems.

What the numbers say—and what they do not prove

For a founder or engineering manager, this raises a concrete question: do employees understand exactly what they are sending to AI along with their task? Someone may remember that passwords must not be shared but overlook a token in a long code snippet or an access link buried in a conversation.

Still, a headline claiming that “only 5% of companies” have rules requires caution. The description provided refers to the share of employees surveyed who reported that rules existed. It does not allow a direct calculation of the share of companies: several respondents may have worked at the same organization, and some employees may simply have been unaware of an existing policy document.

The available text also provides no sample size or composition, question wording or methodological details. The findings therefore cannot be generalized to all employees of Russian companies. Sharing a login, an active secret key and a folder link also creates different risks. The survey groups them into a single picture but does not report how many cases led to unauthorized access or a data leak.

How a secret ends up in an ordinary prompt

Imagine a hypothetical team integrating a payment service. The integration returns an error, and a developer sends the assistant a sample request, its headers and the server response. A real token remains in the authorization header. It is unnecessary for analyzing the request structure: it can be replaced with a placeholder while preserving the field names and error code.

A product manager faces a similar situation when asking AI to analyze customer inquiries. The export may contain contact details, internal links and order information. A useful first step is to put together a few anonymized examples and check whether they are sufficient for the analysis needed. Sending the entire spreadsheet simply because it is easy to attach unnecessarily increases the amount of data shared.

Sending information to an AI service does not, by itself, prove that it has been published or used to train a model. The terms depend on the specific product, plan, settings and contract. These terms need to be checked separately. A service's name alone does not establish which data the team is authorized to entrust to it.

What teams can do

Start with brief rules illustrated by clear examples. Which services are approved? Can source code be uploaded? How should customer documents be handled? Who should employees contact if a key has already been sent to a chat? The answers should be available where employees work and applicable to real tasks.

The next step is to prepare safe examples: a log without secrets, a test request with a placeholder instead of a token, and an anonymized customer inquiry. It is easier for a developer to follow a ready-made example than to determine the boundaries of acceptable use from scratch every time. Automated secret scanning can complement this process, but its results also need review.

If an active key has already been shared with an external service, the practical response is to revoke it, issue a new one and review the available usage logs. Deleting the message is no substitute for replacing the key.

For managers, the survey's main value is as a prompt to examine a specific workflow. Take a typical task the team handles with AI and look at the data sent along with it. That review will show where a clear rule, a ready-made template or a technical restriction is needed.