Public documentation for governed AI labor
SDKs/Governance/Connectors
Arx / Docs / Atlas — Customer-Private CEO Aide

Documentation

Atlas — Customer-Private CEO Aide

arxsec-site / docs/atlas/atlas-spec.md

arxsec-site product-docs docs/atlas/atlas-spec.md

Audience: CISO, CIO, CHRO, and CEO of an enterprise considering ARX. Auditors validating the data-handling posture before approval.

One sentence: Atlas is the customer-private analyzing agent that runs inside the customer's network, becomes the CEO's aide and the single source of truth across the deployment, and never sends customer data to ARX.

---

What Atlas is

Atlas is the customer's full-time business analyst + workforce architect, not just an executive assistant. It is the first agent ARX deploys in any engagement, and it stays for the life of the relationship. Three months in, Atlas is the surface the customer's executives operate from for everything — and the digital workforce flows through it.

Atlas's primary deliverable in the engagement is the manifest set: the document that defines the customer's digital workforce. Atlas analyzes the customer's environment, the human roster, the operating processes, the consultant interview transcripts, the earnings calls, the board decks, the M&A diligence rooms, the analyst reports — and produces the manifests that say *who should be hired, what shape they should be, what their scope is, who they report to.* Those manifests are the input to the bulk-instantiation pipeline that creates the workforce. The CHRO + CFO + CISO sign off on Atlas's manifest set the same way they sign off on a human-headcount plan.

Atlas also serves as the customer's operating cadence. The morning brief is the executive team's start-of-day; the probe is the watch; the audit is the quarterly performance cycle; the coach is how every executive instruction flows into action. The platform implements the five workforce pillars *underneath* every agent; Atlas is the surface the executive team operates *from*.

Atlas is a single agent the customer deploys at the start of an ARX engagement. It runs entirely inside the customer's environment — either in their own Kubernetes cluster (production scale) or as a Docker Compose deployment (smaller estates). The customer's infrastructure team owns the deployment; ARX provides the signed artifact.

Atlas's job is to read across the customer's existing systems and produce three things continuously:

  1. The CEO's morning brief. Top 5 things the CEO needs to

know, sourced from every system Atlas can read.

  1. Decision support. When the CEO poses a question, Atlas

surfaces evidence from across systems with citations back to source documents.

  1. The manifest set. When ARX is ready to deploy a digital

workforce, Atlas analyzes the customer's environment, employee roster, and operating processes, and generates the agent manifests the customer's CHRO + CFO + CISO sign off on. Those manifests are the input to the bulk-provisioning pipeline that instantiates the digital workforce.

Atlas is the platform's "first agent." It makes the rest of the deployment possible because it produces the artifact (the manifest set) that the customer's executive team reviews and approves.

What Atlas is not

  • Not a chatbot wrapper. Atlas is built around a planning loop and

a connector framework, not a conversational UI.

  • Not an LLM reseller. Atlas calls whichever LLM the customer's IT

team configures — including the customer's own local model if they prefer. ARX has no preferred model.

  • Not a data-collection layer for ARX. Atlas does not send any

data, telemetry, or metadata back to ARX. The deployment's egress posture makes this technically impossible, not just contractually prohibited.

---

Three data-handling guarantees

Each guarantee is technically enforced and independently auditable by the customer's own auditor, without trusting ARX.

Guarantee 1 — No exfiltration to ARX

Atlas has zero outbound network access to any ARX-controlled IP address or domain. The deployment chart installs a Kubernetes NetworkPolicy that denies egress except to customer-declared internal endpoints (Workday, Salesforce, GitHub, M365, Slack, etc.) and the customer's own LLM provider (OpenAI on the customer's contract, Anthropic on the customer's contract, customer's local endpoint, etc.).

The NetworkPolicy ships in docs/atlas/network-policy.yaml and is applied as part of the Helm install. Auditors verify the policy is in effect by inspecting the cluster directly:

`` kubectl -n arx-atlas get networkpolicy atlas-egress-lock -o yaml ``

ARX never appears in the allow list, ever. There is no path by which Atlas can reach ARX infrastructure.

Guarantee 2 — No data ingress from ARX

Atlas's update channel is pull-from-customer-mirror, never push-from-ARX. ARX publishes signed images to a public registry (ghcr.io/arxsec/atlas:<version> with a pinned digest). The customer's own infrastructure mirrors the image into their private registry before deploy. The Helm chart references the customer's private registry, never ARX's.

This means:

  • ARX cannot push a new image into the customer's environment.
  • ARX cannot trigger an update.
  • The customer controls when (and if) Atlas updates.

The customer's auditor verifies image authenticity by checking the signed digest matches ARX's published manifest, on the customer's own registry, with the customer's own signing infrastructure.

Guarantee 3 — No telemetry

Atlas emits zero usage telemetry. No "phone home" of anonymized metrics, no error reports to ARX, no version-check pings, no heartbeats. Whatever observability the customer's SRE team wants on the deployment, they collect with their own stack (Datadog, Splunk, Prometheus, etc.). ARX has no view into Atlas's runtime behavior.

The customer's auditor verifies this by inspecting Atlas's outbound traffic against the NetworkPolicy allow list. If the traffic is constrained to customer endpoints, telemetry to ARX is technically impossible.

---

Deployment model

Production scale (Kubernetes)

Helm chart deployable to the customer's Kubernetes cluster. The chart installs:

  • The Atlas pod (single-replica by default, optional HA).
  • The Atlas API service (cluster-internal only, no Ingress to the

public internet by default).

  • The NetworkPolicy that enforces egress restrictions.
  • A PersistentVolumeClaim for Atlas's working memory (vector store,

ingested document cache).

  • A Secret for the customer's LLM provider credentials (managed by

the customer, never seen by ARX).

Reference Helm values live in docs/atlas/network-policy.yaml. Production customers customize the connector list, the LLM provider, and the namespace.

Smaller estates (Docker Compose)

A Docker Compose stack for customers below ~5,000 employees who don't run Kubernetes. Same artifact, same egress posture; the NetworkPolicy is replaced with Docker network rules.

Sealed deployment artifact

  • Image signed with cosign, digest pinned in the Helm chart.
  • All dependencies vendored at build time (no pip install at

runtime).

  • Customer's own image scanner verifies the artifact before

deploy.

---

Ingestion surfaces

What Atlas can read, organized by classification.

Internal systems (read-only by default)

Connectors run as the customer's IT-issued service accounts, scoped to the systems the CIO declares in the manifest. Read-only unless the customer explicitly grants write scope.

Common surfaces:

  • Documents: SharePoint, Confluence, Notion, Box, Google Drive.
  • Issue trackers: Jira, Linear.
  • Code: GitHub, GitLab, Bitbucket.
  • Communication: Slack, M365, Microsoft Teams.
  • Sales: Salesforce, HubSpot.
  • HR: Workday, BambooHR.
  • Finance: NetSuite, Sage Intacct, QuickBooks.
  • Data warehouse: Snowflake, BigQuery, Databricks.

Unstructured corpora (uploaded by the customer)

Documents the customer's chief-of-staff or operations team uploads into Atlas's working memory:

  • Consultant interview transcripts (BCG, McKinsey, Bain, in-house

interviews).

  • Earnings call transcripts and analyst reports.
  • Board decks and committee materials.
  • M&A diligence room contents.
  • Customer-call recordings (transcribed before ingest by the

customer's own tooling).

Time-series feeds (push)

Customer-defined webhooks the customer wires into Atlas:

  • KPI streams (revenue, ARR, NPS, etc.).
  • Pipeline movement (CRM stage changes).
  • OKR / objective updates.
  • Industry / market signals the customer subscribes to.

---

CEO-aide capabilities

Five primitives, each implemented as a declared operation in Atlas's manifest. Each operation has its own approval policy and runtime budget.

Brief

Generates the morning brief — a 1–2 page document the CEO reads at the start of each day. Sources from every system Atlas can read. Cites sources inline. Highlights the deltas since yesterday.

The brief is generated on a schedule the customer configures (typical: 06:00 customer-local time, delivered to a private S3 bucket and an email to the CEO).

Decide

Synchronous Q&A. The CEO poses a question; Atlas pulls evidence from across systems and returns a structured answer with citations.

Example: > "What's our actual deal-cycle time on enterprise deals over $1M > in the last two quarters, and how does it compare to Q4 2025?"

Atlas reads Salesforce's opportunity history, computes the average, compares against Q4 2025, surfaces the answer with line-level citations to the underlying records. Read-only — Atlas does not modify any system to answer.

Probe

Continuous "what's slipping?" sweeps. Atlas runs a configurable set of monitors against KPI / OKR / pipeline data and surfaces deltas the CEO hasn't been told yet:

  • Pipeline cohorts decelerating.
  • Deals stuck at a stage longer than threshold.
  • OKRs trending against forecast.
  • Customer-health signals diverging from the renewal forecast.

Probes fire into the morning brief and as standalone notifications to the CEO and chief-of-staff.

Coach

The operational handoff layer between the CEO and the rest of the agent workforce. The CEO drafts an instruction in Atlas (e.g. "prepare the board read-out on the Q3 enterprise pipeline"); Atlas routes the instruction through the supervision pillar to the right cohort of agents (Sales Director Coordination shape, Finance IC Production shape, etc.) and returns the assembled output for the CEO's review.

This is how the CEO operates the digital workforce without managing 10,000 individual agents directly.

Audit

Reviews the personnel records of the digital workforce on the CEO's behalf. Surfaces drift across cohorts, evaluates cohort performance against the forecast, recommends reorganizations (consolidate cohorts, promote certain agent shapes, retire underperforming variants).

This is the agent equivalent of an internal-audit / talent-review function. Runs on a quarterly cadence by default, ad-hoc when the CEO requests.

---

Architecture

``` ┌──────────────────────────────────────────────────────────────────┐ │ Customer's network / VPC │ │ │ │ ┌─────────────────────┐ │ │ │ Atlas pod │ │ │ │ - planning loop │ │ │ │ - connector layer │ │ │ │ - vector memory │ │ │ └──────────┬──────────┘ │ │ │ │ │ │ NetworkPolicy: egress-locked │ │ │ │ │ ┌─────────┼──────────────┬─────────────┬───────────────┐ │ │ │ │ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ │ │ Workday Salesforce GitHub Customer's LLM Customer's │ │ (read) (read) (read) provider S3 bucket │ │ (chosen by CIO) (audit chain) │ │ │ │ ╳ NO EGRESS to ARX. ╳ NO TELEMETRY. ╳ NO UPDATES from ARX. │ └──────────────────────────────────────────────────────────────────┘

⇡⇡ Image distribution: pull-from-customer-mirror only │ │ ┌──────┴──────────────────────────────────────────────────────────┐ │ Public registry (ghcr.io/arxsec/atlas) │ │ - signed images, pinned digests │ │ - customer's CI mirrors before deploy │ └──────────────────────────────────────────────────────────────────┘ ```

---

Manifest

Atlas's own role manifest conforms to the framework every other agent in the platform conforms to. See reference-agents/atlas-ceo-aide/manifests/job_description.yaml.

Highlights:

  • agent.cell: executive.ceo-aide (a special non-matrix cell;

Atlas is one of one).

  • agent.shape: coordination (Atlas's primary shape — multi-system

orchestration on behalf of the CEO).

  • agent.declared_systems: read-only on every connector by

default; write scope only when the customer explicitly grants it on a per-operation basis.

  • agent.approval_writes: every write goes through the customer's

CHRO/COO approval queue.

  • agent.termination_attestation_required: true (always, same as

every other agent).

  • agent.network_egress_policy: explicit allow-list of customer

endpoints + customer's chosen LLM provider. Zero ARX endpoints. Auditable from the running cluster.

---

Trust artifacts

For the customer's auditor / CISO to validate the Atlas posture without trusting ARX:

  1. Signed image digest. ARX publishes the signed image manifest

(cosign + Sigstore). Customer verifies the signature and pins the digest.

  1. NetworkPolicy YAML. Inspect the running policy:

kubectl -n arx-atlas get networkpolicy -o yaml. ARX endpoints must not appear.

  1. Egress capture. Run a 24-hour egress capture on the Atlas

namespace. The destinations must match the NetworkPolicy allow-list exactly.

  1. SOC 2 Type 2 for Atlas. Available as a separate report from

the ARX SaaS SOC 2. Covers the development pipeline, image signing, and the supply chain.

  1. Third-party penetration test. Performed annually against

Atlas the artifact (not against ARX SaaS). Results published under NDA on customer request.

  1. Source-availability commitment. Atlas is source-available

to the customer's auditor under an inspection license. Auditors can read the source to verify the egress lock is implemented as described.

---

Bundling and pricing

Atlas is bundled into the engagement. There is no separate Atlas SKU. The pricing doc (docs/pricing/value-based-pricing.md) treats Atlas as part of what the engagement fee + retainer cover.

The customer never sees a per-seat or per-call charge for Atlas. Atlas's compute cost lands inside the customer's own infrastructure budget (since Atlas runs on the customer's cluster).

---

Status

  • Spec: this document — Phase 1 / Commit 2.
  • Network policy: docs/atlas/network-policy.yaml — Phase 1 /

Commit 2.

  • Reference manifest: reference-agents/atlas-ceo-aide/ — Phase 1

/ Commit 2.

  • Helm chart implementation: Phase 5 / Workstream F.
  • The five capabilities (Brief, Decide, Probe, Coach, Audit)

implemented: Phase 5 / Workstream F.

  • SOC 2 Type 2 attestation: contracted at engagement signing,

delivered within 9 months of first deploy.