Model providers
Customer model keys are used by default, so model access remains tied to the provider account the customer controls.
Developers · Hosting
Where Deixic runs, and who holds each key.
Managed Deixic runs its application and application data on Google Cloud Platform, with Cloudflare for DNS, TLS, and traffic proxying. Fixes to your systems run with credentials you scope at each provider, and every change is recorded in the action record.
Private deployment · Available
Run Deixic on customer-operated Kubernetes.
Download versioned Helm charts and checksums, then agree on image access, identity, encryption keys, storage, and network requirements with Deixic before installation.
Credentials
Bring model keys by default and limit each connection.
Connected systems
Connector profiles and tools can be scoped by team or person and inherit the permissions granted at the provider.
Credential references
Policy decides before a credential is resolved. Tool-call records point to credential references rather than exposing secrets in the action history.
Credential operations
Connection health is visible, and managed credentials can be rotated or revoked from Deixic.
Private Runners
Apply fixes from machines inside your network.
Deixic stays hosted while the work runs on your own Macs, Linux machines, containers, and Kubernetes clusters, so a fix to a system behind your network runs inside it.
Outbound connection
The runner connects out to Deixic, so nothing on your network has to accept inbound traffic.
Short-lived credentials
Runners get short-lived credentials, and a person’s own sign-in never lands on the machine.
Same approval policy
Tool calls on a runner go through the same approval policy as hosted work.
Watch or take over
Follow a job from the app, take control when you need to, and hand it back.
Data agreements
Set retention and confirm residency during procurement.
Retention is defined in the enterprise agreement; residency is confirmed during procurement, and no universal default is published.
Production rollout
Start with one failing control and its real approval owner.
- 01Choose one failing SOC 2 control or consequential production tool call and identify its target system.
- 02Connect the provider with only the permissions that action needs.
- 03Define the allow, deny, or approval rule and name the decision owner.
- 04Run the path and verify the request, decision, read-back, cost, and result in activity history.
- 05Add the next action, connected system, agent, or business unit after the first path is operating.
Continue the security review.
Review the procurement path, trust controls, and service status.