# Architecture and responsibilities

> This runbook covers the managed installation in a dedicated customer AWS account.

_Concept · Updated 2026-10-15 · Describes release 0.1.164_

Evidence reviewed **8 October 2026**; operating baseline **0.1.130** (the 16 October 2026 handover build; see the [release notes](/help/release-notes.md)).

This runbook covers the managed installation in a dedicated customer AWS account. The operating baseline is **0.1.130**, the handover build; the procedures were verified on 0.1.108 and re-read against the 0.1.130 release notes. Use a later release only after its release record identifies the image and chart to deploy.

## Who owns each part {#who-owns-each-part}

| Part | Responsible team | Routine responsibility |
|---|---|---|
| Dedicated AWS account, organization policies, quotas and billing | Customer cloud team | Approve the account boundary and regional access; maintain payer-account budgets and cloud access |
| Bootstrap IAM role and cluster emergency access | Customer cloud team | Run the supplied bootstrap, retain an IAM principal able to administer EKS, review CloudTrail |
| Platform hostname and DNS | Owner of the DNS zone | Maintain the platform CNAME and ACM validation CNAME; keep records DNS-only |
| Release images, OCI chart and deployment pipeline | Vendor release team | Publish a release, maintain the customer branch and pipeline secret group, supply deployment evidence |
| Deployment approval | Named customer approver | Read every infrastructure plan and release a run in an agreed maintenance window |
| Platform administration | Customer platform administrators | Users, workspaces, model pricing, runner health, audit checks and incident response |
| Estate connections and signals | Customer workspace owners and monitoring teams | Grant read access, test connections, maintain ingest tokens and alert routing |
| Remediation decisions | Authorized customer operators and approvers | Review and release plans; maintain execution credentials separately from investigation access |
| Backups, recovery and security reviews | Customer cloud and security teams with the release team | Verify backups, retain encryption keys, rehearse recovery and archive audit evidence |

These are operating responsibilities, not response-time commitments. Agree named contacts using [Support and escalation](/help/ops-support-and-escalation.md).

## What runs where {#what-runs-where}

| Component | Location and purpose | Data boundary |
|---|---|---|
| Control plane | One platform pod in the customer EKS cluster; portal, Ops console, APIs, intake, scheduler and coordination | Owns the PostgreSQL connection, tenant secret-store key, persistent records and audit trail |
| Workspace runner | A separate pod per workspace; claims durable work and executes investigations and discovery | Customer default is API mode: workspace-scoped token, no database credential or secret-store key; resolves that workspace's investigation credentials |
| Private-network agent | Customer-managed deployment where private estate endpoints are reachable | Connects back to the control plane with a scoped agent token; run it only with the estate read permissions it needs |
| PostgreSQL | Private RDS instance, Multi-AZ in the customer template | Incidents, investigations, settings, encrypted stored credentials and audit chains |
| `/data` volume | Single-zone EBS volume attached to the control plane | Derived skill and connection files; DuckDB lake data is re-collected after loss |
| Vendor pipeline | Azure Pipelines; assumes the customer deploy role for a run | Terraform state and release chart remain on the vendor side; they are not copied into the customer account |

In remote mode the control plane queues work and runners checkpoint each step through it. A failed runner resumes durable work after its lease expires, subject to the attempt limit. This is separate from platform availability: the control plane is one replica with a single-zone volume. Multi-AZ RDS does not make the portal or scheduler multi-AZ. See [Availability and recovery](/help/ops-availability.md).

## Access and data decisions to retain {#access-and-data-decisions-to-retain}

- Keep the account dedicated. The current deployer policy can effectively grant itself account administrator access; a permissions boundary is not delivered. Its trust restricts assumption to the vendor pipeline, with an ExternalId and operator SourceIdentity. Review that accepted risk before a production install.
- Store the onboarding secrets file in a vault. Losing the tenant secret-store key loses access to the credentials encrypted with it. A database backup alone does not replace that key.
- Keep estate permissions read-only at their source. Execution-only credentials are excluded from agent registries and are resolved by the approved execution path. A compromised runner can still read the credentials and evidence it legitimately needs for its own workspace.
- The customer template from 0.1.109 lets both control-plane and runner roles call `sts:AssumeRole` and `sts:TagSession` on `arn:aws:iam::*:role/aiops-*`. Review every estate role that trusts those identities and its workspace External ID. The platform's own account uses a staff-prepared pair; a same-account trust naming the control plane must not bypass that account-selection restriction.
- Confirm model region, endpoint and data-residency policy. Alert content, read-tool evidence and knowledge can enter model prompts. Configure the alert and tool-output PII controls according to that policy; storage scrubbing does not by itself prove every outbound prompt is scrubbed.
- The chart's runner NetworkPolicy needs network-plugin enforcement to be a boundary. Its presence alone proves no isolation. The metrics listener is unauthenticated and must stay inside the cluster.

Sources: [Deployment runbook §0–1](/help/ops-installation-runbook.md#0-the-whole-install), [Architecture](/help/architecture.md), as-built design, Security review, accepted risks, and the `/data` decision.


## Next steps

- Next: [Install](/help/ops-install.md)
- [All Install and operate the platform pages](/help/install-and-operate-the-platform/llms.txt)
- [Documentation home](/help/)