// security
Security by construction: how Praxys protects what you build
Security / Engineering · 4 minute read
Security controls are weakest when they rely on memory: a developer must remember an authorization check, a service owner an outbound restriction, or an operator an audit path. Under pressure, conventions are missed.
Praxys is designed to move the most important controls below application code and into the platform's execution model. The objective is not a single security feature. It is a series of independent boundaries that limit access, constrain failures, and leave evidence when privileged actions occur.
Isolating workloads and data
The intended hosted model treats applications as untrusted workloads and places them in a dedicated MicroVM-capable isolation path. That model is designed to give customer code a stronger boundary than shared in-process execution and to separate public application traffic from platform control-plane traffic.
The next boundary is data access. In supported tenancy configurations, requests resolve into
a tenant context before reaching tenant-scoped resources. Application handlers receive TenantCapability objects—limited surfaces for databases, caches, queues, storage, and other resources—not unrestricted
backend clients. They expose only allowed methods and sanitise sensitive details from errors crossing
the boundary.
Some data paths can also use database-enforced row-level security. The important principle is that data isolation is not left solely to an application remembering to add a filter to every query. Where a workload needs exceptional cross-tenant access, it must use an explicitly tagged privileged path; that action is recorded, and an audit failure causes the access attempt to fail rather than proceed silently.
Denying by default
Praxys applies a simple rule to sensitive operations: uncertainty should not become access.
The web runtime is authentication-by-default for tenant-scoped routes. If those routes are registered without a principal-resolution mechanism, the runtime refuses to boot. An intentionally anonymous application must declare that choice explicitly; it is never the accidental result of an omitted configuration value.
The same posture informs lower layers. Rate-limit, quota, and budget stores are designed to treat a backend failure as an error, not permission to continue unchecked. Managed egress policy is intended to constrain outbound access in supported environments and reduce the chance of an unreviewed path reaching internal endpoints.
This does not mean every operational choice must fail closed. Availability decisions remain explicit and service-specific. It means that a missing identity, a failed security control, or an unapproved capability does not quietly become a grant.
Limiting the blast radius
Security architecture must assume credentials will be exposed, dependencies will fail, and application defects will occur. Praxys limits the impact through several constraints working together.
Tenant-scoped capabilities provide least-privilege resource access. Secrets are managed separately from ordinary application configuration. Egress policies constrain where a workload can connect, including DNS and IP checks designed to resist common SSRF and rebinding paths. At the edge, rate limits, quotas, budgets, and admission controls protect downstream systems from abusive or accidental demand.
These controls are complementary. Workload isolation limits the reach of untrusted code. Capability boundaries limit what that code can call. Egress controls limit where it can send data. Resource policies limit how much damage an unexpected workload can cause.
Making privileged activity accountable
Prevention matters, but effective security must also support investigation. Praxys’ security architecture includes a dedicated audit path for security- and compliance-relevant events. The intended records are schema-validated, sequence-numbered, and linked in a hash chain.
That makes missing or modified records detectable and keeps audit separate from general telemetry, which may be sampled or best-effort. Logging diagnostics and retaining accountable security evidence have different requirements.
Tamper-evident is not the same as tamper-proof. A hash chain identifies alteration after the fact; stronger protections, such as independently managed signing and immutable storage, are deployment concerns that can be layered on top. Being precise about that boundary is part of building a trustworthy system.
Defense in depth, at a glance
No one control carries the entire burden. The layers are intentionally independent: a denied request is stopped before resource access; a constrained capability limits what a valid workload can do; isolation and egress rules contain a compromise; and audit records make exceptional activity visible.
A security foundation, not a substitute for application security
These are platform controls used by both Praxys and the applications we host. They provide a secure baseline without asking every team to rebuild the same mechanisms.
They do not remove the need for application security. Teams still own their business authorization rules, data classification, secure application logic, and configuration of the integrations they choose. Praxys' role is to make the safer path the structural default—and to provide clear, enforceable boundaries when an application needs more privilege.
Request access.
Praxys is in builder preview. Join the list to build software you own.