Where your API keys actually live, and who can see them

A contractor left six months ago. His Google account still runs your invoicing.

We see this exact situation more often than any other, and it never starts as a security problem. It starts as a convenience. Someone needs an automation that sends invoices by email, so they build it, authorize the connection with their own Google login because that is what is in front of them, and ship it. The thing works. Everyone moves on. Nobody writes down that a business-critical process now depends on one specific person's account.

Then that person leaves. If you are lucky, IT disables their account cleanly on the last day, your invoices silently stop going out a week later, and you spend an afternoon figuring out why a process you forgot existed has died. If you are unlucky, IT does not fully disable the account, because "something is still attached to it," and now you have a live access credential belonging to someone who no longer works for you.

This article is about the part of no-code automation almost nobody manages on purpose: the keys, tokens, and connections your workflows run on. Where they actually live, who can see them, and what happens when one walks out the door. It is not a glamorous topic. It is the one that should keep you up at night, and in most companies nobody has ever looked at it systematically.

Why no-code hides your secrets so well

In traditional software, credential handling is a more or less solved problem. There are environment variables, secret managers, a clean separation between code and configuration. Developers know that an API key in source code is a mistake, and tools shout when one slips through.

No-code platforms quietly remove all of that machinery. You click "add connection," log in to Google or HubSpot, and from then on it just works. The key is somewhere, encrypted, and you never see it again. That part is usually fine. The platform stores the token safely and does not hand it back in plain text. The clean connection is not the problem. The problem is every place the platform gently invites you to work around it.

A webhook that has to hit an API with no ready-made module. An internal service with a static token. A quick integration that only needs a bearer header. In all of those cases you type the key into a field by hand, and in that moment a managed secret becomes a piece of text inside a workflow definition. Visible to anyone with edit access, copied into every backup, exported the moment you clone or share the scenario.

No-code makes building automations so easy that the invisible discipline a development team carries with it is simply absent. Nobody ever decided to store keys in plain text. It is just the path of least resistance, and without a counterforce, the path of least resistance always wins.

The four places your credentials are actually sitting

When we audit an account, we look in four places, and at least three of them almost always turn up something.

The first is the connection manager itself. That is the good place. The token sits there encrypted, bound to an OAuth flow, managed by the platform. If everything lived there, this article would not need to exist. But even here one question lurks, and we will get to it: whose account is this connection tied to?

The second is HTTP modules and generic API blocks. This is where the static keys end up, the bearer tokens, the basic-auth strings, sitting in plain text in a header or query field, visible the moment you open the scenario. Anyone allowed to edit the workflow can read them, and in most Make or n8n setups, half the team is allowed to edit workflows.

The third is data stores, variables, and note fields. We have found keys in Make data stores, in n8n variables, even in the description fields of modules where someone left them "just in case" so they could find them later. It is the digital sticky note on the monitor, except this note travels along in every export and every log.

The fourth is the most dangerous, because it lives outside the platform entirely: documentation. The Confluence page where someone collected credentials so the team would stop hunting for them. The spreadsheet with a column labeled "API keys." The Slack thread where a key got shared once and now sits in searchable history forever. These keys are exactly as valid as the ones inside the platform, and they are visible to far more people.

If you do not know how many of these four places hold your keys, you do not control them. And control is the entire point of credentials.

Personal connections are a time bomb

We opened with the contractor whose Google account still runs the invoicing, and it deserves its own section, because it is the failure we see most and the one people understand least until it bites them.

Personal connections fail from two directions. When the person leaves, either the process breaks or the access stays open. And while the person is still there, a business-critical operation runs on one individual's permissions, with everything that person happens to be able to see and do in their own account riding along behind it.

The fix is dedicated service accounts. An automation login that belongs to no one personally, named clearly as what it is, holding exactly the permissions the process needs and nothing else. It is more work to set up. It is the difference between infrastructure and a collection of lucky accidents that happen to still be running.

There is a quieter version of the same problem worth naming. Even when a connection is bound to a shared account rather than a personal one, if that account's password lives in three people's password managers and one ex-employee's memory, you have the same exposure with extra steps. Service accounts only help if the credentials behind them are managed as tightly as everything else in this article.

Nobody rotates, because nobody knows what breaks

Security people will tell you to rotate keys regularly. Every 90 days, some policies say. In practice, almost nobody rotates keys in no-code environments, and the reason is not laziness. The reason is fear.

To rotate a key, you have to update every place that uses it. In a clean architecture the key lives in exactly one place, you swap it, done. In a no-code landscape that grew over time, you do not know how many places the same key is stuck to. Maybe three scenarios, maybe twelve, maybe the Confluence page and the spreadsheet too. Rotate it in one place and forget another, and a process breaks, possibly without anyone noticing for days until someone asks why a sync has stalled.

That fear is rational, and it is a symptom. If you cannot rotate a key without getting nervous, you do not have a handle on its blast radius. You do not know what it can do if it leaks, and you do not know what breaks if you change it. Those are the same question from two directions.

The way out is not to rotate more often. The way out is to know where every key lives, so that rotation becomes a matter of minutes instead of courage. A simple inventory, a list of each key and every place it is used, turns a dreaded operation into a routine one. Most companies are missing that list entirely.

Every key can do more than it should

There is a question we ask in every audit and almost never get a good answer to: what exactly is this key allowed to do?

If an automation only needs to append rows to one Google Sheet, its key needs write access to that one sheet. What it usually has instead is full access to the entire Google Drive of whoever authorized the connection. Read, write, delete, across every file. This happens because OAuth scopes get granted generously at setup time and nobody bothers to narrow them as long as it works.

The principle is least privilege, and it is the single most effective move you can make. A key with minimal rights does minimal damage when it is compromised. A HubSpot token that can only read contacts is a contained problem if it leaks. A HubSpot token with full admin access is a disaster that spans your entire sales database.

The discipline is uncomfortable, because restricted rights mean an automation might later need a permission you did not give it, and then it stalls. That is exactly why most people grant too much up front. But the trade is backwards. A process that stops because of a missing permission is a visible, harmless failure you fix in five minutes. An over-privileged key that leaks is invisible damage you might only learn about after it is done.

The compliance angle people skip

So far this reads like a pure security topic. For any company under GDPR, which in Europe is nearly all of them, it is also a concrete compliance topic.

An API key that grants access to personal data is, in data protection terms, access to that data. Whoever holds it can process it. GDPR Article 32 requires technical and organizational measures that govern exactly this: access control, confidentiality, the ability to know who can reach which data. A live payment key in plain text, visible to half the team, is the negation of that requirement in a single field.

A second dimension comes with it. If your automation uses a key to send data to a provider, say an American API vendor, that provider is a processor for whom you need a data processing agreement and a sound legal basis. The key is the technical proof that this transfer is happening. A company that has not inventoried its keys cannot even say which providers are involved, and therefore cannot fully document its own processing.

When something goes wrong, a breach or a regulator's question, the first question is always the same: who had access, and how was it secured? "The key sat in plain text in a scenario twelve people could edit" is not an answer you want to be giving in that moment.

How you find out a key leaked (usually, you don't)

Here is the uncomfortable part. When a key is compromised, most no-code setups give you no signal at all. No alert, no notification, nothing. The attacker is using a valid key, so every request looks legitimate, because technically it is.

Traditional software has logging, anomaly detection, alerts on unusual access patterns. A typical automation setup has none of it. A leaked key can quietly siphon data for months, and you find out, if at all, through a third party. Through a bill for API calls you did not make. Through a customer asking why their data showed up somewhere. Through the provider itself flagging unusual activity.

That shifts the whole logic. If you cannot reliably detect a leak, your only real defense is to make the leak unlikely in the first place and keep its damage small. Which is exactly where the previous sections lead: fewer places a key lives, fewer rights per key, dedicated accounts instead of personal ones. Each of those lowers either the probability of a leak or the damage it does. Since you cannot lean on detection, prevention is not one option among several. It is the only one that reliably works.

Where you can, it is still worth building in a minimum of detection. Some providers, Stripe among them, show the last-used date of a key and allow separate, individually revocable keys. Issue one key per automation and you can revoke a single one on suspicion without taking everything else down, and you can watch the usage stats for a key that is showing activity it should not.

What we actually do

When we put an account in order, we follow the same sequence every time, and it does not start with buying a tool. It starts with taking stock.

First we inventory. Every key, every connection, every place a secret lives goes on a list. Which key, which service, which permissions, which account, which scenarios. That list almost never exists beforehand, and building it alone regularly surfaces keys nobody remembered were there and still valid.

Then we pull the plain-text keys out of the workflows. In n8n that means routing credentials through the credential system consistently instead of through fields in HTTP nodes. In Make it means using connections and, where needed, proper key handling instead of typing tokens into headers. If you are serious and able, put a real secret manager in between, a service whose only job is to hold secrets and hand them out under control. The workflows then fetch the key at runtime and store it nowhere.

Third, we replace personal connections with service accounts. Every production automation runs on an account the company owns, not an employee, named clearly, with a documented purpose. That survives any staffing change.

Fourth, we cut back permissions. For each key, the question: what does this process actually need? Everything beyond that gets revoked. This is the most tedious stage, because it goes process by process, and the most effective, because it limits the damage of every single leak.

Only then do we talk about rotation. With a complete inventory, rotation becomes what it should be: a schedulable task that costs neither fear nor an entire afternoon. For anyone who has done the first four steps, the fifth is nearly trivial.

A 30-minute audit you can run today

You do not have to wait for a project to get a first read. Sit down for half an hour with someone who has access to your automation platform and walk through the following.

Open your five most important scenarios and look inside every HTTP or API module. Is there a key or token sitting in plain text anywhere? Note every one you find. Then open the connection manager and check, for each connection, whose account it is tied to. Does anyone who has left or is about to leave show up there? Check whether there is a collection of credentials anywhere, in Confluence, a spreadsheet, a chat, and whether the keys in it are still valid. Finally, for your three most critical connections, ask what permissions they actually hold and whether the process needs even a fraction of them.

If you go through those four questions honestly, you will very likely find at least one problem worth fixing the same day. That is not a sign of negligence. It is the normal state of any no-code account that grew piece by piece over a few years. The difference between a secure account and an insecure one is not that nothing ever went wrong in the secure one. The difference is that in the secure one, someone once looked, systematically.

What it comes down to

Credentials are the silent foundation of every automation. As long as they work, nobody thinks about them, and that is precisely what makes them dangerous. The payment key in plain text, the token tied to a former contractor's account, the full-access key powering a task that only needed to read: none of these problems shout. They wait quietly until a person leaves, a key leaks, or a regulator asks.

The good news is that this is solvable with discipline rather than budget. An inventory you can keep yourself. Plain-text keys moved into the platform's credential system. Service accounts instead of personal logins. Permissions cut to what the work requires. None of it is rocket science. It is hygiene, and like all hygiene it only works when it becomes a habit rather than a one-time cleanup.

If you are not sure where your keys live and who can see them, that is the most valuable question you can ask of your automation this week. And if you flinched just now because a specific scenario came to mind, that is exactly where you start.