We label what is implemented, what is a design goal, and what is contractual. No claim floats.
Trust & Security

A named human owner, not a black box.

A named human owner. Customer approval policies. Role-based access. Tenant boundaries. Export and exit rights. These are the controls the engagement is designed around, not a claim that every action is uniformly policy-checked and evidenced today.

Solace Delegated Access uses OAuth 2.0-compatible least-privilege scopes and local session controls. Evidence and access logging exist for specific approved actions, not as a universal, always-on enforcement layer — ask what is covered for your engagement.


Data-flow architecture

Scoped mediation for supported workflows.

Supported cloud-proxied actions route through solaceagi.com so LLM API credentials, tenant-scoped storage, and integrated services can be managed without exposing third-party provider keys to the desktop runtime.

worker → ExecutionContext → solaceagi.com (cloud proxy) → LLM / storage / integrations

For supported, integrated actions, activity passes through mediated endpoints so that logging, budgeting, and tenant scoping can be applied to approved workflows. This covers agreed integrated workflows rather than serving as an unconditional, always-on filter across all desktop networking.

Controls

What's in place.

Implemented

Cloud proxy egress

Supported model calls and cloud state route through solaceagi.com. Solace provisions and manages LLM provider credentials so you never paste third-party API keys.

In progress

Per-tenant isolation

Each customer has its own tenant scope, and access checks enforce it on customer data such as CRM records, messages, files and e-sign. The remaining routes are being brought under the same check; cross-tenant access is treated as a defect, never a setting.

Implemented

Managed LLM credentials

solaceagi.com holds core LLM API credentials on the server side. You do not need to supply or manage external model keys for standard workflows.

Implemented

Evidence logging

Evidence and access logging exist for specific approved actions and supported workflows, recording the approved action so the customer can review what ran.

Implemented

Delegated access

Supported integrations use least-privilege scopes and local session controls; applicable access and review terms are set for the connected service.

Implemented

WorldData separation

Public and licensed market data maintains documented separation and sources from customer records, and your engagement scope identifies how data is used.

Design goal

SOC 2 posture

We build to SOC 2 control practices. We do not yet claim a completed SOC 2 audit; when one is complete, it will say so here with a date.

Contractual option

HIPAA / BAA

For qualifying healthcare engagements, a Business Associate Agreement and hardened deployment are available as a contracted option — not a default claim.

Contractual option

Self-host / on-premises

Regulated customers can run Solace on-premises through DragonTech Private AI under a premium license. We make no air-gap promise.

Our claims rule

If it isn't real, it isn't here.

Every security statement on this site must be one of four things: a control implemented today, a certification actually completed, a design goal clearly labeled as such, or a customer-specific contractual option. Anything that doesn't fit one of those is removed — including any older "OAuth3", absolute-guarantee, or unearned-compliance language you may find cached elsewhere on the web. Those pages are being retired.

We explicitly disclose that logging and automated checks exist for specific approved actions, not as an unconditional, always-on universal enforcement layer across all desktop software.