Keep consequential workflows bounded, reviewable, and recoverable.
Before a system touches real records, define what data may enter, who may act, which decisions stay with a person, what evidence gates release, and how the system will be rolled back.
Six controls gate every production release
Before an agent handles real records, Scale.mn locks the data path, access model, hosting boundary, key custody, logging policy, and recovery plan. Every control gets an owner, an acceptance test, and release evidence.
- 01 · Data boundary
Minimize and map the data
Classify fields, remove unnecessary inputs, map every system the data enters, and define the prohibited data boundary.
- 02 · Access and authority
Name who can see, change, and approve
Define roles, least-privilege access, the person with final authority, exception handling, and identity-provider integration when it is in scope.
- 03 · Hosting and residency
Choose the production boundary deliberately
Record the approved account, region, network boundary, data-residency decision, subprocessors, and the party responsible for each environment.
- 04 · Protection and keys
Assign credential and key custody
Specify transport and storage protection, secret handling, key ownership, rotation, revocation, and the evidence required before release.
- 05 · Logs and retention
Decide what is recorded and for how long
Define security events, log access, retention, export, deletion, and the privacy boundary before the workflow ingests real records.
- 06 · Recovery and incidents
Know who acts when the system fails
Set backup and restore targets, rollback steps, severity levels, incident contacts, notification duties, and the acceptance exercise.
Security decisions have named owners
Scale.mn owns the engineering controls and implementation evidence inside the agreed scope. The client retains lawful authority over its data, accounts, users, and production decision. Nothing critical is left implicit.
| Area | Scale.mn responsibility | Client and joint release gate |
|---|---|---|
| Requirements and data | Translate the agreed workflow, fields, rules, and security criteria into code, configuration, tests, and documentation. | Client confirms the lawful purpose, approved data, prohibited data, records owner, and acceptance authority. |
| Identity and infrastructure | Implement the agreed access and deployment controls inside the granted scope and record any exceptions. | Client owns production accounts, identity administration, user approval, credentials, and infrastructure choices unless a contract states otherwise. |
| Release and operation | Provide the agreed findings, test results, rollback steps, documentation, and handover evidence. | Both sides review residual risk and incident contacts; the named client authority approves or rejects production release. |
Every control leaves evidence
A complete release gives a reviewer a clear record of the architecture, access model, known risks, test results, dependencies, rollback path, and operating ownership.
- Architecture and data-flow mapSystems, boundaries, fields, destinations, and external dependencies.
- Access responsibility matrixRoles, approvals, privileged actions, account owners, and revocation path.
- Threat and risk registerCredible failure modes, mitigations, open exceptions, owner, and due date.
- Security acceptance resultsAgreed tests, observed result, failure evidence, repair, and retest receipt.
- Dependency and integrity recordVersions, licenses, hashes, update ownership, and known exceptions.
- Release and handover packDeployment, rollback, backup, incident contacts, operating limits, and source handover.
Put one agentic workflow through the security gate.
Bring the workflow, data owner, and security reviewer. Scale.mn will return a written boundary, release tests, evidence requirements, and handover plan before production.
Request the security brief Scale.mn · Ulaanbaatar, Mongolia · mike@scale.mn