Securing Proprietary Data in the Age of Public LLMs.

The AI gold rush has created a dangerous paradox. Companies are racing to adopt large language models to stay competitive, but in the rush, many are feeding their most sensitive business data into systems they don't control, don't audit, and don't fully understand. The result is a ticking time bomb of data leakage that most organizations won't discover until it's too late.

The Wrapper Problem

A new category of startup has emerged in the past two years: the “AI wrapper.” These companies take a foundation model like GPT-4 or Claude, add a thin UI layer on top, and sell it as an enterprise solution. On the surface, the pitch is compelling. Under the hood, the architecture is terrifying.

When you use most wrapper products, your data—internal documents, customer records, financial reports, strategic plans—is sent to a third-party API. In many cases, that data is used to improve the model. Even when providers offer “enterprise” tiers that claim to exclude your data from training, the data still traverses infrastructure you have zero visibility into. You can't audit it. You can't verify the claim. You're trusting a Terms of Service document that can change with 30 days' notice.

For companies handling regulated data—financial records under SOX, healthcare data under HIPAA, customer data under GDPR—this is an unacceptable risk posture. But even for companies outside regulated industries, the exposure is real. Competitive intelligence, pricing strategies, M&A plans, and customer lists are all assets that can be weaponized if they leak.

The Architecture We Use Instead

At SoftCode, we approach AI deployment with a security-first architecture. Every design decision starts with the question: “Where does the data live, and who can access it?”

1. Row Level Security (RLS)

Our database layer enforces Row Level Security policies natively in PostgreSQL. This means access control isn't bolted on at the application layer where it can be bypassed—it's enforced at the database engine level. Every single query, whether it comes from a user session, an API call, or an internal service, is automatically scoped to the authenticated user's permissions.

In practical terms, this means Client A's data is physically invisible to Client B's queries. Not hidden behind a permission check in application code. Invisible at the SQL execution level. Even if a bug in the application layer accidentally constructs a query without a WHERE clause, the database itself filters the results.

2. Isolated Processing Environments

When we deploy AI agents for a client, those agents run in isolated environments. The model has access to the client's data and only the client's data. There's no shared context window across tenants. There's no cross-contamination of embeddings. Each deployment is a clean, scoped instance.

We achieve this through a combination of infrastructure isolation (separate compute containers per client where sensitivity warrants it) and application-level scoping (RLS policies that restrict retrieval-augmented generation to authorized documents only).

3. Zero Training Guarantee

This isn't a toggle in a settings panel. It's a contractual, architectural, and procedural commitment. Client data processed by our systems is never used to train, fine-tune, or improve any model—ours or anyone else's. When we use third-party foundation models, we use enterprise API tiers that contractually exclude data from training, and we verify this through our own audit processes.

4. Encryption at Every Layer

Data is encrypted in transit using TLS 1.3 and at rest using AES-256. API keys and credentials are stored in encrypted vaults with automatic rotation. Database backups are encrypted. File storage is encrypted. There is no point in the data lifecycle where information exists in plaintext on disk without encryption.

The Compliance Layer

Our infrastructure runs on SOC 2 Type II compliant providers (AWS and Vercel). This provides baseline guarantees around physical security, access logging, incident management, and change control that are verified by independent auditors. We build on this foundation with our own application-level controls:

• Audit logging on all data access and modification events, with tamper-resistant log storage.
• Role-based access control with the principle of least privilege. No engineer has standing access to production client data.
• Automated vulnerability scanning on every deployment, with dependency auditing and automated alerting on CVEs.
• Data retention policies with automatic purging. When a client terminates service, their data is deleted within 90 days—not archived indefinitely.

The Question You Should Be Asking

Before you adopt any AI tool for your business, ask this: “If I paste my company's most sensitive document into this system, can I prove—architecturally, not just contractually—that no unauthorized party will ever see it?”

If the answer is anything other than a clear, technical explanation of data isolation, encryption, and access controls, walk away. The convenience of a chatbot is never worth the risk of a data breach.

AI should make your business faster. It should never make it vulnerable.