> For the complete documentation index, see [llms.txt](https://docs.algenta.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.algenta.ai/trust-and-security/overview.md).

# Trust overview

Who is responsible for what across Algenta's deployment modes, and exactly which parties ever see your data.

This section is written for a security review, not for an operator. For how-to instructions on any control mentioned here, follow the link into [Deploy & Operate](/deploy-and-operate/self-hosting.md).

## Shared responsibility, by deployment mode

Responsibility is not the same in every mode, and stating it as one blanket line would hide that. The engine reports its own `deployment_mode` (`self_hosted`, `air_gapped`, `vpc`, `hybrid_provider`, or `saas`) in the privacy report at `GET /v1/admin/privacy-report` — check which one applies to a given install before reading the row below.

| Control                                                | Self-hosted / air-gapped                                      | VPC / hybrid                        | SaaS                                      |
| ------------------------------------------------------ | ------------------------------------------------------------- | ----------------------------------- | ----------------------------------------- |
| Runtime infrastructure (compute, network, OS patching) | You                                                           | You (VPC) / Shared (hybrid)         | Algenta                                   |
| Customer data at rest and in transit                   | You                                                           | You                                 | Algenta, per your configuration           |
| Encryption keys (BYOK)                                 | You generate, hold, and rotate                                | You generate, hold, and rotate      | You may supply; Algenta holds the default |
| Identity provider configuration (Entra/OIDC/API keys)  | You                                                           | You                                 | You                                       |
| License activation and device binding                  | You (offline-capable)                                         | You                                 | Algenta                                   |
| Application updates                                    | You choose when to pull a new image                           | You choose when to pull a new image | Algenta                                   |
| Egress and telemetry policy                            | You (default: outbound network and cloud/telemetry paths off) | You                                 | Algenta defaults apply                    |
| Backups                                                | You                                                           | You                                 | Algenta                                   |
| Vulnerability remediation in the engine                | Algenta ships the fix; you apply it                           | Algenta ships the fix; you apply it | Algenta applies it                        |
| Audit log custody                                      | You (your database)                                           | You                                 | Algenta, exportable by you at any time    |

The one constant across every mode: [audit evidence](/trust-and-security/audit-and-evidence.md) is always yours to export, and [governed-execution](/trust-and-security/governed-execution.md) controls apply identically regardless of where the engine runs — they are enforced in application code, not by network placement.

## Subprocessor statement

**Fully self-hosted or air-gapped: no Algenta-hosted subprocessor touches your runtime data plane.** The engine that stores your decisions, executes your plans, and holds your audit log is the process you deployed, on infrastructure you control. That is what `deployment_mode: self_hosted` or `air_gapped` — enforced by the [egress policy](/trust-and-security/data-boundaries.md), not merely asserted by this page — is.

Outside the runtime data plane, two categories of processor exist regardless of deployment mode, because they are how you obtained and are licensed to run the software, not how it runs:

* **Software distribution**: the container/package registries the image or package is pulled from (GHCR, PyPI, npm).
* **Commercial relationship**: license issuance and validation, account management, support ticketing, and billing (for paid editions) — processing account and support metadata, not your runtime decision data.

This is a scoped claim about the *runtime data plane* specifically. It does not extend to SaaS or hybrid deployments, where Algenta operates the runtime by design — see the table above.

## What this section covers

* [Governed execution](/trust-and-security/governed-execution.md) — the control statements behind every plan approval and execution: named denial codes, single-use approval binding, content-hashed policy snapshots.
* [Data boundaries](/trust-and-security/data-boundaries.md) — the egress classification matrix and what the SSRF guard blocks unconditionally.
* [Audit and evidence](/trust-and-security/audit-and-evidence.md) — the hash-verifiable export and what's in it.
* [Identity and access](/trust-and-security/identity-and-access.md) — the four separate identity mechanisms and why they don't fall through to one another.
* [API stability](/http-api/stability.md) — which paths carry a compatibility promise.
* [Capability status](/trust-and-security/capability-status.md) — every protocol surface and integration, labeled against the same three-status discipline this section uses throughout.
* [Protocol compatibility](/trust-and-security/protocol-compatibility.md) — MCP version negotiation, the Responses and Chat Completions surfaces, and the cross-framework conformance suite's actual results.
* [Architecture and trust boundaries](/trust-and-security/architecture.md) — where the engine, your model, and your MCP clients run relative to each other, as a diagram.
* [Evidence walkthrough](/trust-and-security/evidence-walkthrough.md) — the execution-receipt envelope and the audit export, worked end to end.
* [Security questionnaire](/trust-and-security/security-questionnaire.md) — the recurring vendor-review questions, answered directly and checked against this repository.
* [Supply chain](/trust-and-security/supply-chain.md) — what's SBOM'd and scanned today, and what isn't signed yet.
* [Threat model](/trust-and-security/threat-model.md) — a public summary: assets, threats, and the control for each.
* [Support policy](/trust-and-security/support-policy.md) — what's committed today and what's pending owner sign-off.

## What is not yet published here

A formal internal threat model (a public summary now exists — see [Threat model](/trust-and-security/threat-model.md) — but the fuller internal version is separate and not published), a documented incident-response process beyond [vulnerability reporting](https://github.com/thyn-ai/algenta/blob/main/SECURITY.md), tested backup/restore runbooks with stated recovery objectives, and a published support-tier/LTS commitment (see [Support policy](/trust-and-security/support-policy.md) for the honest placeholder that stands in for it today) are not here yet. Publishing any of them before they are true would be worse than the gap itself; they will land as they become real commitments rather than descriptions of intent.

## Next steps

* [Governed execution](/trust-and-security/governed-execution.md)
* [Data boundaries](/trust-and-security/data-boundaries.md)
* [Audit and evidence](/trust-and-security/audit-and-evidence.md)
* [Identity and access](/trust-and-security/identity-and-access.md)
* [Capability status](/trust-and-security/capability-status.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.algenta.ai/trust-and-security/overview.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.