How the Credential-Isolation Pattern Works (and Why BulkForge Is Built On It)

Most SaaS email tools work the same way: you paste an API key or an SMTP credential into their dashboard, and from then on their servers send on your behalf. It's simple to set up, and it means a copy of a credential that can send email as your organization now lives in a database you don't control. BulkForge is built around avoiding that specific trade. This post walks through how.

The two halves: control plane and agent

BulkForge splits into two pieces that run in different places.

The control plane is the part you log into. It's where you build a campaign, upload a recipient list, schedule a send, and watch results come back. It runs on our infrastructure, and it never holds a delivery credential.

The agent is a small deployment that lives in your Azure subscription. You deploy it once, into your own tenant, with its own managed identity. When a campaign runs, the control plane tells the agent what to send and to whom; the agent is the thing that actually reads the delivery credential and hands messages to the provider.

Where the credential actually lives

In your Key Vault. Not ours.

The agent authenticates to your Key Vault using its managed identity, which you grant read access to secrets (the Key Vault Secrets User role) and can revoke at any time from the Azure portal. The Postmark, Azure Communication Services, or SendGrid credential is read from your vault, used in your tenant, and never transmitted back to the control plane. If you rotate it, you add a new version of the secret in your own Key Vault and restart the agent's Function App, which is the step the install guide gives.

What this changes in practice

• Your audit surface doesn't grow. A security or compliance review asks "where can email be sent as us, and who has those credentials." With the paste-the-key model, the honest answer now includes a third-party vendor's database. With the isolation model, the answer is unchanged: the credential is in your Key Vault, same as before you adopted BulkForge.
• Revocation is yours. Cutting off BulkForge's access is a permissions change in your tenant, not a support ticket asking a vendor to delete something and trusting that they did.
• Your credentials stay put. The sending itself happens inside your subscription, with your credentials. Recipient lists and message text are still uploaded to and stored by the hosted control plane for a limited retention period, so the pattern is about credential custody, not about keeping content out of the control plane. For teams sending operational notices, that is the honest answer to "who holds what".

The cost of the pattern

It's not free. You deploy and maintain an agent, which is more than pasting a key into a form. The bet BulkForge makes is that for organizations already operating in Azure with a Key Vault and a compliance obligation, a one-time deployment is a smaller ongoing cost than an expanding credential inventory.