From the CEO

Every few months a new frontier model arrives and the benchmark leaderboard reshuffles. It's genuinely thrilling — and, if you run a business, genuinely beside the point. The model your team uses next quarter will be better than the one it uses today, and the one after that will be better still. Capability is compounding, and it is not where anyone's moat is going to live.

I've spent a lot of the last year in rooms with CISOs, general counsels, and heads of AI. Not one of them is losing sleep over whether the model is smart enough. They're losing sleep over a different question entirely: can I let my people point this thing at our most sensitive data without betting the company on it? That question — not raw capability — is what actually gates adoption. And answering it is an infrastructure problem.

Capability is racing ahead of control

The uncomfortable truth of enterprise AI in 2026 is that the technology has sprinted past the guardrails. Employees are already pasting contracts, patient records, source code, and board decks into whatever assistant is fastest. They're not being reckless; they're being productive. The tools are extraordinary and the pressure to use them is real. But every one of those interactions is a decision about where sensitive data goes — made hundreds of times a day, by people who were never asked to be data-governance officers.

You can respond to that in one of two ways. You can block — lock down the tools, publish a policy, and watch shadow AI route around you within a week. Or you can govern — make the safe path the fast path, so that protection travels with the data instead of standing in front of it. We are firmly in the second camp, and we think the difference is the whole ballgame.

The winners of the AI era won't be the companies with the best model. They'll be the companies that trusted their people to use one — because the trust was built into the infrastructure, not bolted onto the policy.

— Jason Melo, Co-Founder & CEO

Why we build on-device

If trust is the product, then the architecture has to earn it. That's why PrivacyPal runs where the work happens — on the device, in real time, before a single token reaches a model. When someone drafts a prompt containing a client name, an account number, or a line of proprietary code, we intercept it locally and substitute a coherent Privacy Twin: synthetic data that preserves the meaning and structure of the original so the model still does its job, while the real value never crosses the boundary.

On-device isn't an implementation detail — it's the trust boundary. A cloud proxy asks you to send your secrets somewhere else first and trust that they're handled well. On-device inverts that: the sensitive value is protected before it ever leaves the endpoint, under a zero-knowledge architecture where we never see it either. You don't have to trust our servers, because your data never reaches them.

• Protection lives at the source — the endpoint — not one hop away in someone else's cloud.
• One policy governs every AI surface: chat assistants, browser tabs, IDEs, and agents.
• Synthetic substitution keeps prompts useful, so security stops being the thing people route around.
• Full audit of every interaction, so trust is provable — not just asserted.

Trust compounds too

Here's the part I find genuinely exciting. Capability compounds — but so does trust. Every interaction that's governed well makes the next one easier to approve. A team that can safely use AI on its most sensitive workflows doesn't just get a productivity bump; it gets permission to keep going. That permission is the real flywheel of the AI era, and it is built out of infrastructure, one protected prompt at a time.

Models will keep getting better, and we'll be glad of it — PrivacyPal is deliberately model-agnostic, so every leap forward is a leap our customers get to take safely. But the thing we're building isn't a smarter model. It's the layer that lets you point any model at anything you've got, and sleep at night. That's the moat. That's the infrastructure. And that's the whole reason we get up in the morning.

— Jason

Engineering privacy

Redaction is the reflex answer to data privacy. See something sensitive, black it out. It feels responsible, it looks like diligence, and for decades it was the best tool we had. But when your goal is to actually use data with an AI system, redaction is a tax — one you pay in accuracy, in context, and in the quiet frustration of a model that no longer understands what you asked.

What redaction actually does to a prompt

Consider a support agent asking an assistant to summarize a customer's account issue. Redact the name, the account number, the balance, and the transaction, and you're left with: "[REDACTED] is disputing a [REDACTED] charge of [REDACTED] on [REDACTED]." The sensitive data is gone — and so is the meaning. The model can't reason about relationships it can no longer see. It doesn't know whether two [REDACTED]s are the same entity or different ones. The answer degrades, the agent copies less into the tool next time, and privacy quietly becomes the enemy of the work.

That's the hidden cost. Redaction doesn't just remove risk; it removes signal. And because it visibly makes the tool worse, it trains your best people to work around it — which is the opposite of what any privacy program is trying to achieve.

The goal was never to hide data from the model. It was to give the model something just as useful that happens to be safe.

— PrivacyPal Product Team

Substitution: keep the shape, swap the secret

Privacy Twins take a different path. Instead of deleting a sensitive value, we replace it with a coherent synthetic equivalent — a twin that preserves type, format, and relationships while carrying none of the real information. "Maria Gonzalez" becomes another plausible name, and stays that same name every time it appears in the conversation. A real account number becomes a well-formed synthetic one. A $4,212.55 charge becomes a realistic figure of similar magnitude. The model sees a complete, internally consistent world — it just isn't your customer's world.

Because the substitution is structure-preserving, the model's answer comes back in terms of the twin, and we can reverse the mapping under policy so the human sees the real values again. The secret never left the device. The model never saw it. And the analysis is every bit as good as it would have been on the raw data — because, as far as the model could tell, it was working on real data the whole time.

Why this is a strategy, not a feature

• Utility is preserved: prompts stay coherent, so people keep using the safe path instead of routing around it.
• Consistency across a conversation: the same entity maps to the same twin, so multi-turn reasoning holds together.
• Reversible under policy: authorized workflows can re-link results downstream; everyone else never sees the original.
• Auditable by construction: every detection and every substitution is logged — what was found, what it became, and why.
• Regulation-ready: because the raw value never crosses the boundary, GDPR, HIPAA, GLBA, and the EU AI Act get dramatically easier to reason about.

The compliance dividend

When you redact, you're managing the fallout of sensitive data that's already in motion. When you substitute on-device, the sensitive data was never in motion to begin with — so the compliance question changes from "how do we govern this transfer?" to "there was no transfer." That's a categorically easier position to defend to a regulator, an auditor, or a customer's security team. It's the difference between cleaning up after risk and never creating it.

Redaction asks your organization to choose between privacy and productivity, and then quietly taxes you no matter which you pick. Substitution refuses the trade. That's why we don't think of Privacy Twins as a nicer redaction — we think of it as the end of redaction, and the beginning of privacy that finally pays for itself.

— Shayra

Perspectives — from our advisory board

For most of the short history of enterprise AI, governance had a comfortable shape: a human wrote a prompt, a model wrote a reply, and somewhere in the middle you could inspect, approve, or block. The human was the throttle. Agentic AI removes the throttle. An agent reads a ticket, decides on a plan, queries a database, calls three tools, writes to a system of record, and moves on to the next task — dozens of times a minute, often across systems no single reviewer can see at once. The old governance model assumed a human in the loop. Agents are the loop.

Why the old playbook fails

Output review — the practice of checking what a model said before acting on it — was always a bit of a fiction, but with agents it collapses entirely. There is no single output to review; there is a cascade of decisions and actions, each conditioned on the last, executed faster than any human can follow. By the time you'd finish reviewing step one, the agent is on step forty. Governance that depends on catching the bad answer before it does damage simply cannot keep up.

The mistake is to treat an agent like a faster chatbot. It isn't. It's an autonomous actor with credentials, tool access, and initiative. Governing it means governing behavior — what it's allowed to see, what it's allowed to do, and what must be true before it does it — not grading its homework after the fact.

You cannot review your way to safety with an agent. You have to govern the boundary it acts across — before it acts, not after.

— Jordan Serlin, Advisor & Partner

A field guide: five controls that actually hold

Over the last year, working with teams deploying real agents into production, a practical pattern has emerged. Five controls, applied at the boundary where the agent meets the outside world, do most of the work:

• Least-privilege data access: an agent should see the minimum it needs. Sensitive values it doesn't strictly require should be substituted with twins before they ever enter its context.
• Action gating: high-consequence actions — writes, sends, payments, deletions — pass through policy checks that can require approval, apply limits, or refuse, regardless of what the agent 'decided.'
• Boundary-level DSPM: watch the data crossing into and out of the agent in real time, not the model's internal reasoning you can't observe anyway.
• Immutable audit: every decision, tool call, and data access is logged in a tamper-evident trail, so you can reconstruct exactly what happened and prove it.
• Model-agnostic policy: the rules live above the model, so swapping or upgrading the underlying agent doesn't reset your governance to zero.

Govern the boundary, not the brain

Notice what these controls have in common: none of them require you to understand the agent's reasoning. That's deliberate. The interpretability of large models is an open research problem, and betting your compliance posture on solving it is a losing wager. But you don't need to read the agent's mind to govern it. You need to govern the boundary — the data going in and the actions coming out. Those are observable, enforceable, and auditable today. The reasoning in between can stay a black box, because you've made the box's inputs and outputs safe.

This is where on-device enforcement earns its keep. If the boundary control runs at the endpoint, before data reaches the model and before actions leave it, then it holds no matter which agent, which model, or which vendor is on the other side. You've governed the one thing you actually control — the perimeter — and made it independent of the thing you don't.

The regulators are already here

None of this is hypothetical. The EU AI Act's obligations are phasing in, sector regulators in finance and healthcare are issuing agent-specific guidance, and 'we couldn't see what it did' is not going to survive an audit. The organizations that will move fastest with agents are, counterintuitively, the ones that governed them first — because they can say yes to the next use case without flinching. Governance isn't the brake on agentic AI. Done right, it's the thing that lets you take your foot off it.

— Jordan