Sovereign by design.

Every Palisade deployment is single-tenant. Your system runs in its own environment, with its own data stores, its own keys, and its own boundary. Nothing is pooled.

Your data is your property: it is never used to train models, never aggregated across customers, and never leaves your deployment for any purpose you did not direct. What the system learns from your operation belongs to you in the same way the data does: the structures, the patterns, the accumulated knowledge of how your work runs.

The threat model is worth stating plainly. Pooling widens the blast radius: on a pooled platform, an incident in one tenant is a question for every tenant. Here there is no shared substrate, so an incident in one deployment has no path into another. Pooling is also an incentive problem: a platform that holds many customers' data in one place has a standing reason to learn from it, and only policy stands in the way. Single tenancy removes the capability outright. What it does not solve: your own credential hygiene and your own people. Those risks stay with you, and the control model below exists to make them governable.

Every actor in a Palisade system is a named principal, and that includes software: agents authenticate as named identities with role-scoped permission, the same way staff do. Permission derives from how your organization actually runs: who may see a field, who may sign a release, who may act in whose name. Defined once, enforced everywhere, for people and for software alike. Actions that warrant a second set of eyes require two people; no single principal can carry them alone.

Every action lands in the audit trail with its principal, its object, its time, and its authority. The trail is append-only and hash-chained: each entry commits to the one before it, so any rewrite would be arithmetically visible. The record can be read and extended, never edited.

Change is reversible by design. Material changes run on branches, rehearsed and validated away from production, then promoted or discarded. Reversibility sets the limit of delegation: an agent is trusted with exactly as much as can be undone.

Palisade is model-agnostic by design. No model is load-bearing: the system's knowledge lives in a layer you own, in the objects, properties, links, and actions that describe your operation, and models are interchangeable instruments that operate on it. Swap providers, run open weights, or change course entirely without losing the system or what it has learned. Swapping a model is a configuration change. Context is assembled from the ontology at call time, and Palisade persists nothing on the provider's side. What a provider itself may retain is governed by the rung you deploy on, stated plainly in section 04.

The same holds for compute: Palisade runs on shared cloud, on dedicated infrastructure, or in isolated environments under your physical control. Portability is deliberate. A customer who can leave is a customer whose terms hold.

A model invocation runs as the identity that invoked it. The context assembled for the call is filtered through the same permission plane as the caller, field by field, so the model is never handed more than the person or agent it works for could read. Tool calls are governed the same way: every read and every action the model requests is checked against the caller's authority, not the model's.

Palisade persists nothing with a provider. Context is assembled per call, and Palisade's copy is discarded when the call returns. What a provider can retain depends on the rung, stated in the table below.

Palisade does not train models, on customer data or anything else. There is no training pipeline for your data to enter. Provider training on your data is excluded by the same terms that limit retention. Because no model is load-bearing, the roster is a configuration decision you direct: commercial APIs, endpoints in your own cloud, or open weights inside the boundary.

Three rungs, one system. The software is identical on every rung. What changes is who holds the boundary, the keys, and the network. Each rung converts more of the guarantee from contractual to structural. At Isolated, all of it is.

If you believe you have found a vulnerability in a Palisade system, write to security@palisadelabs.com. Include what you found, where, and how to reproduce it. We read every report, we acknowledge reports within three business days, and we take no action against researchers who investigate in good faith and give us reasonable time to fix what they find.

Customers on dedicated or isolated deployments may run scanners against their own deployment with advance notice. Do not degrade service, do not target anything that is not yours, and do not social-engineer our people or anyone else's. There is no paid bounty program: we fix what is real, and we credit researchers who want credit.

Machine-readable contact: /.well-known/security.txt

What the architecture already enforces, and what is being attested.