Appearance
Shell privileges
The standard installation opens remote shell as the unprivileged dataplicity service account. Terminal commands have the same Linux permissions as that account. Dataplicity platform roles control who can open the terminal, but they do not make its Linux process a superuser.
Keep the default boundary
Keep the account unprivileged on production devices. Check the effective identity and groups from the remote terminal:
shell
idFile access, services, and commands should fail when the account does not have the required Linux permission. This is expected security behavior.
The classic installer configures one narrow passwordless sudo exception for the device-reboot action. This is not general sudo access. Installation methods and custom images can differ, so review the actual service and sudoers configuration on the device.
Grant extra access only when required
An administrator can grant access through a specific group, filesystem ACL, service permission, narrowly scoped sudoers rule, or protected credential. Prefer the smallest grant that supports the operational task.
Avoid adding blanket passwordless sudo or running the agent as root. Either choice expands what remote terminal, automation, fleet commands, and confirmed AI-assisted commands can do. Review and audit group, ACL, helper-script, credential, and service changes.
If a task genuinely requires an interactive privileged account, use your organisation's approved access method and authentication policy. Do not place privileged passwords or reusable secrets in terminal history, fleet commands, or scripts readable by the dataplicity account.