Security — SpeyAI

The perimeter

One way in.

Everything SpeyAI works across is already yours and already inside your environment: your version control, your cloud, your model account, your database, your object store. The organization doing the work runs in there with them. One link crosses the boundary in the other direction: the release channel that delivers SpeyAI itself, which your environment opens and which only ever brings software in.

01Your Version Control
02Your Cloud
03Your Model Account
04Your Database
05Your Object Store

One link crosses the boundary. It brings SpeyAI in; nothing of yours goes back out.

The posture

Three pillars.

Model · Self-hosted / no data custody

Self-hosted by design

SpeyAI is deployed in your own infrastructure. H2 Consulting Group does not host your instance and does not take custody of your operational data. There is no central service holding customer data, so there is no cross-customer leakage vector to defend against. The isolation is structural, not promised. Where an evaluation calls for it, your reviewers may read the source under NDA.

Standards · OIDC SSO · optional RBAC

Enterprise identity and access

SpeyAI authenticates through the identity provider you already run, over OIDC single sign-on. Okta, Auth0, and Entra ID are first-class. Optional in-instance role-based access control (operator, auditor, admin) ships off by default, so a read-only auditor seat for the CISO is one config flag away. Because SpeyAI is white-label and self-hosted, it plugs into your IdP rather than forcing a single vendor.

Status · DPA not applicable

Zero-training policy

Your prompts, your agents’ work, and your operational data are never used to train AI models. SpeyAI runs on Anthropic’s Claude models across four transports, each configured within your environment, and your competitive information stays yours.

SpeyAI is self-hosted; H2 Consulting Group does not process your operational data, so a Data Processing Agreement generally isn’t required.

The SpeyAI difference

Governance is the security story.

Beyond isolation and identity, SpeyAI’s security value is the governance architecture itself: every agent has a defined role and a chain of command, and every action answers five governance questions enforced through the pipeline: what it touches, what it spends, who approves, what ships, and what gets logged.

▦

What it may touch

Question 01 · scope

◔

What it may spend

Question 02 · budget

◎

Who approves

Question 03 · never self-approved

✓

What ships

Question 04 · a human signs

▤

What gets logged

Question 05 · forensic record

Those five answers are enforced for as long as the org is running.

A refusal is not a loss. When a gate refuses a change, the work is not thrown away and it is not left half-finished somewhere nobody is looking. It is recovered, re-scoped, and sent back through. The record keeps both the refusal and what happened next.

This is the question a security reviewer asks after the demo is over. A control that stops things is easy to build and expensive to live with if stopping is all it does.

A failed run parked in the console's work queue with Retry, Resolve and Inspect on the row, and the replay it triggered standing on the audit record below. — The failure parks with its payload intact, the fix is a control on the row, and the fix itself lands on the record.

And when you want all of it stopped, one control does it. The console takes the reason before it trips.

The console after the kill switch is tripped: the organization halted, every lane parked where the pipeline caught it, and the override stated on the record. — The kill switch stops every lane at once, and the console takes the reason on the record before it trips.

Controls of this shape are not unique to us, and a reviewer comparing vendors will find them elsewhere. What is different here is that the organization doing the work and the gates refusing it were designed as one system, so there is no seam between the thing that acts and the thing that stops it.

Five agents or five thousand… one chain of command.

In the database

Row-level scoping.

Every tenant-scoped query is scoped explicitly at the application layer and backed by row-level security in the database.

Row-level security · Pattern C

policy · agent_runs

CREATE POLICY tenant_isolation ON agent_runs

USING (workspace_id::text = current_setting('app.workspace_id', true));

The , true makes the setting return null instead of throwing when unset; the ::textcomparison keeps both sides text. This is SpeyAI’s canonical scoping pattern, applied on every tenant-scoped table.

Why this page is short

Short on purpose.

A security page is usually long because the vendor is holding your data. That obligation has to be answered in writing: how your records are segregated from every other customer’s, who inside the vendor can reach them, what happens when there is an incident on their side of the line, and which certifications stand behind the rest.

SpeyAI runs inside your perimeter. There is no shared service holding your data, so there is nothing to segregate. There is no tenant boundary, so there is nothing to breach across. Most of the questions that fill those pages are not answered briefly here. They have no subject here.

That is a statement about surface, not a guarantee. Software you run is still software you have to run well, and the controls on this page are worth exactly what your operation of them is worth. What the architecture removes is a whole class of question, and it removes it by not creating it.