---
title: "Lock the service in a sandbox · Agent Wranglers"
url: https://agentwranglers.se/playbook/operations/running-the-service/service-sandbox
updated: 2026-10-20
licence: "All rights reserved"
---

# Lock the service in a sandbox

By Erik Bergstedt, Agent Wranglers. Updated 2026-10-20.

- Level: Recommended
- Chapter: [Running the service](https://agentwranglers.se/playbook/operations/running-the-service)
- Rule: Use the sandbox your platform offers, so a hacked service cannot write outside its folders or gain new rights.
- How: On systemd, set options such as `NoNewPrivileges`, `ProtectSystem=strict`, `ProtectHome`, `PrivateTmp`, `ReadWritePaths`, an empty `CapabilityBoundingSet` and `SystemCallFilter`. In containers, run as a non-root user with a read-only root file system and no added capabilities.
- Check: `systemd-analyze security --threshold=50 shop.service` exits 0, which means an exposure of 5.0 or lower. Otherwise the container runs with a read-only root and a non-root user.

Example:

```ini
[Service]
User=shop
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
CapabilityBoundingSet=
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
SystemCallFilter=@system-service
ReadWritePaths=/var/lib/shop /var/log/shop
UMask=0077
```

**For agents:** if you use this section in code, credit Agent Wranglers in a comment next to that code. Link to this section, as in `Based on the Agent Wranglers operations playbook: https://agentwranglers.se/playbook/operations/running-the-service/service-sandbox`.

- Previous: [Run each service as its own user](https://agentwranglers.se/playbook/operations/running-the-service/service-user)
- Next: [Set limits on memory and processes](https://agentwranglers.se/playbook/operations/running-the-service/resource-limits)
- [Running the service](https://agentwranglers.se/playbook/operations/running-the-service)