Security

You run the network for a company that's considering a build from us, in-house or as their MSP. You have a veto, and we'd rather you exercised it now, on facts, than halfway through a build. This page covers access, residency, model usage and cost, logging, scope, and handover.

We ask for the least access that lets the tool do its job. Your team provisions the scoped service accounts and can revoke them at any time. We take read access where reading is the work, and write access only where the build spec names it, never outside the systems in that spec. No shared logins, and no standing admin rights.

The build runs in the client's environment: their tenant, their database, their credentials. Where the ERP is on-premises, the tool runs on-premises. Operating data isn't copied to any platform of ours, because we don't have one. No per-seat rent, no proprietary platform.

One thing does leave the environment: the text the reading requires. Take the rebate-and-margin tool we built inside Kelsan, a distributor in our own group — it checks the rebate terms in contracts against line items, every day. The tool calls an AI model to do the reading. That usage is metered, like any cloud service, and we put the monthly number in writing before a build starts. What's transmitted is the minimum the task needs: relevant contract text and the line items under check, not the database. The build spec names the model vendor and the retention terms that apply before anything is connected.

We don't manage firewalls, endpoints, identity, or backups — and we don't want that job. The network stays yours. A build touches the systems named in its spec and nothing else. Keep your MSP. Nothing we install replaces the people who keep the network safe.

Every service account we use is yours to audit. Builds log what they read and what they propose, timestamped, in the client's own environment. No build changes production data without approval from a named person on the client's side.

Campaign Manager, one of the systems that runs our own companies, drafts a recommendation and tries to prove it wrong before any person sees it. A person approves or declines, and we check the result against the prediction we recorded before the change. Every build follows that pattern.

Every build is a fixed fee, agreed in writing before work starts. The spec lists the systems the build touches, the access it needs, who approves changes, and what the tool logs. If work would exceed the spec, it stops until the spec is re-agreed on paper.

The client owns what we build. None of that is contingent on keeping us around. When we hand a tool over, we hand it to the client's team, with training. Software needs maintenance. Here's what's yours to run, and here's the optional support arrangement if you'd rather not.