SECURITY · DEPLOYMENT FACTS

Written for the person
doing the security review

Send your architecture team this page. It covers the model we build for you and, separately, the platform you can deploy alongside it, answers what they are going to ask anyway, and says plainly where our answer is we do not claim that.

Model builds · start here

A training run is a different review from a deployment

Start here, because this is what most people are reviewing us for. During a Foundry engagement we handle your training corpus, which is usually the most sensitive data you hold, and the controls below are enforced by the runner rather than by a clause in a contract. The second half of this page covers Bonacci Studio, which is a separate product you may not be buying at all.

Where does the corpus live?
In the environment the run executes in, and you choose which that is. On your hardware or inside your air gap, the corpus never moves to us at all. On our GPUs it does move, under a written engagement that names the retention period and the deletion date, because pretending otherwise would be the kind of claim this page exists to avoid. If that is unacceptable, the other two modes exist for exactly this reason.
Can a build run air-gapped?
Yes. A job can be pinned to statically registered machines, which means nothing in the pipeline holds credentials that could create infrastructure or move data. A job that declares no egress and also names a cloud provider is refused before it starts, because those two claims contradict each other.
How is PII actually handled?
As a build step, not an assurance. The corpus is scanned and gated before compute is spent, the result is a report with counts by category, and a corpus that fails the gate does not proceed to training. Lineage is emitted, so you can answer which source rows produced which model version.
What if an engineer disagrees with a check?
They can override it, because sometimes the rule is wrong. They cannot override it silently: an override requires a written justification, and that justification is stored in the run report beside the check it suppressed. The audit trail is a file on disk written as the run proceeds, and it exists whether or not anyone opens a dashboard.
Is the run you performed the run we approved?
The job specification is content-addressed, so the configuration that ran is provably the one you signed off. A resumed run whose specification has changed is refused rather than quietly continued, because a run with different hyperparameters is not the same run.
Who ends up owning the weights?
You do, outright. Delivered as safetensors and GGUF with the eval harness and training configuration. There is no licence to renew on the model and no call-home in it. We keep no copy unless you ask us to hold one.
What do you keep afterwards?
You receive the weights outright, in safetensors and GGUF, with the eval harness and the exact training configuration. We keep no copy of your corpus or your weights unless you ask us to hold one, and if you do, it is written into the engagement rather than assumed.
Verify it yourself

The job specification is the evidence

The guardrails on a training run are a file your team reads before anything starts, not a paragraph we wrote about ourselves. A run that violates one is refused rather than flagged.

  jobspec.yaml
# the guardrails your reviewer reads

guardrails:
  no_egress: true
  max_spend_usd: 8000
  max_wallclock_hours: 72

placement:
  # blank provider = registered machines only.
  # nothing here can create infrastructure.
  provider: null
  region: eu-west-1

corpus:
  pii_scrub: true
  dedup: true

claims:
  delivery_terms: owned_outright
Platform deployment · only if you buy it

The control is the deployment model, not a certificate

This half applies to Bonacci Studio, the optional platform. A delivered model does not require it and nothing in this section applies to a Foundry engagement on its own. Studio runs on hardware you own, inside a boundary you already defend. Your firewall rules are the enforcement, and nothing here depends on trusting a promise we made in a questionnaire.

Where does it run?
A Docker Compose stack on infrastructure you own: VPC, private data center, or an isolated network. Images can be mirrored into your own registry.
What talks to the outside?
In a self-hosted deployment, nothing in the install path requires a call to us. Inference defaults to a local endpoint, and payment processors are disabled entirely.
Where does the AI run?
Against your model server: Ollama or vLLM on your GPUs. If you choose to permit egress, you can point it at a commercial API with your own key instead.
How does licensing work?
A signed licence key validated offline against a signature on your machine. There is no licence server, no activation call, and no usage metering.
Who can log in?
Your directory. LDAP / Active Directory / OIDC single sign-on, with local accounts optional and self-registration disableable.
What about our data at rest?
Your PostgreSQL and your object storage, on your infrastructure, under your encryption, backup, and retention policy.
Can it run air-gapped?
Yes. Offline install from mirrored images, a local model server, and an offline licence. We will do the install with your team on a machine with no route to the internet.
What telemetry do you collect?
From a self-hosted deployment, none. There is no usage reporting, no crash upload, and no analytics beacon in the product. This website has Google Analytics; the product you run does not.
Verify it yourself

The deployment configuration is the evidence

You do not have to take the paragraph above on trust. This is the real on-premise configuration, and your team can read every line of it before anything runs.

application-onprem.properties
# the real config. no hidden endpoints.
deployment.mode=onprem

# inference points at your box, not ours
OPENAI_BASE_URL=http://localhost:11434/v1  # ollama

# no billing calls, no licence server
razorpay.enabled=false
paddle.enabled=false

# your directory, your mail, your storage
LDAP_ENABLED=true
MAIL_HOST=smtp.internal

What we do not claim

We do not hold SOC 2, ISO 27001, or HIPAA attestation, and we will not tell you otherwise to get through a procurement gate. We are a small company in Hyderabad. When we have an audit, it will be on this page with the report date.

We also do not publish an uptime SLA for self-hosted deployments, because we do not run them. Availability is your infrastructure. What we do commit to in the licence is a named support engineer and an agreed response time.

If your process requires a certified vendor, we are the wrong supplier today and we would rather say so now than in month four of a procurement cycle. If your process cares about where the data physically sits and who can reach it, keep reading, because that is the part we are built for.

Next step

Bring your security team to the call

We will walk your architecture and security reviewers through the guardrails on a training run, the job specification, the network boundary, and, if Studio is in scope, the compose file and the licence mechanism. Then we answer the questions this page did not. Bring the questionnaire if you have one.

Book the corpus audit · free Email the team