Cambridge Analytica 2.0: How Enterprise AI Can Rebuild Company Secrets From Data It Was Allowed to See, and Why Frontier Models Alone Cannot Stop It

The 2018 Cambridge Analytica scandal did not need a hacked database. Personal data that people had shared for one purpose was reportedly collected through a third-party app, joined into psychological profiles and reused for political targeting. The lesson was simple: permission to see data is not permission to combine it. Enterprise AI is about to repeat that lesson inside companies, at machine speed. AI assistants and agents are being connected to customer records, engineering tickets, source code, supplier orders, budgets, HR systems, calendars and long-term memory. Each connection can be approved on its own. Yet by linking those fragments, an AI workload can work out things no system ever stored: an unreleased product, a launch date, a merger target, a vulnerable supplier, or a detailed profile of an employee or customer. A compromised agent, a prompt-injected document, a careless integration or a third-party AI with broad connectors could quietly turn a company’s own data into a map of its future. That is Cambridge Analytica 2.0. Better models do not fix this: A more capable frontier model is better at connecting the dots, not worse. Guardrails, system prompts and safety training run inside the same software an attacker can steer. No model can withhold a key it already holds. Encryption, separate databases and connector permissions protect each source, but not the relationships between sources. Without concrete, cryptographically enforced separation that companies and partners can verify, enterprises will keep their most valuable data away from even the best AI. This work proposes Technical Non-Joinability: the authority to access information is separated from the authority to associate it. Separate domains. Identity data, content, relationship mappings, keys and authorisation state live in independently controlled protection domains. Scoped authorisation. Each request receives a non-bearer, session-bound authorisation that states exactly which fields and relationships may be joined, for which purpose and under which policy version. Independent release. Each vault decides independently whether to release its part, and released data cannot be reused as a general-purpose token. Temporary minimum view. Only the permitted relationships are formed, inside a protected reconstruction environment, as a temporary minimum-necessary view. Release control. Any generated answer or proposed tool action stays inactive until current conditions are re-checked, a protected receipt is committed, and a single-use release permission is consumed at a mandatory release point. The test is simple: if the AI workload is fully compromised but the association authority is not, the protected relationship must stay out of reach. The architecture is described as 79 implementation and functional profiles. They cover multi-vault separation, output release, streaming, attestation, agent tool calls, runtime behaviour checks, provenance, prompt-injection mediation and multi-authority policy. Pseudocode, formal invariants and a runnable reference implementation are included. Industry relevance (AI-generated). The work addresses the enterprise-AI deployment class in which assistants and agents connect to many business systems at once. Publicly described examples of that class include: Microsoft 365 Copilot and Copilot Studio Google Gemini Enterprise OpenAI ChatGPT Enterprise Anthropic Claude and the Model Context Protocol Amazon Q Business and Amazon Bedrock Salesforce Agentforce ServiceNow AI Agents xAI Grok for Business It also concerns confidential-computing platforms, retrieval-augmented generation, enterprise search, MCP servers and AI governance tooling, under GDPR purpose limitation, the EU AI Act, trade-secret law, DORA and NIS2. These products are named only as examples of where the architecture could apply. Naming them does not allege that any product is vulnerable, deficient, non-compliant or infringing, and it does not describe any undisclosed internal design. The Cambridge Analytica comparison is an illustration of a risk pattern, not an accusation against any company. This industry-relevance material is AI-generated and must be cross-checked against the original PCT filings and primary sources before drawing any conclusion. This disclosure is based on the Mothership application PCT/IB2026/055615, filed 4 June 2026 and publicly disclosed 16 July 2026 (WO 2026/150382), which claims priority from PCT/IB2026/053385, filed 7 April 2026 and publicly disclosed 4 June 2026 (WO 2026/115520). The profile details are as published in Internet-Draft draft-das-enterprise-ai-enforcement-profiles-01 on 19 September 2026. Related family applications can be cross-checked on WIPO PATENTSCOPE. Licensed under CC BY-NC 4.0. The author is open to acquihire or strategic collaboration. Keywords Cambridge Analytica 2.0; enterprise AI security; AI data aggregation; inference attack; purpose laundering; data minimisation; purpose limitation; technical non-joinability; access is not association; frontier model limitations; prompt injection; AI agent security; Model Context Protocol security; RAG security; enterprise search security; Microsoft 365 Copilot; Copilot Studio; Gemini Enterprise; ChatGPT Enterprise; Claude; Amazon Q Business; Amazon Bedrock; Agentforce; ServiceNow AI Agents; Grok for Business; confidential computing; zero trust; trade secret protection; data sovereignty; GDPR; EU AI Act; DORA; NIS2; AI governance; machine enforcement.