AI coding assistants in Sweden: API keys, secrets and source code

Sweden has one of the most active tech scenes in Europe. In start-ups across Stockholm, Gothenburg and Malmö, coding assistants are already part of daily work: completion in the editor, command line agents, assistants that read a whole repository to suggest a fix.

These tools save real time. But they see everything the developer sees: configuration files, API keys, database extracts, proprietary code. For a Swedish tech company, the question is no longer whether to use them, but how to stop them carrying secrets away.

What a coding assistant really sees

A classic assistant receives the open file and a little context. A modern agent goes much further: it walks the directory tree, reads the files it thinks are relevant, runs commands and reads their output. Anything along that path can be sent to the model.

In a real repository, that often includes:

• .env files with API keys, database passwords or service tokens;

• cloud configuration files and credentials left in plain text;

• error logs containing email addresses, customer numbers or personnummer;

• the source code itself, often the company's main asset.

We cover these scenarios in our article on how CLI AI tools leak your secrets.

Secrets first: API keys and tokens

An API key sent to an external service should be treated as compromised. Even if the provider never reuses it, it ends up in logs, conversation histories or shared sessions. The only safe response is to revoke and rotate it, which takes time and can break production.

The most effective approach is to stop the key from leaving. That means recognising it the moment it is pasted into a prompt or read by an agent, not only during a repository scan after the fact.

Pre-commit hooks and repository scanning in continuous integration are still useful. But they act when code is committed, not when a developer pastes a configuration into a chat window to understand an error. That moment needs a different kind of control, placed on the workstation itself.

Source code is a trade secret

In Sweden, the Trade Secrets Act, lagen (2018:558) om företagshemligheter, transposes the 2016 EU directive. Information is only protected if its holder has taken reasonable steps to keep it secret.

For a software company, the pricing algorithm, the recommendation engine or the fraud detection code are exactly this kind of information. Letting that code flow uncontrolled into external tools weakens your position on the day you need to prove you were really protecting it.

Personal data: IMY is still in charge

Developers also handle personal data, often without thinking about it: a database export to reproduce a bug, a log with names and personnummer. If that data goes to an AI assistant, GDPR applies, and the Swedish data protection authority, Integritetsskyddsmyndigheten (IMY), has jurisdiction.

For companies covered by Sweden's new Cybersecurity Act (cybersäkerhetslagen), which transposes NIS2, controlling these flows is also part of risk management. For the public sector side, our first article on Sweden looks at municipalities, IMY and secrecy.

MCP and agents: a new surface

The Model Context Protocol (MCP) lets agents connect directly to databases, ticketing tools or repositories. It is convenient, but every connector opens a new path for sensitive data to reach the model, without the developer pasting anything.

These flows often escape traditional security tools. We explain why in our article on why MCP needs its own DLP.

A simple policy for development teams

Banning coding assistants is neither realistic nor desirable. An effective policy fits into a few clear rules:

1. List approved tools, with contracts that exclude training on your data.

2. Get secrets out of code: use a secrets manager, no keys in versioned files.

3. Use test data rather than production extracts for debugging.

4. Check at the moment of sending what goes to the models, including through agents.

5. Keep a record of incidents, to improve practices and answer audits.

How ZeusLock protects tech teams

ZeusLock runs on developers' machines and in their browsers. It recognises API keys, tokens, passwords, personal data such as personnummer, and code fragments you mark as sensitive. Depending on the rule, it warns, blocks or replaces the value with a realistic one of the same format, so the assistant can keep helping.

Every event is logged. The security team sees which tools are in use and what types of data were intercepted, without reading all of the developers' code.

For developers, everything comes down to friction. A tool that blocks everything ends up bypassed. With a plausible placeholder instead of the real key, the assistant still understands the structure of the file and can suggest a useful fix. Work carries on, and the secret stays at home.

Summary

Coding assistants have become normal work tools in Swedish tech. Yet they see keys, proprietary code and personal data. With clear rules and a check at the moment of sending, you keep the speed without losing your secrets.

Want to see how ZeusLock protects your API keys and code inside AI assistants? Book a demo.