DevAI Suite — Security White Paper

Version 1.1 — October 2026 Classification: Public · safe to share with prospects, customers, and auditors.

Executive Summary

DevAI Suite is the first Manufacturing-as-a-Service (MaaS) platform — a unified APQP programme management, supplier excellence, and smart factory intelligence environment for automotive and aerospace manufacturers. The platform handles regulated manufacturing data (PPAP submissions, FMEA workbooks, supplier qualifications, plant telemetry) for customers operating under IATF 16949 and AS9100 / AS9145.

This white paper documents how DevAI Suite is designed and operated to protect that data. It is structured around the NIST Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond, Recover) and maps each function to specific controls, technologies, and operational practices. Where certifications are pending, we say so honestly with a defensible audit timeline rather than overclaim.

The intended audience is enterprise security review teams, vendor risk-management functions, and procurement officers performing due diligence ahead of contract signature.

1. Govern — Security Program & Accountability

1.1 Security ownership

A named security lead reports to the founder/CEO and owns:

• Security policy authoring and review (annual cadence; ad-hoc on incident).
• Vendor risk reviews and subprocessor onboarding decisions.
• Incident response coordination.
• Audit and certification programme management.
• Customer security questionnaire responses.

The platform-admin role is bound to a specific user account via the is_platform_admin flag (replacing the deprecated email-comparison check); privilege derives from the database row, not from email. In production the role is covered by MFA through the MFA requirement of DevAI's own organisation; that is an organisation setting, not a rule fixed to the role in code.

1.2 Policies in force

Policies are kept under version control and reviewed by the security lead before each release cycle. Customer-eligible excerpts are available under NDA.

1.3 Personnel security

• Background checks for personnel handling regulated customer data.
• Confidentiality agreements signed at engagement start.
• Onboarding includes security awareness training; annual refresh.
• Access provisioning follows the principle of least privilege; quarterly access review.
• Offboarding is automated where possible (SSO de-provisioning, secret rotation, repository revocation).

1.4 Compliance & certification roadmap

For the audit firms engaged, control narratives, and pre-audit evidence packages, contact admin@devaisuite.com.

2. Identify — Asset Management & Risk

2.1 Asset inventory

The platform's asset surface is bounded and inventoried:

• Application apps: devai-api (FastAPI backend) and devai-web (Next.js frontend) on Fly.io (Frankfurt FRA); the admin console (admin.devaisuite.com) and the marketing site (devaisuite.com) on Cloudflare.
• Data stores: Neon Postgres (Frankfurt, aws-eu-central-1) for all relational data including audit logs; Cloudflare R2 buckets in EU jurisdiction: devai-templates-eu (global template library, plus files attached in AI chat and legacy process documents), devai-tenant-docs-eu (per-org documents and models), devai-db-backups-eu (nightly database dumps) and devai-object-backups-eu (nightly dated copies of the two document buckets).
• Cache / queues: Redis hosted by Upstash (United States) for rate-limit counters, short-lived cached values and real-time message fan-out between API machines; Inngest (background-job orchestration, United States).
• External providers: see §7 Vendor & Subprocessor Management.

The public subprocessor list, with the purpose, the data involved and the processing region of each provider, is at /subprocessor-list.html; §7.2 carries the same list.

2.2 Data classification

2.3 Risk management

Material risks are tracked in an internal risk register reviewed quarterly. Top items as of 2026-Q2:

• Single-region Postgres — single point of failure for the database tier; mitigated by Neon's 24-hour point-in-time history, a nightly dump to a second provider (30 daily / 12 monthly) and a documented restore. Multi-region is on the roadmap as customer scale justifies.
• LLM provider dependency — AI Coordinator depends on a third-party model API: Together AI is the default provider. When Together fails, turns that need no tool call fall back to DevAI's own model served on RunPod, wherever its credentials are configured; by default, tool-calling turns have no fallback provider. Anthropic and OpenAI are break-glass only: they cannot be reached unless an operator switches on the emergency setting, which is off by default, or selects one of them as the model provider.
• Embedding-dimension lock — pgvector schema is fixed at 1024 dimensions (Cloudflare Workers AI @cf/baai/bge-m3); a provider or dimension change requires a coordinated re-embed of the corpus, documented in the embeddings cutover runbook.

2.4 Threat model

The platform is threat-modelled against:

• External attackers — credential stuffing, account takeover, injection, SSRF, supply-chain compromise.
• Malicious or compromised tenants — attempted cross-tenant data access via API enumeration, RAG poisoning, LLM prompt injection.
• Insider threat — over-privileged engineers, departed personnel.
• Third-party compromise — subprocessor breach affecting our data.

Mitigations are described in the relevant sections below.

3. Protect — Controls

3.1 Multi-tenancy & data isolation

Every customer's data lives in a single shared PostgreSQL database, isolated by PostgreSQL Row-Level Security. Every table that holds customer data has an RLS policy keyed to the request's tenant context. The application layer sets the tenant on every database session through the request authentication middleware:

ALTER TABLE deliverables ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON deliverables
  USING (org_id = current_setting('app.current_org_id', true)::int);

A request that leaks tenant context (even via an internal application bug) cannot read or write rows belonging to another tenant — the database refuses. Cross-tenant SELECTs return zero rows by design.

RLS is not merely enabled — it is FORCED (ALTER TABLE … FORCE ROW LEVEL SECURITY), and the application's database role is explicitly NOBYPASSRLS. That means no code path running with application credentials can opt out of tenant isolation: even privileged maintenance operations are subject to it. This is enforced in practice, not just in configuration — our own automated database backups cannot run under application credentials: pg_dump refuses to export RLS-forced tables for a role that cannot bypass RLS (verified in CI on 2026-07-23), so backups run under a separately controlled, provider-managed owner role that never serves application traffic.

Fail-closed by construction. When tenant context is missing or mis-bound, the observable failure is denial (empty result sets, HTTP 403), never cross-tenant exposure. Production incidents in this class have exclusively manifested as functionality being unavailable to the legitimate tenant — the database's default answer to an unbound tenant is zero rows.

The app.db.tenant.set_tenant_context helper is the single seam through which tenant context is applied; it is exercised on every request that resolves a user, before any business logic runs. A CI job (rls-postgres-pr) exercises the RLS posture against real PostgreSQL on every pull request.

3.2 Per-tenant document storage

RAG documents live in Cloudflare R2 with object keys prefixed by org_id. Reads are scoped by the same tenant context, with a server-side check before any presigned-URL issuance.

Embeddings (1024-dim, Cloudflare Workers AI @cf/baai/bge-m3) are stored in pgvector tables that carry an org_id column under the same RLS policy as the source documents.

3.3 Encryption

In transit. TLS 1.2+ on all customer-facing endpoints. Strong cipher suites only (AES-GCM, ChaCha20-Poly1305). HSTS is enforced with max-age=31536000; includeSubDomains. The preload directive is intentionally omitted until every subdomain meets the eligibility criteria. X-Frame-Options is DENY and X-Content-Type-Options is nosniff on every response.

At rest. Postgres data is encrypted at rest by Neon's storage layer. Cloudflare R2 encrypts at rest by default (AES-256). Sensitive integration credentials stored in integration_connectors.credentials_json are envelope-encrypted with a per-deployment Fernet key (DEVAI_CREDENTIALS_ENCRYPTION_KEY); the key is rotated on a documented cadence and never leaves the secret store.

Key management. Application keys (JWT signing, Fernet, OAuth client secrets, third-party API keys) are stored in Fly Secrets, surfaced to the running process at boot, and never persisted to disk. Key rotation procedures are documented per provider in docs/runbooks/disaster-recovery.md §3.

3.4 Authentication & access control

Identity options:

• Email/password — passwords are hashed with PBKDF2-HMAC-SHA256 (passlib CryptContext), with a per-password random salt and iterated key stretching; bcrypt hashes from legacy/migrated accounts remain verifiable. Password history is not enforced; minimum length is 12 characters with complexity requirements (configurable per-org).
• Google SSO via OAuth 2.0.
• Microsoft Entra ID SSO via OAuth 2.0 / OIDC, defaulting to the organizations tenant (work/school accounts) — personal MSA accounts are blocked by the is_business_domain gate.
• SSO-only users have NULL passwords and the password-login route refuses them rather than offering a leaky fallback.

Multi-factor authentication. TOTP-based with single-use backup codes, set by each organisation's policy. DevAI's own organisation requires it, which is how the platform-admin role is covered in production. The MFA enforcement check runs in the auth dependency on every protected request; users with MFA enabled but unverified can only reach the /auth/mfa/verify and /auth/mfa/status endpoints until they verify.

Role-based authorization. Every protected route calls ensure_permission(db, user, resource_type, action, org_id) which checks the user's role-permission grant against the requested action. Decisions are recorded to an append-only policy_decisions audit table.

Session tokens. JWTs with an 8-hour lifetime by default, refreshable up to an absolute session lifetime of 30 days. The token is held in an HttpOnly; Secure; SameSite=Strict cookie that scripts in the page cannot read; it is not kept in localStorage. Signing out ends the session on the server. A password change or reset, switching MFA off or changing the account's e-mail address ends that account's other sessions, and a user can sign out of every device at once.

CAPTCHA. Cloudflare Turnstile gates registration, login, password-reset, MFA enrollment, and the public demo sandbox provisioning route. The server-side verify_turnstile_token helper logs Cloudflare's error-codes field on failure for diagnosis.

Rate limiting. A Redis-backed middleware enforces per-endpoint per-IP limits — sign-in, registration, password and MFA endpoints capped at 10 requests/minute, AI Coordinator feedback at 30/minute, default at 100/minute. When Redis is unreachable the sign-in routes stay limited by a counter held in each API process, at half the usual budget; every other route fails open (availability over rigid limits), and each such request is counted and the outage logged as an error.

3.5 Application security

• OWASP ASVS Level 2 alignment is the baseline.
• Input validation via Pydantic schemas at every API boundary; type strictness enforced at compile time with mypy.
• ORM-only data access (SQLAlchemy); no string-concatenated SQL.
• HTTP responses carry strict security headers (HSTS, X-Frame-Options=DENY, X-Content-Type-Options=nosniff, Referrer-Policy=strict-origin-when-cross-origin). The web application also ships a Content-Security-Policy: default-src 'self', frame-ancestors 'none', explicit lists of the hosts it may load images from and connect to, and no unsafe-eval (WebAssembly compilation is allowed, for the CAD viewer). Inline scripts and styles are still allowed. A CI test guards the policy against loosening.
• SSRF defense: outbound HTTP from the application is bounded to a known allowlist of provider hostnames; arbitrary outbound is not permitted from request-bound code paths.
• Output encoding: React (web app) and Jinja2 (admin) auto-escape; explicit dangerouslySetInnerHTML usage is grep-scrubbed in CI.

3.6 LLM-specific protections

The platform sends AI work to Together AI (default inference, image understanding and speech-to-text), the embedding provider (Cloudflare Workers AI, §7.2) for document embeddings and, when web search is configured, Tavily (the search queries the assistant writes). RunPod serves DevAI's own model: with its credentials configured it is the outage fallback for turns that need no tool call, and it becomes the first choice for in-domain skills only when own-model routing is switched on, which is off by default. Anthropic and OpenAI are break-glass only, unreachable unless an operator switches on the emergency setting (off by default) or selects one of them as the model provider. Specific risks:

• Prompt injection from uploaded documents. Text that did not come from the platform or from the user's own typed message — retrieved document passages, attached files, earlier assistant replies replayed from history and supplier-provided text — reaches the model inside a delimited untrusted-data block. Before it is wrapped, common injection phrasings are redacted and look-alike delimiters are neutralised, so a document cannot close its own block; the system prompt tells the model to treat such blocks as data, never as instructions. This lowers the risk and does not remove it, which is why tool-calling proposals are surfaced for user review before execution (the AIProposal lifecycle).
• Data leaving the platform. Customer data leaves the platform for more than model inference, and §7.2 names each recipient: prompts, retrieved snippets, images and audio go to Together AI; document chunks and search queries to the embedding provider (Cloudflare Workers AI); web-search queries to Tavily; job events to Inngest; error reports to Sentry; usage events to PostHog; an Office file a user previews to Microsoft's viewer; and the nightly database dump and the monthly restore drill run on GitHub-hosted runners. Per-organisation fine-tuning (§10.4) sends an organisation's correction pairs to Together AI and the resulting adapter to Hugging Face; it runs only for an organisation whose administrator has switched on training-data consent.
• Cost exhaustion. Per-org and per-user quotas (configurable; default conservative). The public demo sandbox enforces a 10-message AI Coordinator quota per session.
• Tenant-private fine-tuning. Per-tenant LoRA adapters are trained only on the org's own corrections to AI proposals, and only with its training-data consent (§10.4). The scheduled daily training job is held; today a fine-tune starts only when a platform administrator starts one. Adapters never cross tenants; the inference router selects the right adapter by org_id before calling the model server.

3.7 Secrets management

No secret is ever committed to source control; pre-commit hooks and CI scan for accidental commits.

4. Detect — Monitoring & Audit

4.1 Application logging

Structured JSON logs are emitted for every request and security-relevant event. PII scrubbing is applied at the logging filter (app.core.logging_filters.PIIScrubFilter) before logs leave the application; emails, IP addresses, and other identifiers are redacted in non-debug environments.

4.2 Audit trail

A dedicated org_security_audits append-only table records security-relevant events scoped by org:

• Authentication: login, logout, MFA enrollment, MFA challenge result, password reset, SSO bind/unbind.
• Authorization: role grants, role revocations, permission denials.
• Data access: PPAP submissions, FMEA edits, AI proposal accept/reject, integration credential read/write, sandbox toggle.
• Org lifecycle: creation, deletion request, deletion cancellation, conversion from demo.

Customer admins can request export of their org's audit history via the DSR pipeline. Retention is 7 years for regulated artifacts, 1 year for general events, configurable per-customer in the DPA.

4.3 Error tracking

Sentry captures application exceptions with the FastAPI integration (transactions tagged by endpoint), the SQLAlchemy integration (slow-query detection), and the PII scrubbing filter applied at the logging layer. Profiling sample rate is set to 1% of traced transactions to balance cost and signal.

4.4 Infrastructure monitoring

Fly's automated health checking polls the liveness probe (/livez). The readiness probe (/readyz) pings the database (hard dependency) and Redis (soft, fail-open); it is used for deploy verification and incident triage, and every deploy also proves database reachability by running the schema migrations before any machine is replaced. An external monitor on Cloudflare, outside our own infrastructure, checks the web app, the API and the website every minute and the readiness probe twice an hour, and publishes the result on the public status page, https://status.devaisuite.com (English and Spanish, with a machine-readable feed); an outage it sees opens an incident there automatically.

4.5 Anomaly detection

Rate-limit middleware emits standard X-RateLimit-{Limit,Remaining,Reset} headers and logs anomalies (sudden spikes from a single IP) for review. Integration with a SIEM is on the roadmap once SOC 2 Type II is signed.

5. Respond — Incident Response

5.1 Incident classification

5.2 First-30-minute checklist

A paste-ready operator checklist lives in docs/runbooks/disaster-recovery.md §0:

1. Confirm impact via /readyz.
2. Probe Fly machine status and recent logs.
3. Triage the failure class (DB / Redis / app bug / Fly infra).
4. Post status page update before fixing — sets customer expectations.
5. Mitigate per the relevant runbook section.
6. Communicate to affected tenants directly.

5.3 Customer notification

Where legally required for personal-data breaches under GDPR Article 33, customer notification is targeted within 72 hours of confirmed awareness. The notification includes the nature of the breach, categories and approximate number of data subjects, likely consequences, and the measures taken or proposed to address it.

5.4 Post-incident review

A blameless post-mortem is written within 5 business days for every P0 and P1 incident, capturing the timeline, root cause, contributing factors, and concrete follow-ups. Post-mortems are filed internally and shared with affected customers under NDA.

5.5 Vulnerability disclosure

We publish a security.txt at /.well-known/security.txt with the report contact, admin@devaisuite.com. We acknowledge a report within 48 hours and agree a publication date with the reporter, normally once the fix is live and at most 90 days after the report. Researchers who follow our testing rules in good faith are not subject to legal action under our safe-harbor language.

6. Recover — Disaster Recovery & Continuity

6.1 Backup posture

The primary database runs on Neon, which keeps a continuous write history: any moment in the last 24 hours can be restored, and the restored copy is available within seconds (rehearsed on staging, 9 July 2026). Independently, a nightly logical dump of the production database is written to Cloudflare R2 in EU jurisdiction — a second copy at a second provider — kept 30 days daily and 12 months monthly. The dump is taken on a GitHub-hosted runner, which holds a copy of the database for the length of the job. R2 encrypts the stored dump at rest; encrypting it on the runner before upload is built and switches on once its key has been created. RTO target for full-stack restoration is 30 minutes; RPO is near zero within the 24-hour history window, and up to 24 hours when restoring from the nightly dump.

6.2 Restoration procedure

Documented in detail in docs/runbooks/disaster-recovery.md §1. Summarised:

1. Stop the API to prevent split-brain writes.
2. Identify the point in time before the corruption window.
3. Restore it as a new Neon branch (do NOT overwrite in place — preserves the original for forensics). If Neon itself is unavailable, restore the latest nightly dump into a fresh PostgreSQL instance.
4. Validate against business-metric baselines.
5. Repoint DATABASE_URL to the restored cluster.
6. Bring the API back up.
7. Smoke-test via /readyz and the per-provider health endpoints.

6.3 R2 (object storage) recovery

Cloudflare R2 is single-region and does not version objects. The global template library can be regenerated from source via publish_global_library. Customer documents, trained models and chat attachments are copied every night at 03:00 UTC, server-side, into a dated snapshot in a separate EU-jurisdiction bucket (devai-object-backups-eu), kept 30 days daily and 12 months monthly. A file uploaded after the last copy relies on R2's own durability until the next one. Restoring from a snapshot is documented and has not yet been exercised.

6.4 DR rehearsal cadence

What is tested, how often, and what has been done so far:

Until the monthly drill has produced its first record, the 30-minute RTO is a target, not a measurement. A failed drill is treated as an incident in waiting and is fixed within the week.

6.5 Business continuity

Critical business functions (billing, customer support, on-call rotation) are documented in playbooks separate from the platform itself, so platform unavailability does not block customer recovery efforts.

7. Vendor & Subprocessor Management

7.1 Onboarding

Each new subprocessor is reviewed for:

• Data residency (where they store our customer data).
• Contractual posture: DPA, SCCs (for non-EEA processors handling EU personal data), liability terms.
• Security posture: published certifications (SOC 2, ISO 27001), public security pages, breach history.
• Operational dependency: criticality to the service, ease of switching.

The decision is recorded in the vendor register; renewal review is annual.

7.2 Current subprocessor list

The providers that receive customer data on the cloud service, and the condition that switches each one on where it is not always on.

Public data services. The services below answer questions about the outside world. They receive no customer records, but a query can reveal where a customer's sites, suppliers or shipments are.

Connectors that a customer configures to its own systems (ERP, MES, PLM, SharePoint, Google Drive, webhooks and others) send data where the customer points them, with credentials the customer provides. They are the customer's processors, not DevAI subprocessors, and are not listed here.

The same list is published at /subprocessor-list.html, with the data each provider may receive and the date of its last update. The compliance column records what each provider publishes about itself; collecting and reviewing the reports themselves is part of DevAI's annual vendor review. Customer notification of subprocessor changes follows the cadence in the customer's DPA (typically 30 days advance notice for material changes).

7.3 Subprocessor change review

Customers are notified of subprocessor changes per DPA cadence and may object within the contractual window. Where a customer's objection cannot be reconciled with the new subprocessor, the contract permits termination per the DPA.

8. Secure Software Development Lifecycle

8.1 Source control & review

• Single canonical repository on GitHub.
• Branch protection on main: required PR reviews, required status checks, force-push disabled.
• Pre-commit hooks: lint, type check, secret scan.
• CI on every PR: full test suite (currently ~3,000 tests across smoke and full tiers).

8.2 Testing

8.3 Dependency management

• GitHub Dependabot enabled; weekly PRs for security advisories.
• Manual review of every dependency update; security-relevant patches land within 7 days for high-severity advisories, 30 days for medium.
• No outdated framework majors: Python 3.11 (CI canonical), Node 20+, FastAPI / Pydantic / SQLAlchemy current.

8.4 Migration discipline

Database schema changes flow through Alembic migrations, reviewed and idempotent. Production runs alembic upgrade head as a release-command pre-flight. Rollbacks are tested; destructive migrations carry a --confirm gate.

8.5 Static analysis

• Type checking is the primary static-analysis tool (mypy + tsc strict).
• flake8 for Python style.
• ESLint for TypeScript.
• Semgrep runs in CI on every pull request and on main: a finding that a pull request introduces fails the check, and findings that were already there are reported for triage.

8.6 Configuration validation at startup

validate_production_config(settings) runs in the FastAPI lifespan startup. The application refuses to boot when:

• A required production secret is missing.
• STRIPE_LIVE=true is set but the Stripe key is not an sk_live_ key (live-mode mismatch).
• Other invariants required to avoid unsafe states.

This catches configuration drift before it can serve a single request.

9. Data Handling

9.1 Data lifecycle

9.2 Data residency

The application tier runs in Fly's Frankfurt (FRA) region and the primary database in Neon's Frankfurt region (aws-eu-central-1). Cloudflare R2 buckets are in EU jurisdiction. The Redis cache (Upstash), the default model provider (Together AI), job orchestration (Inngest), error monitoring (Sentry) and transactional e-mail (Resend) are in the United States. Document embeddings run on Cloudflare Workers AI, which offers no region choice, so that processing is not pinned to the EU. The region of every provider is in §7.2.

For customers with strict residency requirements, on-premise / dedicated-region deployment is available on Enterprise plans.

9.3 Data subject rights (GDPR / CCPA / CPRA)

The DSR pipeline supports:

• Right to access — full export of the customer's data on request.
• Right to deletion — within 30 days, with confirmation to the requester.
• Right to rectification — handled via the platform UI by org admins.
• Right to portability — JSON export aligned with the same export contract as access.
• Right to object / restrict — handled per the DPA's processing-purposes table.

Requests are logged and tracked through the audit trail.

9.4 Cross-border transfer

Where personal data of EU subjects is processed by US-based subprocessors (LLM providers, Stripe, etc.), the transfer is governed by:

• Standard Contractual Clauses (SCCs) included in the DPA.
• Supplementary measures where required (encryption-in-transit, no plaintext logging at the provider).

The full transfer-impact assessment is internal but available to enterprise customers under NDA.

10. AI-Specific Considerations

10.1 What's sent to LLM providers

Inference calls send:

• The user's prompt (system prompt + user message).
• Retrieved RAG context (the organisation's own documents, limited to those the user may see).
• The results of tools the assistant called during the conversation.
• Images and recorded audio, when the user supplies them (image understanding and speech-to-text).
• Per-tenant adapter pointer (Phase 3 inference router only — never an adapter from another tenant).

Two further flows are not inference: document chunks and search queries go to the embedding provider (Cloudflare Workers AI), and when web search is configured the search query the model writes goes to Tavily. Such a query can carry context from the conversation.

What's NOT sent:

• Other customers' data.
• Internal application secrets, API keys, system credentials.
• The customer's authentication tokens.

10.2 Provider data-handling

Two per-organisation settings govern AI data, and they are separate. Knowledge indexing is on by default: it decides whether the assistant draws on the organisation's own indexed documents. It is a product setting, not a training consent. Training-data consent (training_data_opt_in) is off by default and is switched on by the organisation's administrator, with who switched it on and when recorded. It decides whether that organisation's corrections to AI proposals are captured as training pairs, and a fine-tune runs only while it is on (§10.4). An organisation with no consent record is treated as not having consented.

10.3 AI proposal review

The platform's AI Coordinator never executes destructive actions silently. Any LLM-generated change to customer data flows through the AIProposal lifecycle:

1. AI generates a proposal (FMEA row, dashboard tile, document classification).
2. Proposal is stored with status=draft and surfaced to the user.
3. User reviews and explicitly accepts; rejection is also recorded with optional correction text for tenant-learning.
4. Only on accept does the platform commit the change to customer data.

This prevents silent data corruption from a hallucinated LLM response and creates an audit trail for every AI-driven change.

10.4 Tenant-learning isolation

Per-tenant LoRA adapters can be trained on the org's own corrections to AI proposals. The scheduled daily training job is held; today a fine-tune starts only when a platform administrator starts one. Critical consent and isolation properties:

• Corrections are captured as training pairs only while the org's training-data consent is on (§10.2).
• A fine-tune starts only if that consent is on at the moment the job starts; an org with no consent record is treated as not having consented. Demo orgs (is_demo=True) and organisations inside a sandbox window (sandbox_unlimited_until in the future) are skipped.
• Training data for each adapter is sourced exclusively from one org's tenant_learning_events rows, scoped by RLS.
• The training pairs are uploaded to Together AI (US) for the job and deleted from Together's file store when the job ends.
• Trained adapters are tagged with org_id and stored in private repositories of DevAI's own organisation on Hugging Face (US), one per org, skill and version (<skill>-org-<id>-v<n>).
• The inference router selects the active adapter for the request's org_id before dispatching to RunPod / Together; cross-tenant adapter selection is impossible by design (tested in the Phase 3c wiring suite).
• An adapter is never activated automatically: an operator activates it, normally only after it has beaten the base model on a held-out evaluation; an explicit operator override exists for re-activating a known adapter.

11. Customer Responsibilities (Shared Model)

Security is shared. Customers are responsible for:

• User management: adding, removing, and reviewing authorised users in their org. Disable departed users promptly.
• Credential hygiene: strong passwords; MFA where the org policy permits it; not sharing credentials.
• Configuration: enabling allowed-email-domains, MFA enforcement, and the data-residency settings appropriate for the customer's compliance posture.
• Data classification: assessing what data they choose to upload to the platform. The platform is suitable for typical APQP/manufacturing data; customers with stricter classifications (export-controlled, classified, etc.) should consult before upload.
• Output validation: AI-generated outputs must be reviewed before being relied upon for regulated decisions (PPAP submissions, customer deliverables, etc.). The AI Coordinator's confidence indicators are a starting point, not a substitute for SME review.
• Integration credentials: rotating their own credentials for connected systems (Salesforce, SAP, ERP, MES) per their internal policy.

A copy of this customer-responsibility list is in the Master Service Agreement and the DPA.

12. Contacts

PGP public key for security correspondence is available on request.

13. Document control

This white paper is reviewed at least annually and on every material change to the platform's security posture. The authoritative source is docs/security/WHITEPAPER_EN.md in the platform's source repository.

A Spanish-language version is maintained in parallel at docs/security/WHITEPAPER_ES.md and rendered at /es/security-whitepaper.html.

© 2026 DevAI Suite. This document may be redistributed unchanged for the purpose of vendor security review. Excerpts must retain attribution.