For decades, protecting trade secrets was primarily an exercise in controlling physical and corporate boundaries.

Keep the engineering drawings in a locked room. Restrict access to the source code repository. Require employees to sign nondisclosure agreements. Put sensitive documents behind a firewall. Keep competitors away from the company’s intellectual property.

The cloud changed that model.

Artificial intelligence is changing it again.

Today, an employee can take a confidential product design stored in a corporate cloud environment, paste part of it into an AI assistant, ask the model to analyze it, and receive a useful answer in seconds. The employee may never think of the action as “disclosing a trade secret.” From the employee’s perspective, they are simply using another productivity tool.

From the company’s perspective, however, sensitive intellectual property may have just crossed another organizational boundary.

That boundary might involve a cloud provider, a SaaS application, an AI model provider, an AI application developer, a subcontractor, a data-center operator, or another downstream processor.

The fundamental security problem is therefore no longer simply:

Who inside the company can access the data?

It has become:

Who can access the data anywhere along the technology supply chain?

That is a much harder question.

Trade secrets depend on secrecy

The stakes are particularly high because trade-secret protection is closely connected to an organization’s efforts to maintain confidentiality.

Under U.S. federal law, a trade secret includes qualifying technical, financial, business, scientific, engineering and other information when the owner takes “reasonable measures” to keep it secret and the information derives economic value from not being generally known.

That creates an important security lesson.

A company cannot simply declare something to be a trade secret and assume the designation will protect it forever.

The organization needs to behave as though the information is actually secret.

That means controlling:

• who can access it;
• where it is stored;
• how it is transmitted;
• who processes it;
• how long it is retained;
• whether copies exist;
• whether third parties can access it;
• whether employees can put it into external applications;
• whether AI systems can ingest it;
• whether vendors use it for training or other purposes;
• and whether the organization can demonstrate that reasonable safeguards were actually implemented.

Cloud computing and AI make every one of these questions more complicated.

The Cloud Changes the Security Boundary

The traditional corporate data center gave organizations a relatively intuitive security boundary.

The company owned the servers, controlled physical access, selected the operating systems, managed the network, and generally knew where sensitive information was physically located.

Cloud computing replaces much of that model with a shared-responsibility arrangement.

For example, AWS explicitly describes cloud security as a shared responsibility. AWS protects the underlying infrastructure, while customers remain responsible for security within the cloud, with the precise division depending on the services being used. (Amazon Web Services, Inc.)

This distinction is critically important.

Moving data to the cloud does not mean transferring responsibility for protecting that data to the cloud provider.

In many cases, the cloud provider secures the building, hardware, virtualization infrastructure and certain managed services.

The customer still has to secure:

• identities;
• credentials;
• permissions;
• applications;
• configurations;
• encryption keys;
• databases;
• storage buckets;
• network controls;
• API access;
• endpoints;
• logging;
• data classification;
• and the data itself.

A perfectly secure cloud provider cannot protect an organization from an employee accidentally making a confidential database publicly accessible.

Cloud creates a different threat model

Cloud computing introduces several categories of risk.

1. Misconfiguration

One of the simplest ways sensitive information can escape is through incorrect configuration.

Examples include:

• publicly accessible object storage;
• overly broad IAM permissions;
• exposed API keys;
• improperly configured databases;
• unrestricted administrative interfaces;
• excessive service-account privileges;
• insecure network rules;
• or logging systems containing sensitive information.

The cloud may provide extremely sophisticated security controls, but those controls do not automatically configure themselves according to the organization’s risk tolerance.

2. Credential compromise

The attacker does not necessarily need to compromise the cloud provider.

Compromising an employee’s identity may be enough.

A stolen privileged account can potentially provide access to:

• source code;
• intellectual property;
• customer information;
• financial data;
• research;
• product roadmaps;
• internal communications;
• and cloud infrastructure.

Consequently, identity has become one of the most important security boundaries in cloud environments.

3. Provider compromise

The cloud provider itself can experience a security incident.

The probability may be relatively low for a mature hyperscaler, but the potential consequences are enormous because one provider can host data belonging to thousands of organizations.

This creates a concentration-of-risk problem.

4. Insider access

Cloud providers employ people who operate and maintain infrastructure.

Organizations therefore need to understand what controls exist around privileged provider personnel.

Questions include:

• Can provider employees access customer data?
• Under what circumstances?
• Is access logged?
• Is it approved?
• Is it limited to specific employees?
• Are support engineers able to view customer content?
• Can administrators access encryption keys?
• Are administrative actions independently monitored?

Cloud vendors have invested heavily in these controls, but customers generally do not receive unlimited visibility into the provider’s internal environment.

5. Subprocessors

The cloud provider itself may not be the end of the chain.

A service may depend on other companies for:

• support;
• monitoring;
• analytics;
• telecommunications;
• identity;
• security;
• data processing;
• customer support;
• infrastructure;
• or other specialized functions.

Google’s current Cloud Data Processing Addendum, for example, explicitly addresses subprocessors and provides information about their names, locations and activities. It also describes contractual and security requirements for subprocessors. (Google Cloud)

This is important because the real question is not merely:

“Is my data in Google Cloud?”

It may be:

“Which organizations can potentially process my data because I use Google Cloud?”

That is a substantially larger question.

On-Premises vs. Cloud: Which Is More Secure?

There is no universal answer.

Cloud is not inherently insecure, and on-premises infrastructure is not inherently secure.

The more useful comparison is control versus operational burden.

Area	On-Premises	Cloud
Physical control	High	Low
Physical security responsibility	Customer	Primarily provider
Infrastructure visibility	High	Limited
Scalability	Limited/expensive	Excellent
Security expertise required	High	High, but distributed
Identity management	Customer	Shared/customer controlled
Hardware maintenance	Customer	Provider
Data-center operations	Customer	Provider
Network control	Very high	High, but provider-dependent
Encryption	Customer-controlled	Customer/provider shared depending on service
Insider risk	Internal employees	Internal + provider personnel
Subprocessor exposure	Lower	Potentially higher
Availability options	Customer-funded	Multiple provider options
Disaster recovery	Customer-funded	Often easier to architect
Misconfiguration risk	Significant	Significant
Vendor lock-in	Lower	Potentially significant
Physical data location	Usually easier to determine	Service-dependent
Security evidence	Internal audits	Certifications, SOC reports, documentation
Ultimate responsibility for data	Customer	Customer

The biggest misconception is that on-premises means “secure” and cloud means “someone else is responsible.”

Neither is true.

An organization with poorly patched servers, weak identity controls, inadequate segmentation and no monitoring can have a disastrous on-premises security posture.

A properly architected cloud environment can have stronger security controls than many corporate data centers.

The difference is that cloud introduces dependency.

The company must trust another organization to operate critical infrastructure correctly.

Encryption Is Necessary — But Not Sufficient

Encryption should be fundamental to trade-secret protection.

Sensitive data should generally be protected:

• at rest;
• in transit;
• and, where appropriate, while being processed.

The last category is particularly interesting.

Traditional encryption protects data while it is stored and transmitted. But applications normally need plaintext data while performing computations.

Confidential computing attempts to address this problem by processing information inside hardware-based trusted execution environments. Microsoft, for example, describes Azure confidential computing as a mechanism for protecting data in use, including from certain cloud-operator access scenarios. (Microsoft Learn)

For extremely sensitive intellectual property, organizations should consider whether technologies such as:

• customer-managed encryption keys;
• hardware security modules;
• confidential computing;
• tokenization;
• format-preserving encryption;
• data masking;
• and privacy-enhancing technologies

are appropriate.

But encryption also introduces a critical question:

Who controls the keys?

If the cloud provider controls everything necessary to decrypt the organization’s most sensitive information, the organization has less independent control than if it maintains exclusive or tightly governed control of the cryptographic keys.

For highly sensitive trade secrets, customer-controlled keys can therefore be an important architectural requirement.

AI Creates a New Data-Disclosure Problem

Cloud computing moved corporate data outside the traditional corporate perimeter.

Generative AI can move it outside the perimeter almost invisibly.

Consider a simple example.

An engineer encounters a difficult software problem.

They copy a proprietary function into an AI assistant and ask:

“Find the vulnerability in this code.”

The AI may provide an excellent answer.

But the organization has potentially disclosed:

• proprietary source code;
• architecture information;
• vulnerability information;
• internal naming conventions;
• business logic;
• dependencies;
• and potentially information about an unreleased product.

The employee may have solved the immediate problem while creating a much larger security problem.

This is the fundamental challenge of enterprise AI:

AI makes data extraordinarily useful — and therefore extraordinarily tempting to share.

AI Is Often Another Third-Party Processor

Organizations sometimes treat AI as though it were merely software running on an employee’s computer.

Increasingly, it is not.

A typical enterprise AI architecture can look like this:

Employee

↓

Corporate application

↓

AI gateway

↓

AI application/SaaS provider

↓

Model provider

↓

Cloud infrastructure provider

↓

Subprocessors

The data may therefore pass through multiple organizations.

That creates a supply-chain problem.

An organization evaluating an AI vendor needs to determine not only how the vendor protects data, but also who else can process it.

NIST’s Generative AI Profile specifically recommends maintaining inventories of third parties with access to organizational content and establishing approved AI technology and service-provider lists. It also recommends contractual provisions allowing organizations to evaluate third-party generative-AI processes and standards. (NIST Publications)

That is an excellent foundation for an enterprise AI security program.

The “Training My Data” Question Is Only One Question

One of the most common questions organizations ask AI providers is:

“Do you train your model on my data?”

It is an important question.

It is not enough.

An organization should also ask:

1. Is the data stored?
2. For how long?
3. Where is it stored?
4. Who can access it?
5. Are employees able to access it?
6. Can contractors access it?
7. Which subprocessors receive it?
8. Is it used for abuse monitoring?
9. Is it used for model evaluation?
10. Is it used for product improvement?
11. Is it used for debugging?
12. Are prompts retained?
13. Are outputs retained?
14. Are embeddings retained?
15. Are uploaded files retained?
16. Are vector databases retained?
17. Are backups retained?
18. Can data be deleted on request?
19. How quickly is it deleted?
20. Does deletion include backups?
21. What happens when the contract ends?
22. Can the organization obtain an audit?
23. What happens during a security incident?

The distinction between model training and data processing is critical.

A vendor could truthfully say:

“We don’t train our models on your data.”

while still retaining prompts and outputs for other operational purposes.

For example, OpenAI currently states that business products and the API do not use customer inputs and outputs for model training by default. Its published enterprise information also describes retention and restricted access practices for API data. (OpenAI)

That is useful transparency.

But an enterprise security team should still evaluate the complete data lifecycle rather than stopping at the training question.

The AI Application May Be More Dangerous Than the Model

There is another important distinction.

The model itself may not be the primary security risk.

The application surrounding the model may be.

Consider an AI agent with access to:

• email;
• SharePoint;
• GitHub;
• Salesforce;
• financial systems;
• internal databases;
• cloud storage;
• ticketing systems;
• source code;
• and corporate messaging.

The AI model becomes an intermediary between the employee and those systems.

Now imagine a malicious prompt, poisoned document, compromised integration, or overly permissive API.

The resulting problem is no longer simply “AI hallucination.”

It becomes an authorization problem.

The AI may have legitimate credentials but make an inappropriate request.

This is why AI security needs to be integrated with traditional identity and access management.

The Principle of Least Privilege Must Apply to AI

Organizations should never give an AI agent more authority than it needs.

A useful rule is:

Treat AI agents like untrusted employees with machine-speed capabilities.

That means:

• separate identities for AI agents;
• narrowly scoped permissions;
• short-lived credentials;
• explicit authorization boundaries;
• strong authentication;
• network segmentation;
• API gateways;
• detailed logging;
• approval workflows for high-risk actions;
• rate limiting;
• data-loss prevention;
• and continuous monitoring.

An AI agent that can read corporate documents does not necessarily need permission to delete them.

An agent that can analyze source code does not necessarily need access to production credentials.

An agent that can summarize contracts does not necessarily need permission to send email to external recipients.

AI should therefore receive task-specific privileges, not general corporate privileges.

Data Classification Becomes Essential

One of the biggest mistakes organizations make is attempting to protect every piece of corporate information identically.

That is expensive and ineffective.

Organizations should classify information according to business impact.

A practical model might be:

Public

Information intended for public distribution.

Examples:

• marketing materials;
• press releases;
• public documentation.

Internal

Information intended for employees.

Examples:

• internal procedures;
• ordinary business communications.

Confidential

Information whose unauthorized disclosure could cause meaningful harm.

Examples:

• contracts;
• customer information;
• internal financial information.

Restricted

Highly sensitive information.

Examples:

• source code;
• acquisition plans;
• pricing algorithms;
• unreleased products.

Crown jewels / trade secrets

Information whose disclosure could materially damage the organization’s competitive position.

Examples:

• proprietary algorithms;
• chemical formulas;
• manufacturing processes;
• unreleased technology;
• proprietary models;
• highly sensitive research.

The higher the classification, the fewer external services should be allowed to process it.

Organizations Need an AI Data-Handling Policy

“Don’t put confidential information into ChatGPT” is not an adequate enterprise policy.

Employees need practical rules.

A mature policy should specify:

Allowed

• public information;
• approved corporate AI systems;
• sanitized information;
• synthetic data;
• approved internal datasets.

Restricted

• customer data;
• confidential contracts;
• source code;
• employee information;
• security incidents;
• unreleased financial information.

Prohibited without explicit authorization

• trade secrets;
• cryptographic keys;
• passwords;
• production credentials;
• highly sensitive source code;
• acquisition targets;
• unreleased product designs.

More importantly, the policy should identify which AI systems are approved.

Employees should not have to guess.

Establish an Enterprise AI Gateway

One of the strongest architectural recommendations is to put a controlled gateway between employees and external AI providers.

Instead of:

Employee → Public AI Service

use:

Employee → Corporate AI Gateway → Approved AI Provider

The gateway can enforce:

• authentication;
• authorization;
• data classification;
• DLP inspection;
• prompt filtering;
• sensitive-data detection;
• vendor routing;
• logging;
• rate limiting;
• retention controls;
• model selection;
• policy enforcement;
• and incident response.

For example, the gateway could detect a Social Security number, private cryptographic key or source-code repository identifier and prevent transmission to an external model.

This transforms AI security from an employee-training problem into an enforceable technical control.

Vendor Transparency: How Much Is Enough?

This is one of the hardest questions.

Cloud and AI providers have become significantly more transparent over time.

Major providers publish:

• SOC reports;
• ISO certifications;
• security documentation;
• privacy documentation;
• data-processing agreements;
• subprocessor lists;
• compliance information;
• incident information;
• architecture documentation;
• encryption information;
• identity and access-control documentation.

That is valuable.

But there is an important distinction between security assurance and security transparency.

A SOC 2 report does not give a customer unrestricted visibility into the provider’s entire infrastructure.

An ISO certification does not mean the customer’s particular deployment is configured securely.

A security white paper does not reveal every implementation detail.

A subprocessor list does not necessarily provide a complete technical map of every system involved in processing a particular transaction.

Consequently, vendors generally provide evidence of security, not complete visibility into security.

And there is a legitimate reason for this.

A cloud provider cannot publicly disclose every internal security control without potentially creating a roadmap for attackers.

The challenge for customers is therefore finding the right balance between:

“Trust us.”

and

“Here’s enough evidence for you to verify that trust.”

What Organizations Should Demand From Cloud Vendors

For critical systems, organizations should establish a formal vendor-security assessment.

At minimum, ask for:

Governance

• SOC 2 Type II
• ISO 27001
• relevant industry certifications
• security governance structure
• security incident history
• penetration-testing practices

Data

• data locations;
• data residency;
• data retention;
• deletion procedures;
• backup retention;
• replication;
• data ownership;
• legal-access policies.

Encryption

• encryption at rest;
• encryption in transit;
• key management;
• customer-managed keys;
• HSM availability;
• key rotation;
• provider access to keys.

Identity

• privileged-access management;
• MFA;
• role-based access;
• administrative logging;
• access reviews;
• separation of duties.

Infrastructure

• network segmentation;
• tenant isolation;
• vulnerability management;
• patch management;
• malware protection;
• physical security.

Incident response

• notification timelines;
• incident-response procedures;
• forensic cooperation;
• evidence preservation;
• customer communication.

Supply chain

• subprocessor list;
• subprocessor security requirements;
• notification of new subprocessors;
• right to object;
• supply-chain security.

Google’s current cloud terms, for example, explicitly provide information concerning subprocessors and describe security and contractual requirements imposed on them. (Google Cloud)

What Organizations Should Demand From AI Vendors

AI vendors require a somewhat different questionnaire.

In addition to traditional SaaS questions, organizations should ask:

Model-data questions

• Is customer data used for training?
• Is training opt-in or opt-out?
• Are prompts stored?
• Are outputs stored?
• Are files stored?
• Are embeddings stored?
• How long is information retained?

Human access

• Can employees see prompts?
• Can contractors see prompts?
• Under what circumstances?
• Is human access logged?
• Is customer approval required?

Model lifecycle

• How are models updated?
• Can model behavior change without notice?
• Can customers pin a model version?
• Are changes documented?
• Is there regression testing?
• Can customers opt out of certain model changes?

AI supply chain

• Who hosts the model?
• Who provides the GPUs?
• Who provides the inference infrastructure?
• Who operates the vector database?
• Who processes telemetry?
• Who provides content moderation?
• Which subprocessors can access customer data?

Security

• prompt injection defenses;
• data isolation;
• tenant isolation;
• model access controls;
• API security;
• secrets management;
• logging;
• abuse detection;
• incident response.

Agent security

If the system supports agents, also ask:

• What systems can agents access?
• What permissions can they receive?
• Can customers restrict tools?
• Can customers require approval before external actions?
• Are tool calls logged?
• Can agents access other users’ information?
• Can agents execute code?

This last category is becoming increasingly important.

AI Supply Chains Are Becoming Cloud Supply Chains

The distinction between “cloud security” and “AI security” is beginning to disappear.

Modern AI services frequently depend on cloud infrastructure.

Cloud services increasingly contain AI capabilities.

Enterprise applications increasingly embed third-party models.

The result is a technology chain that might look like:

Company

↓

SaaS provider

↓

AI application

↓

AI model provider

↓

Cloud provider

↓

Hardware provider

↓

Additional subprocessors

Every layer potentially introduces:

• access;
• dependency;
• concentration risk;
• legal risk;
• operational risk;
• security risk;
• and data exposure.

The organization’s security team therefore needs a third-party data-flow inventory, not merely a vendor list.

Build a Data Lineage Map

For every sensitive dataset, organizations should be able to answer:

Where did the data originate?

↓

Where is it stored?

↓

Which applications access it?

↓

Which cloud services process it?

↓

Which AI services process it?

↓

Which subprocessors receive it?

↓

Where are copies created?

↓

Where are backups stored?

↓

When is everything deleted?

If the security team cannot answer these questions, it does not have adequate visibility into the organization’s trade-secret exposure.

Use Zero Trust for Data, Not Just Networks

Zero Trust is frequently described in terms of users and devices.

For trade-secret protection, it should also apply to data.

A useful principle is:

Never assume that because an application is inside the corporate environment, it should automatically have access to sensitive information.

Access should depend on:

• identity;
• device;
• application;
• location;
• data classification;
• business purpose;
• risk;
• and context.

The same principle should apply to third-party services.

An AI application should not receive an entire corporate database simply because it needs five records to answer a question.

The application should receive only what it needs.

Minimize the Data Sent to AI

The strongest AI data-protection technique is often the simplest:

Don’t send the data.

Before sending sensitive information to an external model, organizations should consider:

Redaction

Remove unnecessary sensitive fields.

Tokenization

Replace sensitive values with tokens.

Pseudonymization

Replace identities with pseudonymous identifiers.

Data minimization

Send only the fields required to perform the task.

Retrieval controls

Allow AI to retrieve only authorized documents.

Synthetic data

Use generated or sanitized datasets for development and testing.

Local models

For particularly sensitive applications, consider running an AI model in infrastructure controlled by the organization.

Should Sensitive AI Run On-Premises?

Sometimes.

Running an AI model on-premises can provide significant advantages:

• greater control over data;
• reduced dependence on external model providers;
• greater control over logging;
• greater control over retention;
• reduced external data transfer;
• greater control over network isolation.

But there are trade-offs.

Organizations must assume responsibility for:

• hardware;
• GPUs;
• operating systems;
• model deployment;
• patching;
• security;
• model updates;
• monitoring;
• availability;
• scaling;
• and operational expertise.

On-premises AI is therefore not automatically more secure.

It is simply more controllable.

For highly sensitive trade secrets, however, control can be extremely valuable.

A Hybrid Model May Be the Best Answer

Many organizations should adopt a hybrid approach.

For example:

Public AI

→ public and low-risk information.

Enterprise AI

→ internal business information.

Private AI

→ confidential information.

Isolated/on-premises AI

→ crown-jewel trade secrets.

This approach allows organizations to obtain the productivity benefits of AI without treating every piece of corporate information as equally suitable for an external service.

Continuous Vendor Assessment Is Necessary

Vendor security questionnaires are often performed once a year.

That is not sufficient for highly critical providers.

A vendor’s security posture can change because of:

• acquisitions;
• new subprocessors;
• new models;
• new data centers;
• new jurisdictions;
• product changes;
• changes in retention policies;
• changes in ownership;
• vulnerabilities;
• security incidents;
• or changes in contractual terms.

Organizations should therefore establish risk-based monitoring.

A low-risk SaaS provider might receive an annual assessment.

A cloud provider hosting trade secrets might require continuous monitoring and annual formal reassessment.

An AI provider with access to source code or proprietary research may warrant even more intensive oversight.

Recent corporate cybersecurity disclosures demonstrate that organizations are increasingly incorporating cloud and third-party providers into formal cybersecurity-risk management programs, including vendor assessments, security questionnaires, independent reports, contractual requirements and ongoing monitoring.

The Contract Is a Security Control

Contracts are frequently treated as legal documents rather than cybersecurity controls.

That is a mistake.

For sensitive data, contracts should address:

• data ownership;
• permitted processing;
• prohibited processing;
• retention;
• deletion;
• encryption;
• security standards;
• incident notification;
• subcontractors;
• audit rights;
• penetration testing;
• data location;
• regulatory requirements;
• confidentiality;
• breach liability;
• indemnification;
• business continuity;
• disaster recovery;
• termination;
• data export;
• and destruction.

For AI, add:

• model training;
• model improvement;
• prompt retention;
• output retention;
• human review;
• model changes;
• model versioning;
• AI subprocessors;
• agent permissions;
• and customer control over data.

NIST’s Generative AI Profile specifically recommends contractual provisions that allow organizations to evaluate third-party AI processes and standards. (NIST Publications)

That should become standard procurement practice.

The Vendor Questionnaire Should Become a Technical Assessment

A 300-question spreadsheet is not necessarily evidence of good security.

Security teams should focus on questions that actually affect risk.

For example:

Can you provide evidence that customer data is encrypted using keys that your personnel cannot access?

is more useful than:

Do you have an encryption policy?

Similarly:

Provide the current list of subprocessors that can process customer data and identify their processing location and function.

is more useful than:

Do you manage third-party risk?

The goal should be evidence, not paperwork.

What Does “Good Enough” Vendor Transparency Look Like?

For a low-risk service, publicly available certifications and security documentation may be sufficient.

For a service processing sensitive intellectual property, the bar should be much higher.

A mature vendor should ideally provide:

Level 1 — Public transparency

• security documentation;
• privacy policy;
• compliance certifications;
• subprocessor information.

Level 2 — Customer assurance

• SOC reports;
• penetration-test summaries;
• security questionnaires;
• contractual commitments;
• data-processing agreements.

Level 3 — Technical transparency

• architecture information;
• encryption details;
• access-control descriptions;
• logging capabilities;
• retention controls;
• data-location information.

Level 4 — Customer verification

• audit rights;
• independent assessments;
• evidence upon request;
• incident cooperation;
• contractual verification rights.

Level 5 — Customer control

• customer-managed keys;
• configurable retention;
• customer-controlled deletion;
• private connectivity;
• isolated environments;
• confidential computing;
• granular access controls.

The most secure vendors are not necessarily those that reveal everything.

They are those that provide customers with sufficient evidence and control to make informed risk decisions.

A Trade-Secret Protection Architecture for 2026

Organizations looking for a practical architecture should consider the following model:

Layer 1 — Classification

Identify trade secrets and classify information according to business impact.

Layer 2 — Identity

Use strong identity, MFA, privileged-access management and least privilege.

Layer 3 — Data Protection

Use encryption, customer-controlled keys, tokenization, DLP and data minimization.

Layer 4 — Cloud Security

Implement cloud posture management, configuration monitoring, segmentation and centralized logging.

Layer 5 — AI Governance

Maintain an inventory of approved AI applications, models, agents and data flows.

Layer 6 — Third-Party Risk

Evaluate cloud providers, SaaS companies, AI providers and subprocessors.

Layer 7 — Monitoring

Monitor data movement, anomalous access, API usage, AI interactions and privileged activity.

Layer 8 — Incident Response

Create procedures specifically addressing cloud and AI data exposure.

Layer 9 — Legal Controls

Use NDAs, contracts, data-processing agreements, audit rights and appropriate liability provisions.

Layer 10 — Continuous Validation

Regularly test whether the controls actually prevent unauthorized disclosure.

A Practical Checklist

Organizations can use the following checklist when evaluating whether a cloud or AI service should handle trade secrets.

Data

• Is the data classified?
• Is the minimum necessary data being provided?
• Is sensitive information encrypted?
• Are customer-controlled keys available?
• Are backups protected?
• Is data retention understood?
• Is deletion verified?

Cloud

• Is the shared-responsibility model documented?
• Are IAM permissions reviewed?
• Is MFA mandatory?
• Are privileged accounts monitored?
• Are cloud configurations continuously assessed?
• Is network segmentation implemented?
• Are cloud logs centrally monitored?

AI

• Is the AI provider approved?
• Is customer data used for training?
• Are prompts retained?
• Are outputs retained?
• Are uploaded documents retained?
• Are embeddings retained?
• Are humans able to access customer prompts?
• Are AI subprocessors identified?
• Can model changes affect the security posture?
• Are AI agents restricted by least privilege?

Third Parties

• Has the vendor completed a security assessment?
• Has the vendor provided independent assurance?
• Are subprocessors identified?
• Are data-processing locations known?
• Are security obligations contractual?
• Are incident notification requirements defined?
• Are audit rights available?
• Is the vendor continuously monitored according to risk?

Exit

• Can the organization export its data?
• Can it verify deletion?
• Are backups addressed?
• Are encryption keys revoked?
• Are AI prompts and embeddings deleted?
• Can the organization migrate to another provider?

The Most Important Question

Organizations often ask:

“Is our cloud provider secure?”

or:

“Is our AI provider secure?”

Those are the wrong questions.

The right question is:

“Is our entire data-processing chain sufficiently secure for the value of the information we are giving it?”

That distinction matters.

A company might have an extremely secure cloud provider but configure the environment incorrectly.

It might have a highly secure AI provider but allow employees to paste trade secrets into an unapproved consumer application.

It might have an excellent AI vendor but fail to understand that the vendor relies on several subprocessors.

It might have strong encryption but allow a privileged administrator to access the encryption keys.

Security is therefore not a property of the vendor alone.

It is a property of the system consisting of the company, its employees, applications, vendors, subprocessors, data flows and controls.

Conclusion: Trust, But Verify — Then Minimize

Cloud computing and AI are not inherently enemies of trade-secret protection.

In many cases, they can actually improve security.

Major cloud providers can offer security capabilities that would be prohibitively expensive for many organizations to build themselves. AI can help security teams identify threats, analyze code, monitor systems and discover anomalies. Cloud platforms can provide sophisticated encryption, logging, identity and resilience capabilities.

The danger arises when organizations confuse outsourcing infrastructure with outsourcing responsibility.

They cannot.

The organization still owns the business risk.

And trade-secret protection introduces an additional requirement: the company must be able to demonstrate that it took reasonable measures to keep valuable information secret.

The future therefore belongs neither exclusively to on-premises infrastructure nor entirely to public cloud and AI.

It belongs to controlled data flows.

Organizations should know what information they possess, classify it, minimize it, encrypt it, control who can access it, understand every third party that processes it, constrain AI systems through least privilege, continuously evaluate vendors and maintain the ability to remove their data from third-party systems.

Most importantly, companies should stop thinking of AI as merely another application.

AI is becoming a new class of data processor.

And when that processor is connected to corporate systems, cloud infrastructure and external services, it becomes part of the organization’s security perimeter.

The companies that protect their trade secrets successfully in the AI era will not be the companies that refuse to use the cloud or artificial intelligence.

They will be the companies that understand exactly where their secrets go, who can touch them, what those parties can do with them, and how to prove that appropriate controls were in place.

That is the new definition of the corporate security perimeter.

It is no longer a building.

It is a data-processing ecosystem.