An AI that needs to read a client's social media account (to measure, recommend, or alert) needs that client to authorize their own account. The fastest shortcut is to hand it, without thinking too hard, the key your platform uses to talk to that social network on behalf of EVERY client at once. It works on the first try. And it is exactly the mistake you cannot afford to make even once, because it turns one client's security problem into every client's security problem.
We ran into this head on recently: a client wanted their own data platform to read their TikTok account's statistics. Here is how we solved it without that key ever leaving our server, and the rule we are keeping for any similar integration.
The underlying problem: one key, many clients
When a company builds a platform that talks to a social network (TikTok, Meta, LinkedIn) on behalf of several clients, there is usually a single application credential registered with that network: it identifies the whole platform to TikTok, Meta, or whoever. That key is necessary and there is nothing wrong with it, as long as it stays exactly where it belongs: on the server of whoever manages it.
The problem shows up the moment you need to connect ONE specific client's account. If getting their platform to read their own data means handing them, even indirectly, through an environment variable or a config file, that same master key, you have just created this risk:
- A security failure on THAT client's server (just one, the weakest of them all) compromises the key that speaks on behalf of every other client.
- There is no way to revoke one client's access without invalidating everyone else's, because they all share the same credential.
- You cannot audit which client made which API call, because every call identifies itself the same way.
It is the same pattern, at a different scale, we described when we wrote about what happens when an AI agent depends on someone's personal account permission: one shared piece, without anyone noticing, ends up holding up things that should each stand on their own.
The fix: separate "who holds the key" from "who uses the data"
The decision rule we apply is easy to state, and the hard part is keeping it that way day to day: the master key that talks to the social network never lives on any client's server. What does live there is a short-lived token, belonging to that client and no one else, which their server requests using a secret that only works for them.
In practice we built a go-between with three pieces:
1. An invitation link that expires
The client does not type anything in by hand: they get a signed invitation link that expires after 72 hours. Opening it from their own browser is how they authorize their own TikTok account, with their own session, never with ours. We never see or touch their password at any point.
2. A short-lived token, renewed on its own
Once the account is authorized, the client's server does not receive the master key: it receives a token that lasts 24 hours, and renews itself automatically only when it has less than 2 hours of life left. If that token leaked, the window for misuse is hours, not forever, and it only affects that one client, never anyone else.
3. A secret that only opens one door
When the client's server requests that token, it does so with a secret issued only for them. With that secret they can renew their own access when it is due, but they cannot use it to request another client's token. Revoking one client means deleting their secret, without touching anyone else's.
What you cannot skip: showing the real data
There is an extra temptation in this kind of connection: leaving the confirmation screen at a plain green "connected", and assuming that is enough. It is not, for two reasons.
The first is about trust: if you are going to ask a client to authorize access to their account, the social network's own security review (and the client themselves) need to be able to see, on screen, exactly what is being read with each permission requested. An empty "connected" proves nothing.
The second is practical: we requested 4 permissions for this integration, and the confirmation screen genuinely shows the authorized profile, its counters, and the last 20 videos read with their metrics, covering exactly those 4 permissions. If we ever request one permission too many that is not reflected on any screen, that is the clearest signal that something in the design has gone wrong.
Checklist: before connecting a client's AI to their social account
If your business is building something similar (a platform that reads or posts to social media on behalf of several clients at once), these are the questions we ask ourselves before signing off on an integration:
- Does the key that talks to the social network on behalf of everyone live in exactly one place, and never on a client's server?
- Does the client's server receive a short-lived token, instead of the master key?
- Does that token renew itself before expiring, with no manual step?
- Does revoking ONE client's access leave every other client untouched?
- Does the invitation or authorization link have an expiry date?
- Does the confirmation screen show the real data read (profile, counters, content), not just a generic success message?
A rule that goes well beyond TikTok
This rule is not specific to TikTok, or to social media: it applies to any AI data platform that needs to connect to a client's account inside a system shared by several clients at once (a multi-client ERP, a payment gateway, a messaging hub). The question you should always ask is the same one: if this key leaked today, how many clients would it affect? If the answer is "more than one," the design is wrong, no matter how well it currently works.
It is exactly the kind of decision we made in AutoBoost when we built the AI data platform for a group of pharmacies: before the AI could reason over each office's data, we first had to decide who holds the key and who uses the data every day. We cover that in more detail in our AI data platform case study.
If your business is about to connect an AI to the social media accounts (or to any shared system) of your own clients, check first who holds the key that opens everyone's door. In our services we explain how we approach this from the start, before writing the first line of integration code. And if you want us to review how yours is set up today, get in touch.
