Security built for deployment-critical records

Dagmont protects the integrity and availability of the records that determine whether a blocked robot deployment can proceed: requirements, incidents, evidence, corrective actions, configuration changes, retest results, operational history, and customer acceptance decisions.

Sign-in supports password authentication with multi-factor authentication (TOTP) and recovery codes. Access is role-based across admin, team member, and customer reviewer permissions. Authorization checks run server-side on application APIs. Sessions expire on a configured lifetime, can be revoked on sign-out (including sign-out from all sessions), and use HttpOnly cookies with Secure and SameSite controls. Sensitive browser requests are protected with Origin and Fetch Metadata checks.

Organization records are separated at the application and data-access layers. Automated tests verify that users cannot retrieve another organization's deployments, incidents, evidence, reports, acceptance records, audit events, or Command sites, fleets, robots, missions, and commands. Customer reviewers only see deployment records intentionally shared for review.

Evidence uploads record SHA-256 hashes and store files under organization-prefixed object keys. Case records preserve provenance, ownership, timestamps, and relationships between requirements, incidents, evidence, corrective actions, retests, and acceptance decisions. Significant write actions and evidence downloads create organization audit events with actor, action, object, and timestamps. Customer review and acceptance decisions remain bound to the authorized shared record.

Production evidence ingest uses per-organization integration credentials with HMAC request signatures, timestamp verification, nonce replay protection, scoped permissions, rotation, and revocation. Failed ingest authentication and payload handling are recorded as dead letters for administrator review. A legacy global ingest secret may exist only as a compatibility fallback and is not the primary production model.

Traffic to Dagmont services is protected with TLS encryption in transit. Application data and evidence files are stored in managed cloud services used by Deployment Intelligence and Command. Secrets and credentials are maintained outside source code and handled through secure runtime configuration.

Dagmont maintains documented backup and restore procedures covering application-database restore, evidence-storage validation, and post-restore verification of sign-in, organization access, deployment and evidence access, reports, audit visibility, and Command create-case flows when in scope.

Operational practices include rate limiting on sensitive authentication paths, review of suspicious authentication activity, documented incident handling, production change control, customer offboarding, data export and deletion workflows, and Command authorization boundaries that keep live-control privileges inside the organization. Dependency monitoring and access review follow internal operational runbooks.

Dagmont's security program is organized around controls commonly evaluated for security, availability, and confidentiality during enterprise assurance reviews. Dagmont provides accurate information about implemented controls, testing status, and independent assessment status during customer procurement.

Dagmont Deployment Intelligence owns investigation, evidence, corrective action, retesting, reporting, and customer acceptance. Dagmont Command owns supervised live operations and controlled escalation into Deployment Intelligence.