Why We Built On-Premise First — and What It Forces You to Get Right

Most AI platforms are built for SaaS first. On-premise support gets added later — usually as a Helm chart that wraps the same architecture that was designed for shared infrastructure, with credential management bolted on and audit logs written to a volume mount.

We built Orchestrik on-premise first. Not because we think SaaS is wrong, but because the constraints of on-premise deployment force you to solve the hard problems correctly: how do you store credentials so the agent never sees them? How do you write an audit log that can survive a node failure and still be tamper-evident? How do you enforce tenant isolation when there's no SaaS boundary to fall back on?

Those solutions turn out to be better for SaaS too. The credential vault we built for air-gapped on-premise deployments is strictly better than what you'd build if you assumed a cloud secrets manager was always available. The audit log design we built for compliance teams who need court-admissible records also makes debugging agent failures in production much easier.

An AI agent needs credentials to do anything useful — API keys, database passwords, OAuth tokens, service account certs. If the agent model or the agent runtime can read those credentials directly, you have a serious problem: prompt injection attacks, model output logging by upstream providers, and inference infrastructure you don't control all become paths to credential exposure.

The Orchestrik credential vault sits outside the agent runtime. Credentials are resolved at connector execution time — the connector layer makes the call, not the agent. The agent receives a result: 'the ticket was created', 'the row was updated', 'the approval was granted'. It never sees the credential that made it possible.

This isn't a new idea — it's the same pattern as IAM role assumption in AWS, or a secrets manager with short-lived tokens. But it requires the vault to be a first-class component in your architecture, not a .env file the agent loads at startup. Building for on-premise means you can't assume a managed secrets service. So you build the vault properly.

Regulated industry buyers ask a consistent question: 'if something goes wrong, can you show us exactly what the agent did?' The answer has to be yes before anything else matters.

An audit trail that's useful for compliance review has specific properties: it records inputs and outputs at every step (connector call, model call, approval decision), it's written to storage the agent runtime can't modify after the fact, it's structured so it can be queried by regulators and piped into SIEM systems, and it survives infrastructure failures without gaps.

Writing to a database the agent has write access to fails the tamper-evidence test. Writing to object storage with append-only policies and periodic hash chaining passes it. That design choice — which seems like an implementation detail — determines whether your audit trail is useful in a compliance context or just a log file you can point to.

Building for on-premise means you can't assume cloud-native append-only storage. So you design a write path that works the same way whether the storage backend is S3, Azure Blob, a local NFS mount, or a Postgres table with a trigger that prevents UPDATE and DELETE. The abstraction forces you to be explicit about the guarantees, which makes the implementation better everywhere.

SaaS multi-tenancy typically relies on the cloud provider's account or VPC boundary to separate tenants at the infrastructure level. When you remove that, you have to implement the isolation yourself — at the data layer, the credential layer, and the control plane layer.

In Orchestrik's on-premise deployment, each tenant gets a separate credential vault namespace, a separate audit log partition, and separate control plane scoping. The agent runtime is shared, but it can only access the connector context it was invoked with. There's no path from one tenant's execution context to another's credentials or audit records.

This isolation model is more work to implement. But it means that when an enterprise customer asks 'could another tenant's agent access our data?', the answer is no — and you can show exactly why, at the code level, not just at the policy level.

Everything described above applies to Orchestrik's managed SaaS tier too. The credential vault is the same component. The audit log write path has the same tamper-evidence properties. Tenant isolation uses the same boundaries.

The difference is that on SaaS, we operate the infrastructure. On on-premise or private cloud, the customer operates it. The design is the same. The operational responsibility shifts.

Customers who start on managed SaaS and later need on-premise — usually because of a new regulatory requirement or an acquisition that brings a stricter compliance environment — can migrate without rebuilding their agents. The connector configurations, the audit trail format, the control plane dashboard, the approval chain setup: all of it moves. The only thing that changes is where the infrastructure runs.

On-premise is harder to operate. Updates are slower to deploy. You carry more operational responsibility. If none of your clients have data residency requirements, compliance mandates, or a security team that will block a SaaS vendor, you probably don't need it.

But if you work with regulated industries, enterprise procurement teams, or clients who have had a serious incident and now have strict vendor requirements — the ability to say 'this runs in your environment, your team controls the infrastructure, and here is the audit trail' changes the commercial conversation.

We built it first because the hard version of a problem forces better solutions. The credential vault, the audit log, the tenant isolation model — these are better because on-premise forced us to build them right. SaaS customers benefit from that, even if they never run a node themselves.