<!-- Markdown twin of https://hstlrlabs.xyz/security -->
<!-- Canonical HTML: https://hstlrlabs.xyz/security -->
<!-- Source of truth: src/lib/site.ts (generated at build time) -->

# How I handle your systems and your data.

Your data stays in your environment. The software runs on your own accounts and keys, nothing you share is used to train a model, and you own the source with a clean exit. Here is exactly how each of those holds, specific enough for an IT or security review to check line by line.

## Where your data lives: on your infrastructure, not mine.

The system runs on your own cloud, your accounts, your API keys, and your storage. I do not host your data, and I never log into your systems. I build each integration and prove it against the service's own test environment, then hand you clean, working code with the connection points defined. You plug in your own keys and link your own services, so your credentials and your live systems never pass through me.

- Your data and your credentials stay inside your environment, under your access controls.
- I build and prove the code on my machine, against synthetic data and each service's own test environment, never your production records.
- You connect your own keys and services to the finished code. I never make the live connection or touch your production systems.

## Training: your data is never used to train a model.

Not mine, and not a third party's. Models run on your own account with a major provider, OpenAI or Anthropic, on business-tier terms that do not train on your inputs and meet standard compliance like SOC 2. I name the exact provider and tier in a data processing agreement. When a workflow needs a model, it runs on your account under your terms, so the data boundary stays yours end to end.

## How I build without your data: against the shape of your data, not the contents.

I develop against your field names and formats, a few sample or scrubbed records, and the test environments the tools you already use provide. The workflow is proven in a contained spot where a failure costs nothing. Your live systems connect at the very end, when you plug in your own keys, and the code ships with a test you run to confirm each connection works.

## Integration and reliability: wired into what you have, built to recover.

The system connects to your existing tools through adapters at defined points, so it fits your stack instead of forcing you onto a new one. It is built and staged the way real software is: separate development, staging, and production, with changes tested before they ship.

- A human approves anything customer-facing or high-risk before it goes out.
- Failures are caught and logged inside your environment, visible to your own monitoring or SIEM, with retries and a defined recovery path. Nothing sensitive is logged on my side, because at runtime there is no my side.
- A health check confirms each integration is wired correctly before go-live and after every change.

## What it's built with: built in your stack, so your team can maintain it.

I am not locked to a single language or framework. Because I direct AI agents to build, the work is matched to your environment instead of forced into my favorite tool: if your team runs Python, it is Python; if it is Node, C#, or something else, it is that. It runs on your infrastructure the way that fits, a container or serverless functions, and what you get is ordinary, readable code in a stack your own developers already support, not an exotic framework only I understand.

## Ownership and licensing: you own your product, and you are never locked in.

You are not renting access to a black box. You get the working software as source, delivered into a private repository you control, and the terms below are written into the agreement, not just promised here.

- The workflow built for you is yours outright. The reusable engine underneath it, a framework I reuse across clients, is licensed to you under the [PolyForm Internal Use License](https://polyformproject.org/licenses/internal-use/1.0.0), a recognized source-available license: run it and modify it for your business forever, you just do not resell it.
- The engine source is not obfuscated. You or your engineers can review it under NDA before you sign, and you receive the full, readable source at delivery.
- Delivered as source into a private repository you control, with that license file in the repo and versioned, tagged releases. Every version is yours to keep and run forever, with or without ongoing support.
- New versions come as paid updates when you ask for them. The right to run what you already have never expires.
- Clean exit: take it in-house or to another vendor whenever you want. Nothing important sits on my side.

## Secrets and access: least access, and it is revocable.

- Credentials and API keys live in your environment, never committed to the repository and never pasted into an AI tool.
- Any access I am granted is scoped to what the work needs, and it is revoked at handoff or scoped down for ongoing support.
- I avoid sensitive medical, legal, financial, child-related, payroll, or HR data unless the privacy scope is agreed in writing first.

## If I am unavailable: the system does not depend on me.

It is one person, so the honest answer to "what if he disappears" is that you are not dependent on me, by design. You own the source, it runs on your infrastructure, your team gets a runbook and a walkthrough, and the system keeps running whether I am there or not. When a third-party API eventually changes and a piece needs updating, that is a small, scoped fix: I do it on a paid basis when you want me to, or your team does it from the runbook and the source. No retainer to keep paying, and no dependency you are stuck with.

## Reference architecture: the shape of it, on one screen.

A representative shape, not a diagram of a past client. Everything that touches your data sits inside your environment. Your data plane (CRM, database, inbox, files) and the engine both run inside your environment; the engine reaches your data through adapters, with approval gates and logging in between. I maintain the engine's code against synthetic data on my own machine; your real data only moves inside your environment and never lands on mine.

## The paperwork: in writing, before anything starts.

A simple contract stack covers it: a services agreement, a per-project scope, a mutual NDA, and a data processing agreement. The data handling, the no-training commitment, and the ownership and no-lock-in terms on this page all live in that paperwork, so they are enforceable, not just stated.

## Ask: send the hard questions.

If you are the one signing off on a vendor, send me the questions your review needs answered. Clear answers, in writing, before any access is granted. hello@hstlrlabs.xyz. I read every message myself.
