How do you separate development from admin access at a small startup?

The biggest improvement would be separating privileged work from everyday development. A dedicated, tightly managed admin device or virtual desktop can keep browser activity, email, and package installs away from the environment used for cloud and customer access.

That separation is not magic. If the admin environment shares credentials, files, or sessions with the development machine, malware may still reach the things that matter. Keep it minimal, patch it, and avoid using it for routine browsing.

MFA and short-lived cloud credentials are a solid start, but they do not protect secrets already available on a compromised workstation. Check what the machine can access: SSH keys, cached sessions, VPN profiles, local config files, and deployment credentials. Reduce those permissions and avoid leaving reusable secrets lying around.

For cloud roles, time-limited elevation with logging can limit exposure. Make sure sign-ins, new accounts, permission changes, and unusual access generate alerts you will actually review. For a one-person IT function, a small number of useful alerts beats a huge stream of noise.

For the package side, pin dependencies and review changes rather than automatically taking whatever is newest. Use lockfiles, scan dependencies, and keep build and deployment permissions separated where you can. Never run package installation or build steps as root unless there is a specific need.

A dev container can help keep project tools and files contained, but it is not a strong security boundary if it has access to the host filesystem, agent socket, credentials, or privileged devices. Treat it as hygiene, not a replacement for separating admin access.

With a small team, I would focus on making the blast radius smaller rather than trying to prove the workstation can never be compromised. Use separate accounts for routine work and administration, grant only the access each task needs, and make customer access distinct rather than reusing broad credentials.

Also decide what you would do if the machine were compromised: revoke sessions and keys, disable access, rebuild from trusted installation media, and check cloud and customer-side logs. A written recovery checklist can save a lot of time when you are the only person handling it.

Detection is worth adding, but expect to tune it. Forward endpoint and cloud audit logs somewhere the workstation cannot quietly erase, then alert on events such as unexpected privilege changes, new credentials, or logins from unusual locations. Host monitoring tools can add useful signals, though they need maintenance and are not a guarantee against new attacks.