Getting Started/Security and Compliance for Evaluators

Security and Compliance for Evaluators

What Trinity enforces, what it does not, and which edition each control is in. Written for security reviewers, procurement teams and partners who need to quote it in their own reviews.

Trinity release this page describes: v1.0.0 (final, 20 October 2026, tag ef8112ee8). Page date: 28 October 2026. Where a behaviour is already merged for the next release but not in v1.0.0, it is marked next release.

Companion page: How Trinity Keeps Agents in Bounds gives the design principles. This page is the facts, claim by claim.

Reliance

These answers describe Ability AI's published licences and current commercial practice as at 28 October 2026, by reference to Trinity v1.0.0 and the public repository github.com/Abilityai/trinity. They are provided for information. They are not a warranty, an offer, or a grant of rights beyond the published licences, and they create no obligation unless they are included in a written agreement signed by Ability AI, Inc. Ability AI's enterprise modules, trademarks and commercial terms are governed only by such a written agreement.

How to read this page
1. Supported platforms and deployment shape
2. What enforces approvals
3. Network isolation and egress
4. One instance serving unrelated parties
5. Spend controls and authentication
6. Models
7. Databases, backup and restore
8. Releases, upgrades and rollback
9. Managing several instances
10. Running without the implementer
11. Telemetry and outbound traffic
12. Which controls are Core and which are Enterprise
13. Licence, trademark and reliance
14. Third-party assurance, disclosure and support
15. A governed baseline we recommend
16. Not built — never claim
How this page is maintained

How to read this page

Every claim carries two markers so you can quote it in a security review.

Status. Documented = stated in this documentation or in the public source code's own documentation. Tested = covered by an automated test in the public repository. Unsupported = the product does not do this, or the documentation says not to rely on it. Unknown = we found nothing either way and are not willing to guess.
Edition. Core = the Apache-2.0 open-source platform; a control marked Core is in every install. Enterprise = in the closed enterprise modules, licensed separately. Not built = in neither edition.
Claims come from the v1.0.0 code and documentation and from the product capability sheet we maintain, never from memory. Where an answer depends on a commercial decision that has not been made, the page says nothing rather than imply a policy.
Links go to pages on this site or to the public repository. A reviewer who wants code-level evidence for an Enterprise control should ask for a session with the enterprise modules mounted; the public repository does not contain them.

1. Supported platforms and deployment shape

Short answer. The documented production target is a Linux server with Docker Engine, one Trinity instance per engine. macOS with Docker Desktop is a documented path for running Trinity on your own machine, not a documented server target. Two independent instances cannot share one Docker engine.

Claim	Status	Edition
The documented server target is Linux (Ubuntu 22.04 LTS or later, Docker Engine 24 or later). The documentation never offers macOS or Windows as a server.	Documented: Single-server deployment	Core
macOS with Docker Desktop is the documented “run Trinity on your own machine” path, with 8 GB of RAM given to Docker.	Documented: Local development, FAQ: hardware and OS	Core
Prebuilt images are published for linux/amd64 only. On an ARM host you build the images from source; the agent base-image build installs the native CLI for the host architecture and fails rather than ship a broken one.	Documented: FAQ: ARM hosts	Core
One-click images exist on the DigitalOcean, AWS and Vultr marketplaces, plus an install script for any Ubuntu machine.	Documented: Deploying Trinity	Core
Every platform service and every agent container carries Docker's `unless-stopped` restart policy, so when the engine comes back the fleet comes back and schedules resume. An agent you stopped on purpose stays stopped.	Documented: FAQ: after a reboot; Tested	Core
The backend does not recreate agents on boot; recovery relies on the Docker restart policy. A heartbeat marks an agent degraded after missed beats; there is no automatic restart of a degraded agent.	Documented in code	Core
`docker compose down` removes the agent network and orphans every running agent. Use `restart`; the recovery is documented.	Documented: Monitoring: recovery patterns	Core
Documented host sizes: 4 GB / 2 vCPU minimum, 8 GB / 4 vCPU recommended, 16 GB or more for larger fleets. Each agent container defaults to 4 GB memory and 2 CPUs (admin-adjustable); per-agent parallel capacity defaults to 3.	Documented: Sizing, Agent configuration	Core

Two instances on one Docker engine

Unsupported by construction, not by policy. All of the following are verified in the v1.0.0 compose files and backend code:

Platform service container names are fixed (trinity-backend, trinity-frontend, trinity-redis, trinity-mcp-server, trinity-scheduler, trinity-vector, trinity-otel-collector, trinity-postgres), as are the two network names. A second compose project on the same engine fails on the conflict whatever project name you give it. Documented in the compose files.
Host ports are fixed for the backend, the MCP server, the log collector and the metrics collector; only the web port is configurable. Agent containers are named agent-<name> with host SSH ports allocated from 2222 upwards, with no instance prefix. Documented; the port allocator is tested.
The roster reads every container on the engine that carries the Trinity agent label. An instance does not know which agents are its own, so a second instance would list, and could manage, the first one's agents. Documented in the code. This is the decisive point.

Recommended instead: one Linux host (cloud or on-premises) per instance, which is the documented production path; or one Linux virtual machine per instance, each with its own Docker Engine and IP address (Unknown: not tested by us). Separate macOS user accounts each running Docker Desktop are unsupported: the fixed host ports still collide. Unattended operation of a Mac (pre-boot disk password, auto-login, Docker Desktop at login, sleep) is unknown; none of it is covered by Trinity's documentation or tests.

2. What enforces approvals, and what can bypass them

Short answer. Trinity enforces approvals at two layers. The platform layer holds a request that names a gated skill before the agent ever sees it, and a person must approve it; this is enforced in the backend, outside the model and the prompt, on every runtime. The in-container layer applies on the Claude Code runtime: a second check stops the agent loading a gated skill outside an approved run, and guardrail hooks block a deny-list of dangerous shell commands and credential-file writes. What Trinity does not do is intercept every individual shell command, HTTP request or MCP tool call for approval. The documented design principle is “Trinity bounds agents by what they hold, not what they are told”: the control that holds is that an agent cannot send, publish, pay or delete with a credential it was never given.

Enforced outside the model, on every runtime

Control	Status	Edition
Gated skills. A skill on an agent can be marked as requiring approval. A request that names that skill is held at admission, before dispatch, for chat, tasks, schedules, loops, fan-out, inbound agent-to-agent calls, rooms and the Workspace. The request is frozen (text, model, tool list, timeout, a fingerprint of the skill). A person approves; the run executes exactly once with the approved input; if the skill definition changed in between, the request is marked stale instead of running. Agent and system keys cannot approve. An expired ask ends as not approved.	Documented: Approvals, Keeping agents in bounds; Tested (enforcement, check endpoint, hook registration)	Core. Addressing the approval to an approver or viewer role requires Enterprise; approval by the agent's primary person or an operator is Core.
Person-only platform settings. Autonomy (whether schedules fire unattended), capabilities, parallel capacity and the API-key setting accept only a signed-in person. An agent's key is refused even when the agent's owner is an admin. Creating API keys or changing a GitHub token needs a browser session.	Documented: Authentication: what a key is not	Core
Admin-granted self-change permissions. No agent may change its own or another agent's skills, schedules, instructions, agents or projects unless an admin grants that specific permission. Even with the permission, an agent can never lift its own read-only mode or guardrails.	Documented: Agent configuration, FAQ	Core
Agent reach. An agent's key reaches only itself, the agents it is permitted to call and the agents it spawned, on the MCP tools and on the backend's own routes. Permission to call an agent never includes permission to manage it.	Documented: Authentication: what an agent key reaches; Tested	Core
Credential custody. An agent holds only the credentials injected into it. Credential files are readable only by the agent's owner or an admin; agent, system and connector keys cannot read them, and refused reads are audited.	Documented: Credential management, FAQ: security	Core (the named-secret vault with per-agent grants is Enterprise)
Audit trail. Administrative actions (grants, key changes, logins, credential and autonomy changes, emergency stops) are appended to an audit log with the key that acted.	Documented: Audit trail	Core (dashboard and SIEM export are Enterprise)

Enforced inside the container, on the Claude Code runtime

Control	Status	Edition
A pre-tool-use hook checks with the platform before the agent loads a gated skill and blocks it outside an approved run. Registered in root-owned managed settings the agent cannot edit by ordinary means; fails closed when the agent has gates.	Documented; Tested	Core
Guardrail hooks deny-list dangerous shell commands (recursive deletes of root or home, world-writable permissions, piping a remote script to a shell, rewriting remote history, formatting disks, killing the init process, fork bombs, shutdown, `sudo` against the guardrail files, root shells), block writes to credential files and hook configuration, scan output for leaked credentials, and cap turns per run (200 by default, 1 to 500 per agent). If a hook errors, the tool call is blocked. Owners can tighten the baseline per agent, never loosen it.	Documented: Agent guardrails, FAQ: what guardrails block; Tested	Core
Read-only mode: a hook stops edits to source files while allowing designated output folders; the switch is a root-owned file.	Documented: FAQ: read-only mode	Core

Coverage by runtime

The platform layer is the same on Claude Code, OpenAI Codex and Gemini CLI. The in-container layer applies on Claude Code. We recommend Claude Code for any agent that holds a credential or has a gated skill; use Codex or Gemini for isolated drafting or analysis agents that hold nothing.

In-container control	Claude Code	OpenAI Codex	Gemini CLI
Gated-skill check inside the agent	Yes	No	No
Guardrail hooks (shell deny-list, credential-file protection, leak scan)	Yes	No	No
Read-only mode	Yes, via a hook	Yes, via Codex's own read-only sandbox	No
Turn cap per run	Yes (200 default, 1 to 500)	No	No
Per-agent disallowed tools	Yes	No (logged, not enforced)	No

Documented: Keeping agents in bounds: coverage by runtime, Agent runtimes. All three runtimes run with their interactive permission prompts turned off, which is what makes unattended operation possible; Codex runs in its full-access sandbox unless read-only mode is on.

Paths that bypass the gate

These are documented limits. Design around them rather than discover them.

No per-action approval. A plain shell curl, an HTTP call from a script, or an MCP tool call such as sending a message is not held for approval. The gate matches skills named in the request; it does not inspect effects. Approvals bound to the exact effect (amount, payee) are planned, not built. Documented (planned list).
The agent user has passwordless sudo inside its own container. The in-container hooks catch accidents; a determined agent could rewrite or route around them. The documentation says this plainly and says the boundary that holds is outside the container. Documented.
Edits an agent makes to its own files inside its container are not gated in v1.0.0. Documented in the release notes.
A raw credential plus a shell reaches past the skills. If an agent holds a mail, payment or publishing credential, it can use it without going through a gated skill. Credential custody is the control. Documented.
The “ask before irreversible actions” guidance in the platform prompt is prompt text only, with no technical enforcement. Unsupported as a control.

How to get “a human approves every send, publish, spend, deletion and permission change”

Achievable with what ships, as a design rather than a switch:

Drafting agents hold no sending, publishing or payment credentials. They produce drafts, reports and asks.
Each outbound capability lives in one skill on one agent that holds the credential (the “one key, one agent” pattern), and that skill is marked as gated. Every send then arrives in a person's Inbox as a frozen request and runs once on approval.
Deletions of agents and permission changes already require a person; an agent key is refused.
Run those agents on Claude Code so the in-container check and guardrails apply.

3. Network isolation and egress

Can an agent's outbound traffic be restricted to named domains? No, in either edition. Per-agent outbound allow-lists are planned, and the documentation states: “Agents can reach the open internet today. There is no outbound allow-list yet.” Documented, Unsupported. If egress restriction is required, apply it outside Trinity at the host or VM firewall or an egress proxy on the Docker network; Trinity will neither configure nor verify it. The platform itself needs outbound HTTPS for image pulls and model API calls.

Control	Status	Edition
Agents run on a separate Docker network from the platform's data stores. Agents have no route to Redis, the scheduler or the log aggregator; only the backend and MCP server bridge both networks, and every call through them is authenticated.	Documented: FAQ: platform database	Core
Agent containers run as a non-root user, drop Linux capabilities except network binding, run with no-new-privileges and a non-executable temporary filesystem.	Documented: FAQ: root	Core
Agent containers cannot alter their own network rules (the capabilities needed are dropped). On a provisioned cloud instance the installer's host firewall drops inbound traffic to containers from outside and blocks container traffic to the cloud metadata address; the hardening guide closes the public ports behind a tunnel or a private network. These rules govern inbound, not agent egress. Trinity sets no proxy variables and has no per-agent network setting.	Documented: Hardening; firewall rules documented in code	Core
All agents on an instance share one bridge network, and inter-container communication is not disabled, so one agent container can reach another agent's container address at the network level. The gap is recorded in the public requirements as a network-egress control that is not started.	Documented (requirements); Unsupported as a boundary	Core

4. One instance serving unrelated parties

Short answer. One instance can serve several organisations if each organisation's people are Workspace-only users and each organisation's agents hold only that organisation's credentials. The isolation is enforced at the API layer and is identical in both editions; Enterprise adds user and organisation management, the named-secret vault and per-agent people assignments on top. Two facts should drive the decision: an instance admin sees every agent and every conversation, and all agents on an instance share one Docker network. For unrelated parties with their own security reviews, a dedicated instance per party is the right call.

Boundary	Status	Edition
Agents. A person sees the agents they own or have been shared; an admin sees all. Non-existent and inaccessible agents answer identically, so agents cannot be enumerated.	Tested	Core
People. The `user` role is Workspace-only: it reaches the agents shared with it, its own chats and the Inbox, and is refused with `403 workspace_only` on every operator route, the API and MCP. A shared operator can chat, run tasks and view that agent's files and logs, but cannot change its configuration, credentials, schedules or permissions, nor re-share or delete it.	Tested (Workspace floor); Documented: Agent sharing, Roles and permissions	Core
Conversations. Each person sees only their own chat messages with a shared agent; only admins see all.	Documented: FAQ: sharing	Core
Credentials. Each agent's credentials are injected into its own volume. Credential files open only for the agent's owner or an admin; shared users, agent keys, system keys and connector keys are refused and the refusal is audited.	Documented; Tested (file tiers)	Core; vault Enterprise
Files. One workspace volume per agent; no shared filesystem by default. A shared folder is mounted only when the exposing agent enables it and the consuming agent has a permission edge to it; withdrawing the edge unmounts it.	Documented: FAQ: files; verified in code	Core
Delegated agents. An agent's key reaches itself, the agents it has an explicit permission edge to, and agents it spawned, on MCP and backend routes alike. Nothing else exists from its point of view, even when the same person owns both.	Tested	Core
Logs and audit log. Platform log routes and the audit log API are admin-only; per-agent logs follow the agent's access check.	Documented in code	Core (audit dashboard and SIEM export Enterprise)
Reports. Reports are read through the agent's access check; an agent key cannot publish as another agent.	Documented in code	Core
Rooms. The v1.0.0 release notes state rooms re-check every principal's access at wake time. We did not locate the enforcing code in this pass.	Documented (release notes); code Unknown	Core
Network between agents. See section 3: one shared bridge, inter-container communication enabled.	Unsupported as a boundary	Core

MCP keys. No separate scoping configuration is needed. An agent-scoped MCP key is checked against an allow-list before any tool runs: no permission edge, no call. A user-scoped MCP key carries its owner's role and shares, so a user key held by an admin sees everything an admin sees. On a shared instance, MCP keys for another party's people must be minted for Workspace-only accounts (which by default cannot mint keys at all) or not minted. Tested (agent-key allow-list); Documented (MCP integration, Authentication).

When a dedicated instance is the right call

The other party's security review asks who can see their data. On a shared instance the honest answer is “the instance admins see every agent and every conversation”. A dedicated instance makes the admin their own.
They need their own Enterprise features: the licence is per install, held by the organisation that owns it.
They need egress control, network separation from other tenants, or their own audit export. None of those can be separated per party on one instance today.
They will own the install later. Moving agents between instances carries runtime data only (section 7), so starting on a dedicated instance avoids a migration.

5. Spend controls and authentication for an unattended fleet

Is there a hard platform-level spend cap? No. Per-agent spend caps are planned. The fleet's daily cost figure is an alert, not a stop: it colours the admin cost view and pages nobody. Documented (Keeping agents in bounds, FAQ: operations). What does stop work:

Mechanism	Status	Edition
Agent loop budget. `max_cost_usd` on a loop ends the loop when exceeded, checked between runs, so one in-flight run can overshoot. Also: max runs 1 to 100, timeout per run, max total duration up to 7 days, max consecutive failures.	Documented: Agent loops; Tested	Core
Room budget. A dollar cap closes a shared multi-agent room; capped at $1,000 per room.	Tested	Core (the room-creation route is Enterprise)
Turn caps and execution timeouts bound compute per run. Task runs default to 900 s and chat runs to 1800 s, adjustable per agent from 60 to 7200 s; the turn cap is a Claude Code control.	Documented	Core
Subscription headroom alert at 75% of a subscription's weekly limit; the provider's own rate limit is the hard stop.	Documented: Subscription credentials	Core
Paid agent calls (Nevermined). A spending mandate with a cap, enforced by Nevermined, revocable by a person only.	Documented: Nevermined payments	Core
Stopping work. Stop one agent, quarantine it, or emergency-stop the fleet; these act at the container level and are runtime-independent. A running job can be terminated from the platform.	Documented; terminate Tested (Claude Code, Codex)	Core

The practical cap for an unattended fleet today is the model provider's own spend limit on the API key, set in the provider's console, plus separate keys per organisation or workload so one runaway cannot spend another's budget.

Authentication to the model providers

Trinity supports three ways to reach Claude: a Claude subscription token, a platform API key, or a terminal login; Codex takes an API key or a login; Gemini takes an API key only. Documented: Agent runtimes, Subscription credentials. Subscriptions are pooled: an agent whose subscription is rate-limited walks to the next one with headroom and then, if enabled, to the platform API key, inside the same run. Which credential served each run is recorded. Documented; Tested.

For work done on behalf of others we recommend API keys: one key per organisation (or per agent), with the provider's spend limit set on each key. They are metered and attributable, share no weekly rate-limit window across organisations, and are the organisation's to revoke. Whether a given provider's consumer subscription terms permit automated, unattended use is a question for that provider; Trinity's documentation does not address provider terms. Unknown.

6. Models

Local or self-hosted models are not a supported runtime option in either edition. Unsupported. The three runtimes are the vendor CLIs (Claude Code, OpenAI Codex, Gemini CLI) talking to their vendors' endpoints. There is no setting for a model gateway, an OpenAI-compatible endpoint, Ollama, vLLM, Bedrock or Vertex; the model catalogue holds the supported model ids, and a model id outside the known families is refused at the chat boundary. Documented in code; FAQ: other models.

7. Databases, backup and restore

Databases

Setup	Status	Edition
SQLite (default for a source-built install). Zero configuration. A migration guide declares SQLite end-of-support as of 1 September 2026; it still runs in v1.0.0. Treat PostgreSQL as the supported forward path.	Documented; Tested	Core
Bundled PostgreSQL (the compose `postgres` profile). The default for hosted and marketplace installs since v1.0.0: leave `DATABASE_URL` unset and the bundled database is used; `POSTGRES_PASSWORD` is required.	Documented; Tested, including real-PostgreSQL migration runs in CI	Core
External or managed PostgreSQL. Point `DATABASE_URL` at it; pool-size settings exist.	Documented: PostgreSQL setup	Core
Migrating SQLite to PostgreSQL. No turnkey data copy in the platform: the documented options are a fresh start on PostgreSQL or a manual per-table copy, and the cutover is one-way in practice. Moving back to SQLite is a configuration flip that restarts on the old file; no data flows back.	Documented: migration guide	Core

Recommendation: start every new production install on PostgreSQL (bundled is fine for a single host) so the question never arises. Schema upgrades on PostgreSQL run through Alembic revisions; SQLite has its own migration runner.

What must be backed up

Item	Status	Edition
Database (agents, schedules, executions, queued jobs, pending asks and approvals, settings, encrypted channel and subscription tokens, audit log). A nightly backup at 03:30 UTC plus a pre-migration copy at every boot, written to `backups/` under the data path, 14-day retention by default with the newest three always kept. Same disk as the source, so it protects against corruption, not disk loss. A stale or failed backup raises an Operations alarm.	Documented: Backup and restore; Tested (round trip)	Core
The `.env` file (`CREDENTIAL_ENCRYPTION_KEY`, `AGENT_AUTH_SECRET`, `SECRET_KEY`, `INTERNAL_API_SECRET`, Redis and PostgreSQL passwords). Not covered by the automatic backup: back it up yourself, off the host. Losing the credential encryption key makes every encrypted credential unrecoverable; losing the agent auth secret breaks every running agent's token until recreated. A key-rotation runbook exists.	Documented: FAQ: encryption key	Core
Agent workspaces (definition, skills, memory, history): one Docker volume per agent, not covered. If GitHub sync is on, the agent's repository is the backup for everything committed; runtime data under the agent's declared data paths is exported per agent.	Documented: Agent data	Core
Agent outputs and files shared to people: `agent-files/` under the data path is on the data path; the per-agent public volume is not in the database backup.	Documented	Core
Redis holds ephemeral state only (sessions, locks, rate windows, heartbeats, the event stream), all regenerated on start. Logs and archives are operational, not state.	Documented	Core

Restore, move, and duplicate schedules

Database restore is documented for both SQLite and PostgreSQL (stop the backend and scheduler, replace the file or restore the dump, start). A documented procedure for restoring or moving a whole instance does not exist; you assemble it from parts: restore the database, restore .env, recreate each agent from its repository and import its runtime data. Documented (database restore); Unknown (whole-instance move).
Moving agents between instances. The per-agent export and import carries the agent's declared runtime data only, not its schedules, shares or credentials; the documented pattern is export, recreate the agent on the destination from its repository, import. Documented; Tested.
Duplicate schedules. Schedules declared in an agent's template are created skipping by name, so re-provisioning from the same template does not duplicate them. Schedules created through the API or MCP have no uniqueness constraint on their name, so re-creating those by hand after a restore is the one risk. Tested (template dedupe); Documented in code (no constraint).

8. Releases, upgrades and rollback

Recommended release: v1.0.0 (final, 20 October 2026). The marketplace images and the install script resolve the latest final release, which excludes release candidates. Only the latest release receives security fixes. Documented: SECURITY.md.

Cadence. Final releases over the six months to v1.0.0: v0.6.0 (1 June 2026), v0.6.1 (12 June), v0.7.0 (23 June), v0.8.0 (8 July), v0.8.5 (26 July), v0.9.0 (17 August), v0.9.5 (17 September), v1.0.0 (20 October). Roughly monthly, with release candidates in between. Each release ships notes with an upgrade section and a mandatory “configuration keys whose behaviour changed” list. Documented: What's new.
Upgrading. Pin TRINITY_IMAGE_TAG to a release tag on a hosted install; an unpinned tag turns every re-run of the install script into an unscheduled upgrade. Upgrades run the pre-migration database copy at boot automatically. Documented: Upgrading, FAQ: upgrades.
Rollback after a database migration. Stop, restore the pre-upgrade database backup, check out the previous tag (or re-pull the previous image), start. There is no documented “downgrade the schema in place” procedure. Every PostgreSQL migration carries a downgrade step and CI exercises a full downgrade to base; the SQLite migration runner has no downgrade. A hosted install on bundled PostgreSQL cannot roll back to a release older than v1.0.0, because those releases' compose files have no PostgreSQL service. Documented (procedure, limit); Tested (PostgreSQL downgrades); Unsupported (SQLite downgrade).
Operator action per release. Each of the last three final releases carried required upgrade steps: v0.9.0 (rebuild the agent base image and recreate agents; remote template registry on; automatic backups on), v0.9.5 (rebuild the base image, restart agents, apply the agent restart policy; credential-bearing settings moved to encryption at rest with a rotation instruction; token-free git remotes), v1.0.0 (rebuild the base image and recreate agents; hosted installs default to bundled PostgreSQL with changed DATABASE_URL semantics and a required POSTGRES_PASSWORD; the Workspace-only user role; tighter default permissions for skills and agent-to-agent calls). Expect a release roughly every month, each needing a read of the upgrade notes and a base-image rebuild. We are not aware of a release that lost data when the notes were followed, but we keep no formal record of upgrade incidents to cite, so treat that sentence as unknown rather than a guarantee.

9. Managing several instances together

Short answer. Within one instance, templated deploys and config as code are built in. Across instances there is no control plane, no central health view and no staged-upgrade tooling. Unsupported across instances.

Capability	Within one instance	Across instances
Templated deploys	Agents from a template registry or any GitHub repository; a whole system (agents, permissions, schedules, shared folders) from one manifest. Documented: System manifest, Creating agents.	Re-apply the same manifest and repositories to each instance by hand or script.
Config as code	An agent is a git repository (`template.yaml` declares credentials, schedules, metrics, plugins); the instance is `.env` plus compose plus a pinned image tag. Documented.	Same files per instance; nothing distributes them.
Health view	Fleet health, a built-in system agent that runs health and token-advisory sweeps, git sync audit, monitoring. Documented: Monitoring, Ops agent.	None. Each instance has its own dashboard and system agent.
Staged upgrades	Pin the image tag per instance.	Roll manually: upgrade one instance, verify, move on.
Switching between instances	The CLI supports named profiles, one per instance. Documented: Trinity CLI.	The public ops-agent repository manages one instance per configuration; run several copies.

Agents on different instances can call each other over the agent-to-agent protocol (and, behind an off-by-default flag, with a signed per-agent identity); that is a collaboration path, not a management one.

10. Running without the implementer

Question	Status	Edition
Can an organisation keep running an install if it stops working with whoever set it up? Yes. The core is Apache-2.0 and self-contained; nothing phones home or needs an Ability AI account. The agents are git repositories the organisation owns, with their definition, skills, memory and history. The licence position is in section 13.	Documented	Core
What remote access should an implementer keep? Keep a named admin account per person on the instance (removable by the owner), and host access for upgrades over a private network such as a tailnet, which is the documented hardening pattern. Avoid a shared admin password, an implementer-held long-lived MCP admin key, and holding the owner's `.env` secrets anywhere other than the owner's own backup. The owner should be able to revoke access in two steps: delete the accounts, rotate the host access.	Recommendation built on documented controls: Hardening, Roles and permissions	Core
How is the Enterprise edition delivered? As access to a private companion repository mounted into the install; an instance reports which edition it runs.	Documented (mechanism)	Enterprise

11. Telemetry and outbound traffic

Default behaviour. By default Trinity records only a small fixed set of anonymous product events (onboarding and setup steps) locally, in its own database, with no network egress. Documented: FAQ: does Trinity phone home, Product telemetry.

The two opt-in outbound paths, both off by default and independent of each other:

Security and product updates contact form (Settings, or an optional checkbox on first-run setup): sends exactly the details you typed, at most once per install; disabled outright with OPERATOR_INTAKE_ENABLED=false.
Anonymous usage sharing: an admin-only, reversible toggle. Sends coarse aggregates (release version, edition, install lane, counts of agents, executions and funnel steps, and an outcome mix of how runs ended) under a random share id that is never the install id. Never PII, message content, prompts, emails or agent names. The payload is validated against a documented schema before every send; the Settings panel shows the exact payload and the last five sends. Egress needs two independent gates, stored consent and the TELEMETRY_SHARING_ENABLED switch; DO_NOT_TRACK=1 hard-disables both. Consent is a human-only decision; no API key can toggle it. Cadence once per 24 hours when on.

Documented; the default-off configuration and the kill switch are verified in the code. There is no version or update checker in the platform: an instance never calls home to ask whether it is current. Verified by absence in the code.

Other outbound traffic an instance makes

Destination	Purpose and when	How to switch it off	Status
The model providers you configure (Anthropic, OpenAI, Google)	Every agent run. The one inherent egress. What a provider does with a prompt is governed by its terms, not by Trinity. Which credential served each run is recorded.	Not applicable	Documented
`ghcr.io`	Image pulls at install and upgrade on a hosted install.	Build from source	Documented
GitHub (`raw.githubusercontent.com`, `github.com`, `api.github.com`)	The agent template registry (fetched hourly, byte-capped, falls back to the bundled list); the bundled skills library clone; template and repository imports; the front-desk agent seeded at first boot.	`TEMPLATE_REGISTRY_ENABLED=false`; `TRINITY_DEFAULT_SKILL_SOURCE=""`; `TRINITY_DEFAULT_SYSTEM_MANIFEST=disabled`. The registry switch is independent of `DO_NOT_TRACK`.	Documented in code and configuration
`intake.abilityai.dev`	Usage sharing (opt-in), the one-time contact form (opt-in), and the in-app bug report (user-initiated, build-time flag).	`DO_NOT_TRACK=1`, `TELEMETRY_SHARING_ENABLED=false`, `OPERATOR_INTAKE_ENABLED=false`, the bug-report build flag	Documented; Tested
The Claude Code plugin marketplace (`abilityai/abilities` on GitHub)	Pre-installed into the agent image at build time and re-installed at agent boot.	`TRINITY_PREINSTALL_PLUGINS=0` build argument	Documented
The documentation Q&A service	The `ask_trinity` tool and the docs bot, only when a person or agent invokes it.	Configurable endpoint; do not grant the tool	Documented
Nevermined (sandbox or live)	Paid agent calls and card funding, only when an admin configures Nevermined.	Not configured by default	Documented
`api.github.com/repos/abilityai/trinity/releases/latest`	The Vultr marketplace image resolves the current release at first boot only.	Not applicable to other installs	Documented in the boot script

12. Which controls are Core and which are Enterprise

The design rule. Open source is the whole runtime; Enterprise is additive governance on top. Nothing in the open core moves to Enterprise later. Documented in the public README.

Control	Edition
Container-per-agent runtime, three model runtimes, scheduling, loops, outbound agent-to-agent calls, channels, MCP server, Workspace, Inbox, asks	Core
Role-based access (admin, creator, operator, Workspace-only user), agent sharing	Core
Gated skills, person-only settings, admin-granted self-change permissions, agent reach	Core
Guardrail hooks, read-only mode, turn caps, loop budgets	Core
Encrypted credentials at rest, credential-file read tiers, secrets kept out of git	Core
Append-only audit log with optional hash chain (“compliance mode”, off by default)	Core
Fleet health, system agent, automatic database backups	Core
Telemetry off by default with a hard kill switch	Core
User and organisation management (invites, deactivate, per-user activity)	Enterprise
Single sign-on (OIDC: Okta, Entra ID, Google Workspace). SAML and SCIM are roadmap, not shipped.	Enterprise
Two-factor authentication (TOTP) and machine identities for admin APIs	Enterprise
Named-secret credential vault with per-agent grants	Enterprise
People-per-agent assignments, the approver and viewer roles, the role card	Enterprise
Projects (tasks, log, health, steward)	Enterprise
Audit dashboard, SIEM export, auditor export	Enterprise
Inbound agent-to-agent exposure control, allow-list, paid calls	Enterprise
Cross-model validation (a second model referees a run)	Enterprise
Ephemeral agents with a lifetime and a budget	Enterprise
Execution search across past runs	Enterprise
Per-agent outbound allow-lists, per-agent spend caps, effect-bound approvals, approval chains	Not built (planned)

Managed operation by Ability AI or a partner is a services engagement on a client-owned install, not an edition. There is no hosted Trinity.

13. Licence, trademark and reliance

The wording in this section is Ability AI's reviewed position as at 28 October 2026. It describes the published licence: the LICENSE file in the public repository is the Apache License 2.0, verbatim, with no additional terms. Read it with the reliance note at the top of this page.

May a third party deploy, configure and manage Trinity for clients as a paid service, and include it in an offering under its own brand?

Yes, as to the open-source core. Since 12 June 2026, Trinity's core has been licensed under the Apache License 2.0. Apache 2.0 permits anyone to use, modify, host, operate and distribute the core for any purpose, including commercially. That includes deploying, configuring and managing it for clients as a paid service, hosting it for several clients, and including it in an offering sold under your own brand. The licence is perpetual and irrevocable and includes a patent licence (Apache 2.0 §§2-3). Where you distribute the software, for example by handing a client an installation, Apache 2.0 §4 requires you to include the LICENSE and NOTICE files, keep the existing copyright and attribution notices, and mark files you have modified. You may add your own terms for your own offering, but they cannot take away rights your recipients have under Apache 2.0.
Two things are not covered by the open-source licence. (1) Enterprise modules. Some capabilities are in closed enterprise modules that are not part of the open-source distribution. As at v1.0.0 these include OIDC single sign-on, user and organisation management, the audit dashboard and SIEM export, enforced two-factor authentication, the credential vault, inbound agent-to-agent exposure controls, people assignments and projects. They are licensed separately on commercial terms. Using them in a deployment you operate for clients requires a written agreement with Ability AI. (2) Trademarks. Apache 2.0 grants no rights to Ability AI's names or marks (§6), including TRINITY; see the trademark answer below.

Can a client on a client-owned installation keep running if it stops working with its implementer?

The open-source core: yes, without conditions. The Apache 2.0 licence runs directly from Ability AI to every recipient of the software. It does not depend on the implementer or on any agreement with the implementer, and it cannot be revoked. A client that owns its installation can keep running the open-source core indefinitely, and can have it operated by itself or by any other provider.

Is licensing per instance, per agent or per seat across many installations?

The open-source core carries no licence fee at any scale. There is no per-instance, per-agent or per-seat charge for it.

Can a third party use the TRINITY name or logo in a white-labelled or co-branded offering?

The open-source licence does not include trademark rights. Apache 2.0 §6 excludes them, except for reasonable and customary use in describing the origin of the software and reproducing the NOTICE file. You may brand your own offering under your own name. You may not use TRINITY, or the Trinity logo, as or within the name of your offering, or in a way that suggests it is provided or endorsed by Ability AI, without our prior written permission. Ability AI reserves all rights in its names and marks. If you want to refer to Trinity in your materials, please send us the proposed wording before use.

Enterprise-module terms, partner arrangements and anything else commercial are set only in a written agreement signed by Ability AI, Inc. This page states none of them.

14. Third-party assurance, disclosure and support

Item	Status	Edition
Penetration test. UnderDefense performed a web application penetration test of Trinity between 23 February and 20 March 2026 (two certified testers; findings: 6 high, 6 medium, 5 low, 2 informational). A remediation retest between 16 and 23 April 2026 found all issues fixed except three low and one informational, with two high and one medium partially fixed and downgraded to low. Overall grade A, “Excellent”. The letter of attestation (23 April 2026) is in the public repository.	Documented: attestation letter	Core
SOC 2 / ISO 27001. Not certified. Do not state otherwise in a review. Compliance report packs are exploratory on the Enterprise roadmap.	Documented (absence)	n/a
OWASP self-assessments against OWASP Top 10 (web, LLM, agentic) are in the public repository. These are internal assessments, not third-party audits.	Documented: docs/security	Core
Vulnerability disclosure. Email security@ability.ai; do not open a public issue. Response within 48 hours. Only the latest version is supported for security fixes.	Documented: SECURITY.md	Core
Support for self-hosters. Public documentation, a documentation Q&A bot (in-editor via MCP, CLI or HTTP), GitHub issues and discussions. No SLA.	Documented: Getting help	Core

15. A governed baseline we recommend

The smallest deployment that stays on the supported path for work that holds credentials:

One Linux host, 8 GB RAM and 4 vCPU (a cloud instance from the one-click images, or an Ubuntu machine with the install script), running one instance.
Claude Code as the runtime for every agent that holds a credential or has a gated skill; a few agents to start; API keys with provider-side spend limits.
The “one key, one agent” pattern: one sender agent holding the outbound credentials with its send skills gated; drafting agents holding nothing.
Hardened per the guide: a domain, then a Cloudflare Tunnel or a tailnet, public ports closed.
PostgreSQL from day one; backups verified once by a restore; .env backed up off the host.
A dedicated instance per organisation whose data needs its own security review, on that organisation's own account where it will own the install.

What we advise against

Two instances on one Docker engine (section 1).
Codex or Gemini CLI for agents that hold credentials or have gated skills: the in-container controls apply on Claude Code (section 2).
Relying on prompt-level “ask first” behaviour as a control. Rely on credential custody and gated skills.
Hosting several unrelated organisations on one instance before per-agent egress allow-lists and spend caps exist (section 4).
Consumer subscriptions as the sole model authentication for work done on behalf of others. Use per-organisation API keys (section 5).
Enabling anything inbound (public links, Telegram, inbound agent-to-agent) on an instance that does not yet sit behind a tunnel or private network.

16. Not built — never claim

A reviewer should treat any of the following as absent in v1.0.0, whatever a demo or a deck implies:

SAML and SCIM (OIDC is the only single sign-on that ships, Enterprise).
A hosted Trinity or “Trinity Cloud”; a SOC 2 or ISO 27001 certification.
Per-agent outbound allow-lists; per-agent spend caps; approvals bound to the effect of an action; approval chains or edit-before-approve.
Local or self-hosted models; a fourth runtime.
A multi-instance control plane; a whole-instance restore or move procedure.
Signed agent identity between instances switched on by default (it ships off behind a flag).
The audit hash chain on by default (it is off; say “compliance mode”).

How this page is maintained

Source. Derived from the product capability sheet Ability AI's product management keeps for Trinity, anchored at release v1.0.0 (ef8112ee8), plus the v1.0.0 code and this documentation. It is not a second source of truth: where this page and the capability sheet disagree, the sheet is corrected or the page is.
Cadence. Every claim is re-verified at every final Trinity release; the release stamp and page date at the top move with it. A claim that stops being true between releases is corrected when found, with the page date updated.
Ownership. Trinity product management owns the content; the documentation site publishes it through a reviewed pull request, never a direct push; the licence and trademark section changes only after legal review.
Corrections. A factual error on this page: open a GitHub Discussion. A security vulnerability: email security@ability.ai, never a public issue.

Keeping Agents in Bounds Deploying Trinity

Describes Trinity v1.0.0 · page date 28 October 2026