Built for the operator who can't afford a leak, or a hallucination.

A clear runway, not a checklist

OpsATC.AI is architected against SOC 2 and ISO 27001 from day one, and the control framework is implemented. SOC 2 Type I and an independent penetration test are budgeted but not yet initiated; the Type II observation window extends beyond our current planning horizon. We will not claim certifications we have not earned, and we will publish current status on this page as each one is awarded.

Industry-specific attestations (CMMC, ITAR, HIPAA where applicable) considered on a per-customer basis during design-partner contracting. Reach out to [email protected] before evaluation if your industry requires a framework not listed above.

Internal back-end security audit

A read-only back-end security audit completed 2026-06-16, conducted with six AI agents running in parallel against disjoint scopes, with founder verification at each cited file:line, the same multi-reviewer discipline published as an operating rule below. This was an internal audit, not a third-party engagement: no outside firm has reviewed this codebase. A focused remediation wave closed all six Critical findings, covering tenant-provisioning authorization, connector-credential encryption at rest, race-free cost governance, scheduler retry and dead-letter handling, SSRF and cloud-metadata egress guards, and Row-Level Security fail-closed. A re-audit confirmed the closures. Third-party penetration test is scoped post-design-partner stage. Audit summary and remediation evidence available to design partners under NDA.

Regulatory disclosure

Every Captain first-session interaction includes the verbatim sentence "I'm The Captain, an AI assistant powered by Anthropic's Claude." Every Captain response surface (chat reply, recommendation card, Logbook entry, daily workbench tile) carries a persistent footer reading "Powered by Anthropic's Claude." This disclosure is enforced at the React component level (the surfaces cannot render without it) and is designed to satisfy the Anthropic Acceptable Use Policy (effective 2025-09-15), EU AI Act Articles 4 and 50, California SB-1001, and FTC Section 5 anti-deception guidance simultaneously. Procurement and legal teams can verify the implementation under NDA.

What the platform enforces, by topic

Skeptical buyers want to see what the platform actually enforces, not just what it markets. The ten domains below are the decisions and controls that govern how OpsATC.AI handles tenant isolation, integration, data quality, security, and privacy. The full technical detail behind each one, including the decision records that document it, is shared with design partners under NDA.

The ten domains we govern

• Multi-tenant data isolation: Postgres row-level security enforced at every query; tenant boundary is a database-level invariant, not application-level.
• MCP adapter architecture: Model Context Protocol as the integration layer; per-connector capability + scope + write-gate registry.
• Captain orchestrator state machine: bounded state graph + selectTools chokepoint + per-operation routing; one orchestrator path per workflow, not free-form agent loops.
• Trusted Advisor doctrine: The Captain reads systems of record; writes route through a human-gated approval queue; no autonomous writes to customer systems.
• Data quality detection: layered detection (baseline → inline → scheduled → on-demand) of the six issue classes that erode operator trust: stale records, missing identifiers, duplicate keys, contradictory source-of-truth values, schema drift, and reference-data gaps. Per ADR-0023.
• Security controls: five control families. Live today: per-tenant egress allow-list; a TLS 1.2+ (AEAD) floor with mTLS and per-adapter certificate pinning supported in the egress client (we do not force TLS 1.3, which would break older customer endpoints); secrets management via pgcrypto with per-tenant HKDF-derived data keys. Architected but not yet deployed: cloud-managed KMS master keys (ADR-0014 Phase-7), distributed per-tenant rate limiting on the customer-facing serverless path (ADR-0012 access family), static egress IPs, and a managed WAF in front of /graphql.
• Privacy & PII Protection: four-tier sensitivity taxonomy applied at the connector boundary. The Forbidden tier (SSN, passport, bank account, ICD-10 diagnosis codes linked to identity, GDPR Article 9 special categories, 42 CFR Part 2 substance abuse records, COPPA minors data) is designed to be filtered at the connector boundary before it reaches The Captain, rather than passed through, even with customer consent or admin override. The Identifying tier (names, employee numbers, customer IDs) is default-deny and not accessible in-product today; the four-gate elevation policy (express written customer permission, signed DPA, per-tenant policy flag, two-person admin approval, all audit-logged) is defined and will be enforced when that access path ships. Per ADR-0031.
• Token governance: per-tenant monthly budgets and per-user daily caps, hard-enforced at the orchestrator with an atomic, race-safe cutoff and an append-only record of every block. A per-operation model router with admin policy knobs ships in the codebase; production traffic exercises a single tier today, and the cheaper and deeper tiers activate as more operation types land.
• Live-read architecture: connectors integrate without ingesting source data into a central lake; The Captain queries source systems live and uses the returned data only to answer the request in-flight, retaining read metadata (system, operation, record count, latency), never the read payload.
• Network Federation doctrine: two adjacent-layer tenants in a real-world business relationship can share a specific slice of operational data (e.g., ASN status for one customer's orders, demand for one supplier's parts) through OpsATC without either side losing read-only posture, tenant isolation, or audit. Bilateral acknowledgment required before any data flows; scope is enumerated as canonical entities plus a filter predicate; every cross-tenant read writes a federation.read audit event visible to both tenants; either side revokes unilaterally and instantly. Per ADR-0022. Honest-stage framing: internal-only today and design-partner-gated for the first external use.

Five operating rules we hold ourselves to

The decisions above describe what the platform enforces. Operating rules describe what we hold ourselves to: explicit organizational rules, internally enforced across every conversation, every commit, every dispatch. The five we publish:

• Honest-stage discipline. Never invent customer counts, quotes, shipped-feature status, or operational data. Pre-revenue framing is explicit. The honest-stage banner above is anchored to a code constant in packages/types/src/compliance.ts.
• Four-tier sensitivity model (ADR-0031). Forbidden PII (Social Security numbers, passport numbers, bank account numbers, PHI) is blocked by default and never intentionally surfaced, filtered at the connector boundary by design, regardless of consent. Identifying data (names, employee numbers) requires explicit written per-tenant permission. Operational data is default-allow; public data is unrestricted.
• Verbatim AI disclosure. Every Captain first-session message includes the exact string "I'm The Captain, an AI assistant powered by Anthropic's Claude." Satisfies Anthropic AUP (effective 2025-09-15), EU AI Act Article 4/50, California SB-1001, and FTC Section 5 anti-deception simultaneously.
• Single-writer discipline. Only one development conversation modifies a given working tree at a time. Prevents parallel-write corruption and silent commit interleaving. Discovered the hard way; codified after.

These five are a subset of nine operating rules codified internally; four are engineering-discipline rules less relevant to a buyer audience. The full set is shared to design partners under NDA at pilot kickoff.

Full architectural detail, including the decision records behind each control, is shared with design partners under NDA at pilot kickoff. Reach out for architectural deep-dive sessions during contracting.

Read-only by doctrine. The clicks belong to the operator.

The Captain is read-only against every system of record. She reads, reasons, cites, and recommends. She does not issue POs, reroute shipments, or post journals: those clicks belong to the operator. This is doctrinal, not a default: OpsATC.AI is not building write capability against customer systems of record. The clicks are yours, permanently.

How this works in practice

• Default mode: advisory. The Captain drafts, recommends, and cites. Nothing changes in your systems of record unless a human user clicks approve.
• OpsATC writes only to its own application data. Notes, scheduled prompts, configuration, draft artifacts (emails, briefs) that you review and send from your own system. Never outbound to your ERP, Kinaxis, Salesforce, or any system of record.
• Approval audit. Every approval is logged with approver identity, scope, and any limits. Structured logging is captured during the design-partner pilot; SIEM streaming (Splunk HEC, Elastic, Datadog) lands with production hardening, post-pilot.
• Kill switch. The Admin Portal is designed to expose a per-workflow disable that immediately pauses The Captain from generating recommendations on the affected workflow. Implementation completes during the design-partner pilot.

The read-only doctrine is defense-in-depth across three layers: a default-deny write-gate registry of 644 entries (634 high-risk Tier-2 + 10 low/medium static), The Captain's tool-selector filtering high-risk writes out before any tool list reaches the model, and a CI lint that blocks any pull request adding an unregistered write tool. Most high-risk writes have no executable code path at all. The full write-gate architecture is detailed under Platform controls above and on the integrations page.

Where your data lives: regions, retention, third parties.

Hosting is in US regions on Neon Postgres and Vercel, with EU and APAC residency on the production roadmap. We set out residency, retention, and sub-processor-change commitments in writing in the pilot agreement.

Regions & status

Sub-processors

Every third party that may touch customer data. Additions are communicated to design partners 30 days in advance with an objection window, set out in the pilot agreement. Status reflects current platform integration; design partners receive the as-deployed list before pilot kickoff.

“Customer-selectable cloud” reflects design posture, not a live multi-cloud deployment today; production runs on Vercel + Neon (US).

Last updated: July 2026.

Strategic independence, in writing

OpsATC.AI is built to operate independently of any single distributor, ERP vendor, or supply chain platform. We include explicit change-of-control protections in the pilot agreement so an acquisition cannot leave you stranded.

Design-partner change-of-control terms

• Perpetual license to the version of the platform you are running at the moment of an OpsATC.AI change-of-control event.
• Source-code escrow with a recognized third-party escrow agent. The escrow account is established at the first design-partner contract execution; release triggers include change-of-control, business-continuity events, and material breach.
• Defined transition window: no less than 12 months, during which the platform continues to operate at current pricing and SLA terms regardless of acquirer intent.
• Right of first refusal on data extracts, configuration exports, and tenant-isolation guarantees during the transition.

These terms are set out in the pilot agreement, available for review under NDA prior to engagement.

Buyer questions, answered straight

Strategic-objection questions we hear from security teams, data leads, and operations buyers during evaluation. Pilot-scope and architectural-pattern markers are preserved: what ships today versus what lands during the pilot is called out in each answer.