The accounts nobody remembers connecting to your site

In short: your site is not only its code and its server. It is every account, plugin and service that was ever given a way in: the theme you bought, the forms plugin, the agency that built it, the builder you used once for one page. Below is where to look, what to write down for each one, and what to do with the ones you no longer use. Plan a morning for the first list, and have one person own it by name.

This is a list you make and keep yourself. It is not an audit or a certification, and a list that looks complete does not prove that nothing else has access. The menus and rules below are as each vendor's own documentation described them when we read it on 31 October 2026. Menus move, so if a name differs, search the vendor's help for the title of the page we link.

Two emails, eight minutes apart

On 28 October 2026 I received two emails from an AI site builder I had used once, about a year earlier, for an old site. The first arrived at 17:01. It said a security incident affected my account and told me to rotate my keys. The second arrived at 17:09. It said my keys were not affected.

Eight minutes apart, from the same sender.

I did not choose which one to believe. I checked every place the service could have received access: the authorized apps on my GitHub account, which listed 17 OAuth apps plus 3 GitHub Apps, then the hosting, then the database. It had no access anywhere, and there was nothing to revoke.

It took a morning, one two-factor code and one forgotten login to say that with certainty. And I knew what I was looking for. If you have never made this list, the first part of the work is knowing where to look. The rest of this article is that list of places.

A site is every account connected to it

When people say "the site", they usually mean the pages a visitor sees. What decides who can change those pages lives somewhere else: in the accounts and services connected to the site over the years. For a small company the list often includes:

• the theme or template you bought, and the account you bought it with
• plugins and modules: forms, booking, chat, newsletter sign-up
• the agency or freelancer who built the site, and anyone who maintained it later
• the AI site builder or AI coding agent you connected to your code once, for one page
• the hosting, the domain, the database, and the email account that receives every password reset

Each of these was added by someone, on a day when it made sense. Few are ever removed. Starting the list is easy. Keeping it current is the hard part, so the list needs one owner, by name. "The team" or "the agency" is not an owner.

Before you start: one page, one owner

Open a spreadsheet or a plain document. At the top, write the name of the person who owns the list and today's date. Then go through the places below one at a time, with your password manager open and your phone nearby for two-factor codes. Expect at least one login you have forgotten. I had one.

1. GitHub: authorized apps, installed apps, tokens and keys

If your code is on GitHub, this is where "Sign in with GitHub" and "Connect your repository" buttons leave their trace. In your account settings, under Integrations, click Applications. There are three tabs, and they are three different lists:

• Authorized OAuth Apps. Each one holds a token with access to your account. GitHub's documentation says to review them for new applications with broad permissions, such as access to your private repositories, and to revoke the ones you do not recognise or that are out of date.
• Authorized GitHub Apps. Apps you allowed to act on your behalf. According to GitHub, only the person who authorized an app can revoke that authorization. An organization owner cannot do it for you.
• Installed GitHub Apps. Apps installed on your account, with the repositories each one can reach. For an organization, the same list is in the organization's settings, under Third-party Access, then GitHub Apps. Uninstalling an app removes its access to that account, but GitHub notes the app may still be authorized to act on your behalf elsewhere. To stop it everywhere, also revoke it in the Authorized GitHub Apps tab.

Two more places on GitHub:

• Personal access tokens, under Settings, then Developer settings. GitHub says you should delete a token you no longer need.
• Deploy keys, in each repository's settings, under Security. GitHub's page on deploy keys says to delete the ones you do not recognise or that are out of date.

2. Hosting and deploy accounts

Whoever can log in to the hosting account, and every token it has issued, can publish a new version of your site. In your host's dashboard, look for the members or team page, the API tokens page, and the list of connected Git repositories. The names differ from host to host. On Cloudflare, for example, account members are on the Members page, where a Super Administrator can remove a member. API tokens are under My Profile, then API Tokens, for tokens tied to a person, and under Manage Account, then API Tokens, for tokens tied to the account.

Write down every token you find, even if you do not know what it is for. A token nobody can explain is the first one to ask about.

3. Domain registrar and DNS

Whoever controls the domain controls where your site and your email point. At the registrar, check who can log in, when the domain expires, whether it renews automatically, and which email address is the registrant contact.

That last one matters more than it looks. On Cloudflare Registrar, changing the registrant's name, organization or email needs an approval sent to the current registrant's email address, and a request nobody approves within seven days is cancelled. If that address belongs to someone who left, or to the agency that registered the domain, you need them to make the change. The same page notes that under ICANN rules a registration with outdated contact details may be suspended or even cancelled. Cloudflare's domain management page shows where to see the expiry date and the Auto-Renew status.

If your DNS is managed somewhere other than the registrar, repeat the members and tokens check there. A token that can edit DNS records can point your site or your email somewhere else.

4. Database and backend tokens

A database account has members, and usually keys and tokens too. Supabase, which many AI-built apps use, is a good example of all three:

• Members. Your organization's team settings list everyone with a role. Supabase's access control page says a member with an organization-level role has those permissions on all current and future projects in that organization.
• Personal access tokens. These let tools such as the Supabase CLI act as you. The Supabase documentation is direct about the older kind, shown with a Legacy badge: a token with your account's full access carries every permission on every organization and project you belong to, including ones you create or join later. In its words: "A full-access token created a year ago can touch a project you created today."
• API keys. A secret key, or the older service_role key, bypasses row level security and has full access to the project's data. Write down every service and server that holds a copy.

5. Email and analytics scripts on your pages

Newsletter sign-ups, chat widgets, analytics and tag managers work the same way: your page loads a script from someone else's server, and that script runs inside your page like your own code. When such a provider is compromised, the sites that load its script are exposed with it. We described one case in the Brevo supply-chain attack.

To see which outside services your pages load, open your site in Chrome, open DevTools, go to the Network tab and reload the page. Chrome's guide to the Network panel shows how to add a Domain column: right-click the header of the table and select Domain. Every domain that is not yours belongs to some account. For each one, write down which account it is, who can log in to it, and whether you still use it. A tag manager is itself a way to add scripts to every page, so the people who can publish in it belong on the list too.

6. Payment and form services

Payment providers and form services hold two kinds of access: people who can log in to the dashboard, and API keys that your site or another service uses. In each one, open the team or users page and the API keys page, and list both. Also note where form submissions and payment notifications are sent. If they go to a former colleague's address, so do your customers' messages.

7. People and agencies with logins

Go back through every account above and read its member list once more, this time asking about people instead of apps: the agency that built the site, the freelancer who fixed the forms, the colleague who left last year. For each person, write down which accounts they can still log in to, and decide whether they should. If your site runs on WordPress or another content management system, its own users screen belongs here too, because an administrator there can usually change anything on the site.

8. Tools you used once

This is the one my story is about. An AI site builder, a page builder, a form tool, a website scanner: you connect it to your code or your hosting to try it, and forget it the same week. These tools leave their trace in the places above, most often in GitHub's authorized apps. Two more ways to find them:

• Search your email for the words "authorized", "connected", "installed" and "welcome", and look at what you signed up for.
• Look through your password manager for sites you saved once and never opened again.

For each tool you find, look for its name in the places above. If it is in none of them, write that down too. "No access found, checked on 31 October" is a useful line.

What to write down for each

One line per account or service, with these fields:

• Name: the service, and which login it uses.
• What it can reach: which repositories, which site, which database, which domain. "Everything" is an answer, and worth noticing.
• Owner: one person, by name, who decides whether it stays.
• Alert email: the address that receives its security emails and password resets. If it belongs to someone who left or to an agency, change it.
• Last used: copy the date if the dashboard shows one. Otherwise write "unknown".
• Decision: keep or remove, and the date you decided.

What to do with what is no longer used

1. Revoke the access. Revoke the app, remove the member, delete the token. On GitHub, an app may need both: uninstall it, and revoke its authorization, as in section 1.
2. Then rotate every key it held. Removing a service does not change a key you once gave it. If it ever had a copy of a secret, create a new one and retire the old one. Supabase's rotation guide gives a safe order: create the new key, replace it everywhere the old one is used, confirm, then retire the old key. It also warns that deleting a secret key cannot be undone. Cloudflare lets you roll an API token, which invalidates the old secret and keeps the same permissions.
3. Write the date on the line. The next person who reads the list should see what was removed, and when.

How to read a confusing vendor alert

A security email from a vendor tells you what the vendor knows. It cannot tell you what that vendor could reach in your accounts. Your list can, and you can check it yourself, whatever the email says.

• Do not act through the email's links. Open the vendor's site and your own accounts the way you normally would, by typing the address or using your password manager.
• Look for the vendor in your own accounts. Go through the places above and search for its name. If it has access somewhere, revoke it and rotate what it held. If it has none, there is nothing to revoke.
• Read the logs you have. GitHub's security log, under Settings, then Archives, lists actions on your account from the last 90 days, including OAuth app authorizations. Cloudflare keeps account audit logs (version 1) for 18 months. Supabase's platform audit logs record dashboard and API actions by organization members, on the Team and Enterprise plans.
• Write down what you checked, and when. If a second email contradicts the first, as mine did eight minutes later, your own check is still the answer.

How often to repeat it

• Once a quarter, on a date in the owner's calendar.
• Whenever someone leaves, or a contract with an agency or freelancer ends.
• Whenever you connect a new tool, even for a test. Add its line the same day.
• Whenever a vendor sends a security email, even one that says you were not affected.

The second pass is faster than the first, because you only look for what changed.

A 10-point checklist for a company site

We publish a short checklist in Romanian for public institutions, 10 lucruri de verificat pe site-ul instituției sau al firmei, written so that it can be done without technical knowledge. This is the same idea for a company, focused on who can reach the site:

1. One named person owns the access list, and it shows the date of the last check.
2. The domain is registered to the company, the registrant email is one the company controls, and the domain renews automatically.
3. Every admin login for code, hosting, domain, database and email uses two-step login, and nobody shares a login.
4. The platform, theme and plugins are up to date, and the ones you do not use are removed.
5. Nobody who has left, and no agency whose contract has ended, still has a login.
6. Every authorized and installed app on GitHub is one you still use.
7. Every API key and token has a named owner, and the keys once held by removed services have been replaced.
8. Every outside script on your pages comes from an account you can name and log in to.
9. Security emails from every service reach an address that someone reads.
10. A copy of the site and its data is kept outside the hosting account, and you have restored it at least once.

What this list does not cover

It shows who and what was given access. It does not test your site for weaknesses that need no access at all, and it cannot find an account that nobody remembers and that left no trace in the places above. For what a stranger can reach from the browser, use 10 things to check before real users arrive. A finished list means these places were checked on that date, nothing more.

When to get help

If you find an app, a token or a login you cannot explain, or you cannot tell what a key you need to rotate is used for, a second pair of eyes is usually faster than guessing. Our AI app rescue is built for sites and apps made with AI builders and AI coding agents. It starts with a fixed-price diagnosis: a written report of what is wrong, why, and a fixed price for each fix. The report is yours to use with any developer.

Frequently asked questions

How long does the list take the first time? For one site and one person, plan for a morning. Checking one vendor across GitHub, hosting and the database took me about that, so a full list can take longer. Every service with its own login and two-factor code adds time, and so does every login you have forgotten.

Who should own the list? One person, by name, who can log in to the main accounts or can ask someone who does. In a small company that is often the founder. "The team" or "the agency" is not an owner.

If I uninstall an app on GitHub, is it gone? Not always. Uninstalling removes its access to that account. GitHub notes the app may still be authorized to act on your behalf, so also revoke it in the Authorized GitHub Apps tab.

Do I need to rotate keys if I removed the service? Yes, if the service ever held a copy of a key. Removing the service ends its own access, but a key it once received keeps working until you replace it.

A vendor emailed me about a security incident. What do I do first? Do not use the links in the email. Open your own accounts directly, look for that vendor in each place on your list, and revoke and rotate only where it actually had access. Write down what you checked.

Is this a security audit? No. It is a list of accounts and who owns them, made and kept by you. It does not test your site, and it does not prove that nothing else has access.

Sources

All vendor pages read on 31 October 2026. If you find a difference from the source, write to us and we will correct the article.

• GitHub Docs: Reviewing your authorized OAuth apps, Reviewing and revoking authorization of GitHub Apps, Reviewing and modifying installed GitHub Apps, Managing your personal access tokens, Reviewing your deploy keys, Reviewing your security log.
• Cloudflare Docs: Manage account members, Create API token, Roll tokens, Registrant contact updates, Domain management, Review audit logs, version 1.
• Supabase Docs: Access control, Personal access tokens, API keys, Rotate a leaked or compromised API key, Platform audit logs.
• Chrome for Developers: Inspect network activity.