How AISO
is built.
One framework in your network sits between everyone who uses AI and everything AI touches. People chatting, builders making agents and developers in their coding tools pass through the same policy layer, and every decision lands in one audit log.
The layers
Every surface enters through the same identity and policy layers. Nothing reaches a model or a data source around them.
Where people work
SurfacesThe Studio in a browser, Slack, Microsoft Teams, email, published chat pages, coding tools, CI pipelines and the command line.
Who is asking
IdentitySingle sign-on over OIDC, SCIM provisioning, roles, developer sign-in with short-lived tokens, CI keys, and service accounts that have to be declared.
What is allowed
Policy, one layer for every surfaceClassification levels and clearances, model ceilings, the cloud-model lock, pinned models, budgets and rate limits, approvals, project rules, and pre-send checks from certified packs.
What does the work
Agents, knowledge, toolsThe chat router and agents, workflows and schedules, knowledge stores with hybrid search, MCP tools and data sources, the developer gateway, and packs.
What answers
ModelsCloud providers on your key, open-weight models on your machines, and models shared by other AISO machines, with routers and failover.
What is kept
The recordThe hash-chained audit log, the usage ledger, signed answer records, keyed fingerprints of what was sent, code attestations and the signed evidence bundle.
One process holds the Studio, API, gateway and schedulers. Data sits in SQLite, or Postgres for a cluster, with vector search in the same database, so there is no separate vector service to run.
The checks one request passes
Every call to a model runs these in order, whatever surface it came from. In monitor mode the classification checks record what they would have refused instead.
- Who is this?Account, developer token or CI key. A disabled account’s tokens stop at once.Unknown: anonymous rules
- May they use this?Role, agent access, project membership.No: offered an access request
- What may they read?Their clearance against each document, table or file.Above clearance: withheld
- May this model see it?The model’s ceiling, local-only levels, the cloud lock, the pinned model.Too sensitive: refused, local model named
- Is anything leaving that shouldn’t?Fingerprints of classified code, and a pre-send check where a level requires one.Match: refused
- Is there budget?Per person, per model, per project, and requests per minute.Spent: refused, or moved to a local model
- Record itA usage row. Cloud calls and every refusal go into the hash-chained audit log.
Deployment shapes
The same binary in every shape.
One machine
A Mac, Windows or Linux host running everything, with SQLite and a model engine beside it.
Hub and nodes
A hub enrols other AISO machines and sends them signed policy. Nodes share models and agents over signed HTTPS, and an answer computed on a node keeps its query results there.
Developer laptops
A small loopback service with no database. Routine calls go to the laptop’s own model and the rest go to AISO, as the developer. It keeps working offline on local models.
Active/active cluster
Every replica serves chat, the Studio, the API and the developer gateway at once, from one Postgres store. There are no sticky sessions, so a conversation continues on any replica. We tested it with three replicas, including killing the scheduling replica mid-run.
Nodes share, the hub sets the floor
A hub holds classification, budgets, roles and what may leave the building. Nodes take those as a minimum, cache the signed roster, and keep enforcing them while the hub is away.
What leaves the building
Everything outbound, what it carries, and the switch that stops it. There is no telemetry and no call home.
Stays on your machines
Accounts, settings and the audit log. Documents, embeddings and the knowledge graph. Conversation history and agent memory. Answer records and their query results. Open-weight models and every prompt sent to them. Code maps and fingerprints, never source code.
| Can leave, when you configure it | What it carries | How to stop it |
|---|---|---|
| Cloud model providers | Prompts and documents at levels the model is cleared for | No cloud entries, or the server-wide cloud lock |
| Data sources over MCP | The question, and the person’s own access token | Don’t add the server |
| Identity provider | Standard sign-in requests | Local accounts only |
| Slack, Teams, email | Messages in the channels you connect | Don’t attach the integration |
| Other AISO nodes | Tasks for shared models and agents | Federation is off by default |
| Hugging Face | A model’s name, when an admin downloads it | Pre-load models, then block the host |
See it on your own machines
We’ll run AISO against your identity provider and a slice of your data, then scope a deployment. Two weeks to production, or your money back.
Book a Demo