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.

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 encryption keys with HKDF-SHA256 envelope encryption (implementation complete; deployed with the first design-partner pilot); KMS infrastructure support with AWS/GCP/Azure backends (production hardening, post-pilot). A leak of one tenant's key has no effect on any other tenant.
• Per-tenant rate limiting on the agent layer (in-memory limiter shipping with the pilot; Redis-backed distributed limiter lands with production hardening, post-pilot). Noisy-neighbor behavior cannot degrade another customer's experience.
• Model context boundary — Major Tom'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.

Audit trail — structured logging and write-gate enforcement

Every Major Tom 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 Major Tom makes, every system of record he 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.

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

Major Tom is read-only against every system of record. He reads, reasons, cites, and recommends. He 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. Major Tom 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 Major Tom from generating recommendations on the affected workflow. Implementation completes during the design-partner pilot.

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 subdomain
• 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.