User Manual

This manual is for operators who use Sentinel Secure X after the platform is already installed.

It focuses on the day-to-day console experience:

• signing in and managing sessions
• understanding the dashboard
• reviewing device trust changes
• using commands, updates, recovery, and integrations
• finding agent bundles when your deployment publishes them

For installation, see installation_guide.md.

1. Access and operator roles

Operators typically sign in at:

• /dashboard for the live console
• / for the landing page and deployment overview

Built-in role names in Sentinel Secure X are:

• viewer
• operator
• approver
• security
• admin

Your account may have one role, several roles, or explicit permissions.

2. Signing in

The dashboard supports:

• username and password login
• TOTP one-time code login when required
• passkey sign-in for phishing-resistant authentication

After sign-in, use the session controls to:

• view active sessions
• revoke a stale session
• sign out immediately

If your deployment enforces passkeys for an account, password-only sign-in stops working after a passkey is enrolled.

3. Understanding the dashboard

The dashboard is organized for quick operator reads.

Top-level areas:

• Summary cards: fleet count, compliance, pending reviews, and service health
• Device state: trust posture for each managed endpoint
• Service health: API, worker, maintenance, scheduler, and rollout services
• Audit trail: recent governance and security events

What operators should scan first:

1. Pending reviews
2. Unhealthy services
3. Devices with trust, certificate, or attestation issues
4. Recent audit events tied to approvals, revocations, or rollout pauses

4. Device lifecycle and trust posture

Each device card helps answer four questions:

1. Is this the device we expect?
2. Is it still trusted?
3. Is its certificate still valid and approved?
4. Is it waiting on operator action?

Important device fields:

• Transport: whether the device is reaching Sentinel over a secure path
• Trust Tier: the current trust classification
• Approval State: whether enrollment or rotation is pending review
• Bound Identity: the certificate currently pinned to the device
• Cert Status and Cert Expires: certificate hygiene and urgency
• Attestation: whether the configured attestation policy passed
• Update State: whether a staged update is waiting, applying, complete, or failed

5. Enrollment, identity review, and certificate rotation

New devices typically appear through the agent heartbeat path.

When SENTINEL_REQUIRE_NEW_DEVICE_APPROVAL=true, new enrollment stays pending until a reviewer approves or rejects it.

Use the identity review path when you need to:

• approve a new device
• reject an unexpected enrollment
• approve a planned certificate rotation
• reject an untrusted or unexplained certificate change

Security operators should pay attention to:

• certificate common name and device_id alignment
• unexpected issuer changes
• certificate revocation posture
• rotation timing relative to expiry windows

6. Commands and protected reviews

Operators can queue device commands from the console or API.

Common patterns:

• queue a routine action directly
• require review for sensitive actions
• hold the action until distinct approvers satisfy policy

Use protected review flows when you want:

• high-risk diagnostics gated by human review
• distinct approvers for sensitive devices
• a durable audit record of who approved or rejected an action

If a command stays pending, check:

• whether approval thresholds were reached
• whether the device is online
• whether the agent has outstanding results waiting to report

7. Update campaigns

Update workflows are designed for staged, governed rollout rather than ad hoc replacement.

Typical operator flow:

1. stage a signed manifest
2. create an update campaign
3. review and approve it
4. watch rollout rings, canary gates, and pause states
5. resume or halt when rollout signals demand it

Use the update area to:

• inspect campaign status
• see whether a rollout is paused or blocked
• monitor assignment state across devices
• decide whether a rollback or pause is the safer path

8. Recovery and resilience

Recovery is part of the trust model, not an afterthought.

Operators can use recovery features to:

• record signed backup manifests
• submit or review recovery jobs
• track restore drills
• inspect observed recovery environments

What good recovery posture looks like:

• recent valid backups
• recent tested restore drills
• explicit review for sensitive recovery actions
• signed validation artifacts where configured

9. Service health and scheduled jobs

Sentinel tracks background services because trust decisions depend on them.

Service health panels help confirm:

• the API is live
• the delivery worker is processing queued integrations
• the maintenance worker is expiring time-bounded state
• the scheduled-job coordinator is active
• the update-campaign scheduler is progressing approved rollouts

Scheduled job controls let authorized operators:

• inspect recent execution history
• suppress a job temporarily
• resume a suppressed job
• trigger a manual run when policy allows it

If readiness fails, check the service health panel before assuming the dashboard is wrong.

10. Integrations and trust distribution

Sentinel can push trust and security events to downstream systems.

Operators may use the console or API to manage:

• generic webhooks
• Splunk HEC connectors
• Slack and PagerDuty connectors
• NAC and IdP policy connectors
• Microsoft Sentinel / Azure Monitor delivery
• recovery runners and audit sinks

Typical operator checks:

• whether a connector is healthy
• whether deliveries are backing up
• whether signing material is available
• whether a destination is suppressing or rejecting events

11. Agent downloads

Some deployments publish current endpoint bundles under /downloads/.

When enabled, the landing page and dashboard expose:

• Linux agent bundle
• macOS agent bundle
• Windows agent bundle
• manifest.json
• SHA256SUMS

Use those downloads when you want operators to fetch the exact bundle version currently published by the deployment.

Before rollout, verify:

1. the archive checksum matches SHA256SUMS
2. the bundle matches the target operating system
3. the device certificate and config paths are correct for the endpoint

12. Audit trail expectations

Sentinel is designed to leave a reviewable decision trail.

Operators should expect audit visibility for:

• sign-ins and sign-outs
• approval and rejection actions
• command dispatch and acknowledgement
• certificate revocation and identity review
• rollout pauses, resumes, and signals
• recovery job approvals and results
• service health transitions

When something looks unusual, check the audit trail before retrying or overriding policy.

13. API and scripting reference

The dashboard is the easiest operator path, but many workflows also map cleanly to the API.

Use operator_api_workflows.md for route-level guidance when you need to:

• script admin actions
• automate review flows
• inspect recovery or rollout state externally
• integrate Sentinel with internal runbooks

14. Common operator runbook

For a normal daily check:

1. Sign in to /dashboard.
2. Review pending approvals.
3. Check service health and scheduled jobs.
4. Review any devices with degraded trust or expiring certificates.
5. Review recent audit events for unexpected revocations, pauses, or failures.
6. Check integration delivery health if downstream systems depend on Sentinel events.

15. Troubleshooting

If the dashboard loads but data looks stale:

• check service health first
• verify /api/health/ready
• confirm the affected worker is still running

If a device never becomes trusted:

• verify certificate paths and CA trust on the agent
• check whether enrollment approval is required
• inspect certificate common name and device_id
• review attestation policy failures

If operator sign-in fails:

• verify credentials
• check whether TOTP or passkey is required
• look for login throttling or session-limit conditions

If a command or rollout does not progress:

• confirm approvals were completed
• confirm the device is online
• confirm the relevant worker and scheduler services are healthy