Your AI never sees your passwords (and it never should)
Connecting an AI to the software your business runs on means handing over the keys to your inbox, your CRM, your calendar. The one thing that should never happen is the AI ever holding those keys. Here's the credential architecture that keeps them out of the model's reach.
The moment you let an AI act inside your real business systems, one question matters more than any other: where do the credentials live?
Because to send an email from your inbox, update a deal in your CRM, or drop a file in your drive, something has to hold the keys to those accounts. The entire trust model of an AI-connected business comes down to a single design decision: whether that something is the AI, or a layer you actually control. FloConnector’s answer is unambiguous: the AI never holds the keys. Not the tokens, not the passwords, not the refresh secrets. Here’s how that’s enforced rather than just promised.
Two layers of auth that never touch
The critical idea is that there are two completely separate authentication boundaries, and credentials never cross from one to the other.
Layer A, the AI client to FloConnector. Your AI (Claude, or whatever speaks MCP) authenticates to FLC with its own token. In beta that’s a connection bearer; at GA it’s full OAuth 2.1 with PKCE. This token says “this client is allowed to talk to this workspace’s endpoint.” That’s all it can do.
Layer B, FloConnector to your vendors. Separately, when you connect a platform during onboarding, FLC completes that vendor’s OAuth flow and holds the resulting tokens. These are what actually authorize calls to your inbox, your CRM, your calendar.
The point is that Layer A and Layer B never meet. The AI’s token (Layer A) can ask FLC to “send that email.” FLC then uses the vendor token (Layer B) to do it. The AI never receives, sees, or can request the vendor token. It asks; FLC acts. The keys stay on FLC’s side of a wall the model can’t reach across.
The vault: encrypted before it’s ever stored
Holding vendor tokens is a responsibility, so the second rule is about how they’re kept. Vendor OAuth tokens are envelope-encrypted app-side before they’re written down. The plaintext token is encrypted in the application layer; only the ciphertext reaches the database.
That distinction matters. It means the database, the thing most likely to be dumped, backed up, snapshotted, or subpoenaed, never contains a usable credential. A leaked database row is ciphertext without the key. Decryption happens in the application, in memory, only at the moment a call actually needs to be made, and the refresh cycle runs server-side so expiring tokens are renewed without anyone, human or model, handling them.
The safest place for a secret is one where the systems most likely to leak never hold it in usable form. The DB stores ciphertext; the plaintext lives only in memory, only for the instant a call needs it.
Least privilege, by construction
Keeping credentials safe is table stakes. The next question is scope: even acting through FLC, how much can the AI actually reach? The design answer is “only what you’ve explicitly turned on,” enforced at several points:
- Only connected, entitled vendors are exposed. A workspace’s endpoint surfaces tools for the platforms it has actually connected and is paying for. Everything you haven’t switched on simply isn’t there to be called.
- Namespaced by platform. Every tool is prefixed by its vendor (
gmail_,slack_), so there’s never ambiguity about which system an action lands in. - Per-user access, not blanket access. Reaching a connection is gated on workspace membership and an explicit per-user assignment. Being in the workspace isn’t enough; you’re granted the specific connections you should have, and no more.
Add it up and the AI operates inside a box you drew: a known set of platforms, clearly labelled, scoped to the person on whose behalf it’s acting.
Store less, so there’s less to lose
The last principle is the quietest: minimise data at rest. FLC is a proxy and a composite-tool layer, not a data warehouse. It deliberately doesn’t keep a standing mirror of your business data. Large reads are processed in an ephemeral, in-memory analytics engine that’s discarded after the request, so the raw records never become a persistent copy sitting somewhere waiting to leak.
Its own interaction log, the record it keeps for billing, support, and product analytics, is built to hold metadata, not sensitive payloads: which tool ran, for which workspace, when, whether it succeeded. The encrypted vendor tokens are the one genuinely sensitive thing FLC stores, and they’re encrypted app-side precisely because they’re the exception, not the rule.
Why this is the whole ballgame
It’s tempting to treat security as a checklist bolted onto a product after it works. For an AI that acts inside your real systems, it is the product. If the credential model is wrong, nothing else you build matters, because the first incident ends the trust.
So the architecture is arranged around one sentence you should be able to say plainly to anyone: the AI can do the jobs you allow, in the systems you’ve connected, on behalf of the people you’ve granted, and at no point does it (or anyone dumping a database) hold a key that still turns a lock.
That’s not a feature. It’s the foundation the features are allowed to stand on.
Keep reading
More from the blog
Code mode needs a sandbox. Query mode doesn't.
Context engineering for MCP has two named answers: deferred loading for too many tools, code execution for too much data. Code execution buys its savings with an agent sandbox. Here's the third answer I built FloConnector on instead, why I think it's the right default, and where it loses.
What is an MCP server? A plain-English guide
An MCP server is the piece that lets an AI like Claude actually do things in your other software: read a spreadsheet, send an email, raise an invoice. Here's what that means, how it works, and why you probably shouldn't build one yourself.
How FloConnector keeps 50+ connectors out of your context window
Loading every tool a business might need costs ~72K tokens before the model reads a word. Deferred tools flip that: the model pays only for what it reaches for. How it works, why it isn't part of MCP, and what a server can actually do about its own context cost.