The largest single workload on Antbase is a finance pipeline — a set of n8n workflows that classify transactions, summarise statements and draft reconciliations. It is mine, which means the hardening below is not a checklist written for a blog post; it is the configuration I actually run, including the parts where the honest answer is "redact it before you send it."
This post assumes you are putting something you care about through a third-party inference layer and want to know precisely what that exposes. I will start with the part vendors usually bury.
What Antbase stores of your requests
A truncated preview of your prompt. Not the whole prompt, but a preview, and it is real content.
- •Every request writes a trace row: model, provider, timings, token counts, cost, error code — and a truncated prompt preview.
- •Prompt previews are deleted after 30 days by a scheduled job that nulls the content and keeps the metrics. The routing telemetry survives; what you typed does not.
- •A hash of the prompt is kept after the preview goes, so duplicate detection and cache analysis keep working on content that is no longer stored.
- •In operator views your previews show as `[redacted]` by default. Visibility is opt-in per user, from your dashboard settings, and exists so you can let support see a failing prompt when you want help with it.
- •There is currently no per-workspace switch to disable preview storage entirely. If that matters to you, the mitigation is on your side, below.
So the rule for a finance workload is the obvious one, and it is not satisfied by any vendor promise: do not send raw account numbers, counterparty names, card numbers or customer identifiers in the prompt. Redact client-side, before the request leaves your process.
// Replace identifiers with stable tokens before the prompt is built.
// The model reasons about structure, not identity - it does not need the
// real IBAN to classify a transaction, and a preview of this is harmless.
const scrub = (s: string) =>
s
.replace(/\[A-Z]{2}\d{2}[A-Z0-9]{10,30}\/g, '<IBAN>') // IBANs
.replace(/\(?:\d[ -]*?){13,19}\/g, '<CARD>') // card numbers
.replace(/\\d{9,12}\/g, '<ACCT>'); // account numbers
const res = await fetch('https://antbase.ai/v1/chat/completions', {
method: 'POST',
headers: {
authorization: `Bearer ${process.env.ANTBASE_KEY}`,
'content-type': 'application/json',
},
body: JSON.stringify({
model: 'ant:coder',
messages: [{ role: 'user', content: scrub(statementText) }],
}),
});If you keep a mapping from token back to identifier on your side, you get the model's reasoning without the model — or the router, or the upstream provider — ever seeing the identity. This is worth doing even with a vendor you trust completely, because it shrinks the blast radius of a mistake anywhere in the chain to nothing.
Use BYOK, and understand what it does and does not change
With Bring Your Own Key, Antbase routes your request to the provider using your credential, and the provider bills you directly. There is no fee for this.
- •What it changes: the commercial relationship and the data processing agreement for inference are between you and the provider. Your enterprise terms, your zero-retention agreement if you have one, your region.
- •What it does not change: the request still passes through Antbase, and the trace row with its prompt preview is still written. BYOK is not a bypass of the paragraph above.
For a regulated workload BYOK is usually the right answer anyway, because it means the model provider you have actually diligenced is the one serving the request.
Pin the models your risk review approved
A router picking the best available model is exactly what you want for a chatbot and exactly what you do not want for a process under audit. Model whitelisting restricts a team or a project to an explicit allowlist. Anything outside it is refused with a clear `MODEL_NOT_ALLOWED`, rather than quietly served by a substitute.
This is the single most valuable control in the list for finance, for two reasons. It makes your model choice reproducible, which is the thing an auditor asks about. And it is how you keep sensitive projects off the free pool — which brings us to the caveat that matters most.
Free models are served by third-party free tiers. Free tiers are free because the provider gets something else out of the arrangement, and that something is often permission to train on what passes through. Never route confidential data to `ant:free`.
An allowlist that excludes free models is how you enforce this structurally instead of by remembering. Set it per project, and a well-meaning change to a prompt template cannot accidentally send last quarter's ledger to a free endpoint.
Cap the spend in two places
- •Per-team and per-project budget caps are enforced on the request path. Reach the cap and requests stop with `BUDGET_EXCEEDED` (HTTP 402) until the period resets or you raise it. This is a hard stop, not an alert after the fact.
- •Every request is also priced against your balance before it runs, using the real prompt size. A prompt you cannot afford is refused with the cost and the shortfall stated; a reply you cannot afford in full has its `max_tokens` lowered instead. You cannot spend past your balance.
For an automated pipeline the project cap is the one that saves you. A finance workflow that loops — a retry storm, a malformed statement that re-triggers, an agent that misreads its own output and tries again — is the realistic way a bill goes wrong, and it goes wrong at three in the morning. Set the cap to the most that workflow could legitimately need in a day.
One key per service, and rotate them
- •Issue a separate Antbase key per workflow or service, not one shared key. A key is then revocable without an outage anywhere else, and your usage breaks down by caller for free.
- •Never put a key in a startup command, a container image layer, a committed config file, or a screenshot. Read it from a secret store at runtime.
- •Rotate by creating the replacement first, moving each consumer over, verifying traffic on the new key, and only then revoking the old one. Revoking first means an outage you then debug under pressure.
- •If you think a key has leaked, invert that order: revoke immediately, then issue the replacement. A short outage is cheaper than an unknown third party on your balance.
That last point applies to your upstream provider keys too, and it is worth being concrete about why one place is uniquely bad: a credential committed to a git repository is not removed by deleting it in a later commit. It is in the history, and the only remedy is rotation. Treat "it was in a private repo" as a reason to rotate sooner rather than a reason not to.
The n8n setup, concretely
If you are driving this from n8n, as I am, the configuration is an OpenAI credential pointed at Antbase. Set the base URL explicitly — an unset base URL is how requests end up somewhere you did not choose.
# n8n OpenAI credential
Base URL: https://antbase.ai/v1
API key: <a key issued for this workflow only>
Model: ant:coder # or a pinned model id from your allowlist- •Put the finance workflows in their own Antbase project, with their own allowlist and their own daily budget cap.
- •Scrub identifiers in a Function node before the model node, not inside the prompt template, so the redaction cannot be edited away by someone tweaking wording.
- •Set a timeout and a bounded retry count on the model node. Unbounded retries plus a per-token cost is the loop that empties a balance.
- •Log the Antbase request id your side. When something needs explaining later, that id is how you connect your run to the routing trace.
Where it runs
Antbase itself runs in Europe. That governs where the trace rows and previews described at the top of this post live. It does not govern where your inference happens — that is determined by the model and provider you route to, which is precisely why the allowlist and BYOK matter more than the router's own location. If data residency is a hard requirement, pin models whose provider and region you have verified, and use your own key so your agreement with that provider is the one in force.
The short version
- •Redact identifiers client-side. Assume everything you send is stored somewhere for a while, because a preview is.
- •Use BYOK so the provider you diligenced is the one serving you, and bills you.
- •Pin an allowlist per project, excluding free models.
- •Set a hard daily budget cap on every automated workflow.
- •One key per service; rotate new-then-old, except after a leak, when it is old-then-new.
None of this is exotic. It is the same discipline you would apply to any processor handling your data, with one addition specific to inference: the prompt itself is the payload, and it is the part people forget to treat as sensitive.
