Skip to main content

Sovereignty

Autoheal is built for teams that have to prove where their data lives and what an agent is allowed to do. This page covers the two deployment models and the governance controls that apply to both.

For platform security posture, including encryption, certifications, vulnerability management, and incident response, see Security.

Deployment models

Autoheal offers two deployment models. Governance controls, authorization boundaries, and approval policies are identical in both; the difference is where the platform runs and where your data comes to rest. See Architecture for how the platform is built.

Fully-managed SaaSBYOC (Bring Your Own Cloud)
AvailabilityDefaultPaid add-on
Runs inAutoheal's cloudYour own cloud account
Data at restAutoheal's infrastructure, logically isolated per tenantYour infrastructure, inside your VPC
LLM inferenceAutoheal-managed model providersYour LLM provider (Bring Your Own Key)
UpgradesAutomaticYou control the upgrade window
Best forMost teams, and the fastest path to a first agent runStrict data residency, regulatory, or contractual requirements

Fully-managed SaaS

The default. Autoheal runs the platform and you connect your tools. Your environment is logically isolated from every other tenant, your data never crosses a tenant boundary, and you get upgrades as they ship. This is the fastest path to a first agent run and the right choice for most teams.

BYOC (Bring Your Own Cloud)

Available as a paid add-on. See BYOC for the deployment architecture. The entire Autoheal stack is deployed inside your own cloud account, so all data, including investigations, memories, skills, and agent run traces, stays contained in your environment and never leaves it. You control the upgrade window, and LLM inference can be routed through your own provider accounts so prompts and completions stay within your contractual boundary too.

BYOC is the right choice when a data residency requirement, a regulatory regime, or a customer contract means production telemetry cannot leave your infrastructure. Contact support@autoheal.ai to enable it.

Agent governance

Governance controls apply identically in both deployment models.

Authorization boundaries

Every agent has an explicit allow-list of integrations it may reach. Nothing outside that list is reachable, and the boundary is enforced by the platform rather than by instructions in a prompt, so an agent cannot talk itself into a data source it was not granted.

Read and write access are granted separately. Most agents are read-only; write access is granted deliberately for the specific cases where an agent needs to post a result back, such as commenting on a pull request. See Custom Agents for how allow-lists are configured.

Approval policies

Approval policies are set by engineers and scoped at the team level, so each team governs how much autonomy its own agents have. When a run produces a result that requires a decision, the agent flags it for review instead of acting unattended.

Nothing is applied to your systems automatically. Autoheal suggests; your team decides. See Governance Policies for how approval rules are written and evaluated.

Audit

Every agent run is recorded with its trigger, the integrations it queried, the context it loaded, each step it took, and the conclusion it reached. Combined with the evidence behind each conclusion, this gives regulated environments a complete and queryable record of what an agent did and why. Every tool call and approval decision is queryable in the Audit Trail. See Roles & Permissions for access control over these records.

Cost governance

LLM inference spend is governed alongside access. Autoheal tracks model spend per agent and per team, so platform owners can see which agents are expensive and set the dial between cost and autonomy rather than discovering the tradeoff on an invoice.

Under BYOC, inference routed through your own provider accounts appears on your existing cloud bill and within your existing commitments. See Agent Context for how per-run cost is reduced.

Data residency

Under fully-managed SaaS, data residency options are available for storage location; see Security. Under BYOC, residency follows your own cloud account, so data comes to rest in the regions you deploy into and nowhere else.

In both models, your data is never used to train AI models without your explicit consent.