Approvals at the boundary
There is a moment before every consequential action where someone decides: allow or deny. Pardx makes that moment structured, visible, and persistent — instead of invisible and inconsistent.
SECURITY
The isolation model, in concrete terms.
This page explains what each part of Pardx can reach, what it cannot reach, and where Approval is required.
A policy engine on the machine
Station checks policy locally before anything runs. What each tool may touch is decided by you; the agent works inside those lines, or it waits. Shell-level bypasses — pipe-to-shell, nested substitution — are blocked by design.
Zero-permission cloud workers
In Pardx Cloud, the container that executes agent code holds no cloud identity. A stolen token from inside a job grants nothing: no secret store, no storage, no other user.
Sealed credentials
Per-user envelope encryption (AES-256-GCM data keys wrapped by KMS), opened only at launch by the control plane, scrubbed at teardown. Credentials never sit in logs, images, or shared state.
Network discipline
Cloud workers run behind a default-deny egress firewall on a dedicated network path, as non-root, with the metadata host denied.
The record
Every run leaves an audit trail — action, time, reason, approval. Trust here is not a promise; it is a property you can check.
Questions we get
What can an agent do without my approval?
Read and reason within the scope you gave it. Writes, pushes, and other boundary-crossing actions pause for explicit approval — allow once, allow for the run, or deny. You can also stop the run entirely, from any device.
Where does my code live when agents work on it?
On your own machines when you pair them with Station, or inside your private Pardx Cloud VM — a per-user machine whose state is encrypted and never shared with another user.
How is Pardx Cloud isolated between users?
Every job runs in a fresh container holding exactly one user’s state and credentials, and the container is destroyed when the job ends. The worker itself carries zero cloud permissions; all privileged operations stay in the control plane.
How are my credentials stored?
Envelope-encrypted: the credential blob is encrypted with a per-user data key (AES-256-GCM), and that key is wrapped by a managed KMS key. It is unwrapped only at job launch and scrubbed before the machine sleeps.
Can I see what an agent did?
Yes — that is the point. Every action is kept with its time and its reason: what ran, what changed, which machine did it, and what you approved. The record is yours to review and export.
What happens when I hit stop?
The run ends on the real machine — the process group is terminated. Not a pause. A stop.
We publish what is built, not what is planned. As controls land — deeper encryption options, team policy, attestation — they will be described here in the same terms.
Run agents without giving up control.
Request early access