# Secure your application

Understand the default identity, isolation, network, image, secret, and audit controls.

Canonical: https://docs.deliberate.space/security/

Use this page to understand the security controls your deployment receives by
default and the controls your Team still owns. These controls are not a
certification and do not replace security inside your application.

## Control access to the platform

Access to the platform is authenticated and scoped to a Team. Built-in roles
separate owners, contributors, operators, auditors, viewers, and billing users;
roles can be narrowed to a Project or Environment class. Private Net access is
granted to a person, so enrolling another device does not require you to repeat
every application grant.

Read [Manage Team access](/teams/access/) to invite a coworker and apply these
roles and scopes.

Applications remain responsible for their own end-user authentication and
authorization. A public route does not inherit console or Team access control.

## Isolate workloads

Each Environment has its own Kubernetes namespace. Tenant containers cannot
choose or weaken their runtime security context:

- stateless components run inside the gVisor userspace-kernel sandbox;
- components with durable volumes, or those requesting `microvm` isolation,
  run in a Kata Containers microVM;
- privilege escalation is disabled, the runtime-default seccomp profile is
  applied, and Linux capabilities are dropped except for a bounded set needed
  by the selected runtime; and
- service-account tokens are not mounted into ordinary tenant workloads.

Images pushed to the deliberate. registry are scanned for known
vulnerabilities. Findings and fixed versions are visible from the image view
and through `deliberate images vulns`. Scanning informs you about known issues;
it does not currently block a deployment.

## Limit network access

Inbound workload traffic is deny-by-default. The platform permits traffic from
the application gateway and creates specific paths for declared component,
database, bucket, and Blueprint dependencies. Public outbound traffic is
generally permitted, while private address ranges, cloud-metadata addresses,
and common abuse ports are blocked.

Outbound SMTP submission on ports 465 and 587 is available on Pro plans. Port
25 remains blocked on every plan. SSH, Telnet, RDP, and SMB egress ports are
also blocked by the Environment baseline.

Public platform-generated HTTPS routes use platform-issued TLS certificates
and pass through the origin WAF. Private routes require an enrolled device and
an explicit Team-member grant, and the device-to-platform tunnel is encrypted
with WireGuard. Traffic between Cilium-managed endpoints on different cluster
nodes is also transparently encrypted with WireGuard. Same-node traffic does
not enter that tunnel; it remains protected by the workload sandbox and network
policy boundaries described above. See [Web traffic
protection](/operate/web-traffic/) for the WAF's coverage and current
custom-domain limitation.

The WAF is only a safety net for common, recognizable attack patterns. Neither
WAF coverage nor a Private Net route makes an application secure: your Team
still owns application authentication, authorization, validation, patching,
rate limiting, abuse controls, and application-specific monitoring.

## Protect data and secrets

Tenant durable storage is placed on encrypted storage classes in the deployed
platform infrastructure. Protected PostgreSQL and FerretDB backups add
client-side archive encryption before the archive reaches encrypted object
storage. Secrets use OpenBao as their source of record and are materialized
only into the Environment and component that consumes them.

These mechanisms and the differences between database and volume backups are
covered in [Data protection](/data/protection/).

## Review Team activity

The Team Activity view records successful resource changes and selected
sensitive actions, including secret reveals, database-credential reads, shell
and proxy sessions, access changes, and Private Net changes. Denied permission
checks are recorded as well. Filter the history in the console or export it
through the CLI:

```sh
deliberate activity --project my-app --env production
deliberate activity --since 2026-07-01T00:00:00Z --json
```

Audit events retain the actor, action, time, resource, and selected structured
details; secret values and bearer tokens are not included. The current default
retention is 365 days. Reads and lists are generally not recorded, audit writes
are best-effort, and long-term archival is not currently provided. Treat the
Activity view as an operational history, not as an immutable compliance log.

## Your responsibilities

Your Team controls application code, dependencies, end-user access, secret
contents, route visibility, and who receives platform roles. You also decide
whether the documented retention and recovery behavior satisfies your legal
and business requirements. Contact deliberate. before relying on a platform
default as a formal compliance control.

## Next steps

- [Review encryption and recovery controls](/data/protection/)
- [Understand the WAF safety-net boundary](/operate/web-traffic/)
- [Manage Team roles and scopes](/teams/access/)