Endpoint agent trust guide
Check the agent’s trust path before it reaches client devices.
Review enrollment, identity, signed commands and updates, local permissions and revocation. Ask for evidence tied to the agent version and operating system you intend to use.
Practical evaluation guidance. Check current Dayrook scope and evidence.
On this page8 sections
Illustrative decision map · not a product screenshot
Verify every command from enrollment through evidence.
Tenant identity, transport, signed intent, local policy, and lifecycle controls form one chain; a failed gate stops the action.
- 01Identity
- 02Transport
- 03Envelope
- 04Gate
- 05Lifecycle
In brief
What to carry into the workflow
- Trust starts with short-lived, tenant- and region-scoped enrollment followed by a unique stored agent identity.
- Every command must be signed, short-lived, replay-resistant, policy-bound, and independently accepted by the local agent.
- Updates, rollback, revocation, remote access, backup, and automation must use the same fail-closed control chain.
Establish identity at enrollment
An endpoint agent is a privileged operator on the customer’s device, so installation begins with a tenant-scoped, region-scoped, short-lived enrollment secret. After enrollment, the agent receives an identity that is bound to the tenant, device, and selected region.
Local credential storage follows the operating system: DPAPI on Windows, Keychain on macOS, and libsecret, kernel keyring, or an encrypted fallback on Linux. Credentials are not reusable setup strings exposed indefinitely to operators.
- Confirm enrollment secrets expire and cannot enroll into a different tenant or region.
- Bind the resulting identity to the intended device and customer scope.
- Use supported OS-protected credential storage and deny plaintext persistence.
- Record installer signing and platform validation for the operating system in scope.
Protect the transport
Production agent transport uses mutual TLS and certificate pinning. Insecure TLS belongs only behind a debug-only compile path and must not be available in production binaries.
Identity and transport checks are distinct from user authorization. A connected agent still accepts only a command that matches its own identity and local policy.
Verify every command envelope
Before dispatch, the agent verifies a signed envelope containing tenant ID, agent ID, action, canonical parameter hash, short expiry, unique nonce, authorized issuer, compatible policy version, and signature. Any missing, tampered, expired, replayed, wrong-tenant, wrong-agent, or wrong-policy command fails closed.
Identity binding
Tenant and agent identifiers must match the enrolled local identity and current regional policy.
Payload binding
The parameter hash binds the approved request to the exact payload the agent receives.
Time and replay
A short expiry limits exposure and the nonce prevents a previously valid envelope from being reused.
Policy binding
Issuer, action, and policy version must remain allowed by both the server-side decision and local agent policy.
Gate high-risk actions end to end
Script and shell execution, patching, remote desktop, file transfer, service and process management, backup restore, network tunnels, and credential injection require more than agent connectivity. The server enforces role, entitlement, billing state, customer scope, and MFA or approval where configured before it signs a command.
Remote desktop adds WebRTC or TURN session exchange, consent and policy checks, and recording where policy requires it. Backup and Agent-S automation still travel through the signed-command and local-policy controls instead of a separate privileged channel.
Update, revoke, and prove the boundary
Agent updates need signed packages, staged rollout, rollback, and revocation. A revoked agent stops accepting commands and may perform only an approved decommission action. This gives operators a bounded response when identity, package, or policy trust changes.
- Reject unsigned, expired, replayed, wrong-tenant, wrong-agent, wrong-policy, and tampered commands in tests.
- Prove mutual TLS, certificate pinning, and production rejection of insecure TLS.
- Validate signed Windows installers, signed and notarized macOS packages, and the supported Linux installation path.
- Exercise allowed and denied command, backup, restore, remote, automation, update, rollback, revocation, and decommission paths.
Try this in your evaluation
Agent trust acceptance record
Illustrative scenario · use it to plan a test, not as proof of a result
Fictional test: revoke a test agent, attempt an old signed command offline, reconnect, and inspect whether execution is denied under the documented policy.
Define a successful result
Check these support boundaries
- OS and exact signed agent version
- Certificate/pin rotation and signed commands
- Revocation online and offline
- Agent-S prerequisites and Linux encrypted fallback
Acceptance record
Record build signature, trust root, rotation window, offline expiry, command denial and recovery path. Validate each OS separately.
Limits to resolve
No tested-version matrix is established by this planning example. Agent-S is a specialized execution agent; ask for its release prerequisites and actual trust evidence.
Questions, answered
Questions to resolve before your next step.
What proves an agent belongs to the right tenant?
Enrollment and the resulting device identity should bind the agent to one tenant and endpoint, with server and local checks rejecting scope mismatch.
Can a captured command be replayed later?
Signed commands should carry bounded identity and expiry, while replay state and endpoint policy reject a reused or stale request.
What evidence should a security review request?
Request current enrollment, certificate, signing, command-denial, update, rollback, revocation, uninstall, audit, and platform-artifact evidence.