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 Type II and ISO 27001 from day one. The control framework is implemented. The formal audit is planned, not yet initiated. 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.

Independent back-end audit

An independent, read-only back-end security audit completed 2026-06-16 (six parallel forensic reviewers with disjoint scope, lead verification at each cited file:line). 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.

Tenant isolation, by design

Per-customer data isolation is enforced at every layer: storage, query, model context, embeddings, audit, key management. No cross-tenant fine-tuning. No "shared learnings" leaking one operator's IP into another's recommendations. Architecturally, one customer's view never crosses another's.

What this means concretely

Pilot scope below describes the controls shipping with the first design-partner deployment. Production hardening lands post-pilot.

• Logical isolation at the database row level, enforced by tenant ID on every query path; no application-level join can cross tenants. (Implementation complete; deployed with the first design-partner pilot.)
• Per-tenant credential encryption at rest — customer credentials are encrypted with pgcrypto using per-tenant HKDF-derived data keys today. A refuse-to-boot guard forbids the dev env-key strategy in production. The cryptographic primitive is live; a leak of one tenant's key has no effect on any other tenant — by design. Architected but not yet deployed (ADR-0014 Phase-7 target): cloud-managed KMS master keys (production currently uses an environment-provided master key, not a live KMS). The externalized KMS layer (customer-controlled AWS/GCP/Azure backends, automated key rotation, HSM-backed master keys, formal CMK lifecycle) hardens with production deployment, post-pilot.
• Rate limiting posture (honest read) — the adapter egress limiter is in-memory and per-(tenant, provider), wrapped around every outbound call to keep us within the customer's published API limits. On the serverless deployment it is a per-invocation bucket, not a cross-instance ceiling. The GraphQL inbound limiter is in code but installed only on the long-running Fastify path, not on the customer-facing Vercel serverless adapter. Distributed per-tenant rate limiting that protects against noisy-neighbor behavior is architected (ADR-0012 access family, Redis-backed variant landed in code) but not yet deployed; it lands with production hardening, post-pilot.
• Model context boundary — The Captain's per-request context window is loaded only with the active tenant's data; tenant ID is enforced at the prompt construction layer, not just at retrieval.
• Customer-tenant configuration exposed in the Admin Portal so isolation policy is auditable directly by your team during the pilot, not via a screenshot in a sales deck.

Provisioning posture today

• 5 tenants currently provisioned on Neon Postgres — OpsATC.AI's own dogfooded tenant plus 4 demo environments. Pre-revenue, design-partner stage. Production tenant slots open at pilot kickoff.
• Row-Level Security at the database layer — RLS baseline applied at migration 0017 (enable_rls_baseline); migration 0035 makes RLS fail-closed — a query with no tenant context returns zero rows via an all-zeros sentinel, not every tenant. Logical isolation is database-enforced, not application-enforced.
• Tenant isolation is tested, not asserted — a 49-test integration suite boots under a restricted no-BYPASSRLS database role so RLS actually engages, and includes a fail-closed canary that asserts a no-tenant-context query returns zero rows. Isolation is a tested invariant, not a prose promise.
• JWT in HttpOnly cookie only (T11 migration complete 2026-06-10). Authentication tokens never appear in URL params, never in localStorage. SSO callback drops the legacy ?token= URL pattern. XSS-resistant by construction.

Encryption, transport & egress posture today

A precise read on what is code-enforced on the running stack right now (Vercel + Neon Postgres + Railway, single-region), what is architected but not yet deployed, and what is on the roadmap. The labels matter — we do not market roadmap as live.

In place today — code-enforced on the running stack

• Multi-tenant Postgres Row-Level Security
• Read-only Trusted-Advisor doctrine with two-tier CI enforcement
• Append-only audit log (UPDATE/DELETE revoked from the application role)
• 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.
• Customer credentials encrypted at rest with pgcrypto and per-tenant HKDF-derived data keys
• A refuse-to-boot guard forbidding the dev env-key strategy in production
• CAIQ / SIG / VRA pre-fills mapped to specific ADRs
• GDPR + CCPA architectural controls
• A read-only-scoped DPA template

Architected but not yet deployed

• Cloud-managed KMS master keys (ADR-0014 Phase-7 target) — production currently uses an environment-provided master key, not a live KMS
• Multi-AZ database failover (ADR-0014 Phase-7 target)
• Static egress IPs (ADR-0014 Phase-7 target)
• A managed WAF in front of /graphql (ADR-0014 Phase-7 target)
• Distributed per-tenant rate limiting on the customer-facing serverless path (ADR-0012 access family) — the GraphQL inbound limiter is in code but installed only on the long-running Fastify path, not on the Vercel serverless adapter that serves customer requests. The per-(tenant, provider) adapter egress limiter is in-memory and single-instance — an outbound courtesy to respect customer API limits, not a cross-instance ceiling. The Redis-backed distributed variant landed in code but is held for production hardening, post-pilot.

Roadmap, not running. We will not market these as live until they ship.

On the roadmap, honestly

• SOC 2 Type II is not yet certified — no audit booked
• ISO 27001:2022 control mapping is in progress; certification follows SOC 2
• HIPAA / BAA and FedRAMP are out of scope at launch
• Third-party penetration test scoped post-design-partner

OpsATC.AI is pre-revenue with no live paying customers and no SOC 2 certificate today. We will not claim certifications we do not hold, customer counts we do not have, or operational metrics we have not measured. The honesty is the differentiator.

Vertical configurations — one customer, one vertical

Seven vertical configurations are pre-tuned in the platform. One customer = one vertical configuration, not a forked codebase. Each vertical pre-tunes navigation, KPIs, recommendation prompts, and connector defaults for that supply-chain role:

• Distribution
• Contract Manufacturing
• Hybrid Manufacturing + Distribution
• Storage / OEM
• Integrator + Customer Network
• Logistics + 3PL
• Hub Provider

Forking the codebase per customer creates a maintenance nightmare. Pre-tuned vertical configs keep the platform unified while letting each customer's surface match their operating model.

Architecture decisions, by topic

Skeptical buyers want to see what the platform has actually decided, not just what it markets. OpsATC.AI maintains 30 accepted Architecture Decision Records (ADRs) in docs/adr/, each immutable after acceptance. The nine domains below summarize what those 30 records collectively govern; the records themselves carry rationale, alternatives weighed, trade-offs accepted, owner, and status, and are shared in full to design partners under NDA.

The ten domains the 30 accepted ADRs cover

• 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 structurally inaccessible, regardless of customer consent or administrative override. The Identifying tier (names, employee numbers, customer IDs) requires four-gate approval — express written customer permission, signed DPA, per-tenant policy flag, two-person admin approval, all audit-logged. Per ADR-0031.
• Token governance — per-tenant prompt-cache partitioning, per-tenant token budgets, per-operation model routing with admin policy knobs.
• Live-read architecture — connectors integrate without ingesting source data into a central lake; The Captain queries source systems live; no shadow-copy retention.
• 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

Architecture Decision Records describe what we've decided. 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.
• AI output verification. Every AI agent finding is independently verified by a primary reviewer before acting on it. Subagent claims do not bypass primary judgment.
• Four-tier sensitivity model (ADR-0031). Forbidden PII — Social Security numbers, passport numbers, bank account numbers, PHI — is NEVER accessible 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.

The full ADR registry (30 accepted records as of 2026-06-13, with rationale, alternatives weighed, trade-offs accepted, owner, and status) is available to design partners under NDA at pilot kickoff. Reach out for architectural deep-dive sessions during contracting.

Audit trail — structured logging and write-gate enforcement

Every Captain event — every read, query, recommendation, and human decision — is designed to be tied to a user, a role, a source system, and a timestamp. Write-gates are enforced in code; all gate decisions are logged. The design-partner pilot delivers structured audit logging with write-gate enforcement. Production hardening (post-pilot) adds persistent forensic-grade audit storage with cryptographic chain-of-custody and export in formats accepted by regulated-industry auditors.

What the audit trail captures

Capture surface designed for the design-partner pilot. Specific fields are finalized per pilot during onboarding.

• User action log — every action a human user takes in any portal, with role context and source IP.
• Agent activity log — every tool call The Captain makes, every system of record she reads from, every query and recommendation, with the prompt and response retained.
• Approval trail — every human-in-the-loop approval, with approver identity, timestamp, scope authorized, and any limits configured.
• Source citations — every recommendation includes the systems and records it was derived from, retained alongside the response.
• Configuration changes — every change to tenant configuration, role assignments, integration settings, or workflow rules.

Retention & export

Target retention is 7 years for audit-relevant records, configurable per tenant. Export formats planned: JSON, CSV, and SIEM-compatible streams (Splunk HEC, Elastic, Datadog). Historical export via the Admin Portal lands with production hardening, post-pilot.

Security roadmap

Phase 1 controls ship during the design-partner pilot. Phase 2 hardening is implemented during the pilot and shipped before production deployment. We do not market completed Phase 2 controls as live until they ship — and we do not market Phase 1 as production-live until a paid pilot is in flight.

What this means for a pilot today. Phase 1 controls are sufficient for a single-tenant design-partner pilot running against your sandbox or staging environment. Phase 2 hardening is a precondition for production-data deployment and ships before any pilot transitions to live operations of record. Phase 1 vs Phase 2 status for each control is reviewed jointly with your security team during pilot scoping; we will not run against production data on Phase 1 alone.

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. First, every adapter that exposes a high-risk write tool declares it in packages/mcp-core/src/write-gates.ts — currently 644 entries (634 high-risk Tier-2 + 10 low/medium static), default-deny with audit trail. Most high-risk writes don't have an executable code path at all (Tier-1 enforcement — the adapter class never wraps them in executeWithGate()); the Tier-2 registry shown here is the second defense layer. Second, The Captain's tool-selector filters high-risk writes out before any tool list reaches the model. Third, a CI lint denies any pull request that adds an unregistered write tool. The architecture is governed by 30 accepted ADRs in docs/adr/, each immutable after acceptance. The Captain's behavior is validated by a golden-prompts eval harness that runs nightly in CI against a curated 30-prompt set, with a deterministic grader that self-tests its own reproducibility on every run; failures post to the workflow summary and gate the next release.

What we won't do with your data or your team.

Two commitments hold together: your operational IP is never used to train any third-party model, and the team running your operation is never the metric we optimize against.

On your data

• No foundation-model training on customer data. Anthropic's API terms forbid it; the OpsATC.AI master-agreement template reaffirms it.
• Process improvements stay yours. The Process Intelligence Engine is designed to surface bottleneck patterns and ROI calculations identified inside your tenant; those findings are your operational IP, not platform-level features we resell.
• De-identified telemetry only. Platform-improvement analytics (latency, error rates, feature usage) is designed to be aggregated and de-identified before it reaches our engineering systems; the telemetry pipeline ships during the design-partner pilot.
• For cross-tenant isolation specifics — fine-tuning, embeddings, key management — see Section 02.

On your team

The OpsATC.AI master-agreement template explicitly does not include a headcount-savings clause. The outcomes we measure are cycle time, OTIF, exception MTTR, onboarding velocity, and decision compression — never seats eliminated. The objective is to amplify operators you already have, not to enable their replacement. The master-agreement template includes the commitment in writing; design partners receive it under NDA before contracting.

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

Hosting is on AWS, US regions, with EU and APAC residency on the production roadmap. Design partners receive written commitments on residency, retention, and sub-processor changes in the master-agreement template.

Regions & status

Retention defaults (master-agreement template)

• Operational data: retained for the term of the agreement; deleted within 30 days of termination unless otherwise specified.
• Audit logs: 7 years (configurable to longer for regulated customers).
• Backup snapshots: 35 days rolling target, encrypted at rest with per-tenant keys; the rolling-snapshot schedule lands with production hardening, post-pilot.
• Customer-initiated deletion: subject-of-data requests fulfilled within 30 days.

Sub-processors

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

Last updated: May 2026.

Disclosure, response, timing.

Two channels for "something is wrong": researchers and customers reporting a vulnerability they found, and the internal incident path when we detect one ourselves. Both have written commitments below.

Vulnerability disclosure — for researchers and customers

Target acknowledgment within one business day. Target triage status within five business days. No legal action against good-faith researchers who follow this policy. These targets become contractual SLAs from the design-partner pilot onward via the master-agreement template.

In scope

• opsatc.ai and any *.opsatc.ai production subdomains
• The OpsATC.AI mobile and web applications
• The MCP connector framework and published adapter SDK
• Authentication, authorization, tenant isolation, and audit-trail integrity

Out of scope

• Vulnerabilities in third-party services we use (please report to that vendor; we will coordinate)
• Issues requiring physical access, social engineering, or denial-of-service testing
• Best-practice findings without a demonstrable exploit path

How to report

Email [email protected] with a clear technical description, reproduction steps, and the impact you observed. PGP key issued on request once first design-partner contracting begins. Researchers will be credited in security acknowledgments — that page is published as soon as the first valid report is received.

Incident response — when we detect it

Procedures are documented; the first tabletop rehearsal is scheduled before the first design-partner pilot goes live. Customer-notification timelines below become contractual commitments via the master-agreement template.

Notification timing (master-agreement commitments)

• Sev-1 (confirmed customer data exposure or loss): notification to affected customers within 24 hours of confirmation, with regulatory authorities notified per applicable jurisdiction (GDPR Article 33, state laws).
• Sev-2 (security incident with potential customer impact): notification within 72 hours of confirmation.
• Sev-3 (security event with no customer impact): disclosed in the next monthly security update; included in the public incident log, which is published from the first design-partner pilot onward.

Response capacity

At the design-partner stage, the founder is the on-call line. Response timing is human-paced, not 24/7 SOC-paced — committed in writing via the master-agreement template. Current on-call structure is published on this page as it evolves.

Strategic independence, in writing

OpsATC.AI is built to operate independently of any single distributor, ERP vendor, or supply-chain platform. The master-agreement template includes explicit change-of-control protections so an acquisition cannot leave you stranded.

Design-partner change-of-control terms (master-agreement template)

• 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 live in the master-agreement template, not in a sales deck. Available for review under NDA prior to design-partner engagement.

Built to be replaced — gracefully

Every connector is designed to ship with a documented schema. Every workflow is designed to export as YAML. Every audit log is designed to be portable. We don't trap data, and we don't lock you in. The fastest way to lose a long-term customer is to make them feel imprisoned, so we are building the exits in parallel with the entrances. Export capabilities are available from the first design-partner pilot onward.

What you can take with you

• All customer data, in JSON or CSV, via the Admin Portal export — target latency in minutes, available from the design-partner pilot onward.
• Workflow definitions exported as portable YAML, suitable for re-import to a different orchestration platform.
• Audit logs, complete history, via the same export channel.
• Connector schemas documented for every integration in the OpsATC.AI catalog so you know exactly what each adapter reads — the read-only doctrine means no adapter writes to a system of record.
• Configuration backups on demand, or scheduled to a customer-controlled S3 bucket. The scheduled-S3 path lands with production hardening, post-pilot.

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.