Security
Learn why Device AgentZebraByte is a single-impuls posture reporter rather than an MDM, with fixed local checks, APIs initiated by agent and signed updates.
ZebraByte Device Agent is a posture reporter, not a device management tool. It registers a device, runs a fixed set of local security controls and pushes the results to the platform organization. not an MDM: the platform server cannot send commands to the device, install software, change settings, or run arbitrary checks.
Design philosophy
Posts Tagged ‘Design Philosophy’The agent follows a simple rule: the device speaks to the platform; the platform never speaks to the work to be done.
| This agent does | This agent does not |
|---|---|
| Collect local posture signals | Get shell commands, scripts or policies from the platform |
| Push heartbeats and check results | Open a control channel for the server to call the device. |
| Registering and unsubscribing with local consent | Block, delete or reconfigure the machine as an MDM |
| Self-update from signed GitHub Releases | Download and run binaries not signed or provided by the server |
This limit exists so that employees and operators can treat the agent as observability for compliance – not as remote administration of their laptop or server.
Push-only communication
“Push-only communication”All agencies are agent-initiated HTTPS to /api/agent/v1. The published surface is:
| Endpoint | Direction | Purpose |
|---|---|---|
POST /enroll |
Agent → server | Changing a single registration token for an API device |
POST /heartbeat |
Agent → server | Report host identity and receive schedule intervals |
POST /postures |
Agent → server | Push posture check results |
POST /unenroll |
Agent → server | Ask the server to remove the device |
There is no WebSocket, long surveys command line or reverse shell style channel. the platform server does not open connections to registered devices.
When the agent beats the heart, the response contains only the programming metadata: device ID, heart rate range, posture range, and server time. not includes commands, checks definitions, scripts or file loads.
Fixed check set
Section entitled “Fixed check set”Posture checks are Compilation in binary agentEach platform records the same named checks at the time of construction (for example, disk encryption, screen lock, firewall, time synchronization, OS version, automatic update, password policy, remote connection and malware protection).
The server cannot:
- Add a new check at runtime
- Modification of the way an existing control is evaluated
- Ask the agent to run an arbitrary executable or script
Local help commands used by controls to solve pinned absolute paths They are not taken from the network or only from the PATH.
You can run the same checkup set offline with probo-agent collect – which prints the results locally and doesn’t push anything onto the platform.
Authentication and local secrets
Section entitled “Authentication and local secrets”- Enrollment uses a one-shot token on the platform console. The agent changes it once for a long life device API key, then stores that local key (file mode
0600in the agent state directory). - Subsequently, the heartbeats and posture push authentication with that deviceAPIto HTTPS.
- If an administrator revokes the device on the platform, the agent's subsequent calls receive unauthorized responses and the agent ceases to treat the record as valid.
- Uninstall/unenroll clarifies the state of the local agent on the device.
Do not place log tokens in URLs, chats or logs. Prefer the desktop log stream (installer + browser) on macOS and Windows whenever possible.
Updates and integrity
Section entitled “Updates and integrity”When automatic update is enabled, the agent checks GitHubReleases under the tag probo-agent/v*, checks the launch artefacts with Cosign / Sigstore, and only then replaces its binary. Verification replaces the signature identity in the platform's launch workflow on a labeled committee.
You can disable automatic updates at the time of installation (--no-auto-update / PROBO_NO_AUTO_UPDATE). Commands.
Implementation
Section entitled ‘Implementation’The officer is written in GoThis option reduces the entire class of memory corruption bugs common to C/C++ agents without introducing a runtime scripted or interpreted on the device.
We also keep dependencies to a minimumThe agent prefers the standard Go library and a small set of well-made packages (e.g. checking Cosign/Sigstore andAPIOS) rather than a large tree from third parties.
Agentul este open sourceSource, launch workflows and signed live artefacts in ZebraByte/the platform the repository (cmd/probo-agent, pkg/deviceagent), so that security teams can audit the verification set, the API client, and the update verifier on their own – do not take these claims on trust.
A few notes on scope:
- Gathering posture, heartbeats, sharing signatures, and self-updating logic live in binary Go – the same code path on macOS, Windows, Linux, and FreeBSD.
- Platform assistants remain narrow. on macOS, a small signature Swift The privileged help only exists to complete your browser registration over XPC; it is not a general remote control area or scripting.
- Auto-updates never run unsigned bits: only the launch artefacts verified by Cosign/Sigstore replace the binary (see section 4.2). Updates and integrity).
The choice of language and a set of weak dependencies support the push-only model; they do not replace it.
Compared to MDM
Section titled “Compared to MDM”Mobile device management products are built for control Endpoints: pushing configuration profiles, running settings, installing apps, locking or deleting devices, and often performing remote actions. observe Final points for proof of conformity.
Use your existing MDM (or configuration management) if you need remote control. Use ZebraByteDevice Agent when you need continuous proof of posture in the platform without giving the compliance platform a machine command channel.