The API names a folder. It never names a path.

The configuration file is the permission model

A file named dropzippa.config.json sits beside the agent on the machine. It lists the folders that agent will expose, each under an alias:

• alias — the name jobs use, such as orders. Never a path.
• path — the real local folder it maps to.
• writable — whether jobs may create or modify files here.
• deletable — whether jobs may delete here, deliberately separate from writing, so a folder can be fillable without being emptiable.
• allowed_extensions — the file types permitted. An empty list means no restriction, never “deny everything”.

Only someone with access to that machine can edit this file. The API cannot add a root, widen one, or reach a path outside one. A job may only name an alias that already exists. That asymmetry is the whole security model, and everything else is a consequence of it.

Enforcement happens on the machine

The server validates the shape of a job, but only the agent knows what a root maps to and whether a given path really stays inside it. So containment is decided locally, after the path has been fully canonicalised — which means the agent stays safe even if it is talking to a server that has been changed or impersonated.

The agent refuses the following regardless of what the server sends:

• Paths are always relative to a root. Absolute paths, .. segments, backslashes, UNC shares and drive letters are all rejected before anything touches the filesystem.
• Links are followed before the decision. A symlink or junction inside a root that points somewhere else is an escape. The agent walks every segment of a path and follows links as it goes, rather than checking only the final component.
• Reserved device names are rejected. Windows treats names like CON and com1.txt specially. They are refused rather than written.
• Archives cannot escape their destination. Every entry in a .zip is validated against the destination before it is written, so an entry named ../../ goes nowhere. Entry count, total uncompressed size and compression ratio are all capped.
• Downloads are verified when you ask. Supply an expected SHA-256 and a mismatch fails the job. The bytes are never published.
• Nothing is ever executed. There is no run, shell or open operation in the API or the agent. This is not a setting that can be turned on.

Jobs are all or nothing

Every write lands in a hidden staging folder inside the destination root and moves into place only once every operation in the job has succeeded. Because staging sits on the same volume as the destination, publishing is an atomic rename — a process watching that folder never sees a half-written file, and a failed job leaves your folders exactly as they were rather than a half-built folder that looks finished.

Credentials

Each installed agent has its own credential, stored hashed, and revocable on its own without disturbing any other machine. Your application authenticates separately with an API key carrying explicit scopes, so a read-only integration cannot submit work.

Connectivity

The agent connects outbound. There is no inbound port to open, no public IP required, and no firewall change — the machine holding your files is never addressable from the internet.

Changing what an agent may touch

Edit the configuration file and choose Reload configuration in the agent’s tray menu. The new set is published immediately, and any folder that is missing or unreachable is reported as unavailable in the dashboard rather than failing jobs later.

Reporting a vulnerability

Email security@dropzippa.com. Please include enough detail to reproduce the issue.