AI Can Build Your Service. How Much OS Should Ship With It?

Key takeaways

• Unikernels bundle an application with the operating-system components it needs.
• MirageOS builds these specialized images using OCaml and libraries.
• Removing unnecessary components can reduce attack surface, but application vulnerabilities remain.
• AI coding agents may ease development, while runtime security requires separate validation.

An AI coding agent may need a shell, a compiler, and a pile of dependencies to build your service. The finished service may need far less. Unikernels take that gap seriously: how much operating system should accompany a program into production?

Build a server around one job

A general-purpose operating system earns its keep by being flexible. It runs different programs, manages users and files, and supports a wide range of devices.

That flexibility becomes less compelling when a server has one narrowly defined job. A small service returning a fixed set of responses may have little use for an interactive shell or a package manager.

A unikernel packages the application together with selected operating-system components. Include networking if the application needs it. Leave out components it can do without. The result is an image built to run that particular application.

MirageOS follows this approach using OCaml, a programming language, and libraries that provide operating-system functionality. It can build an image for a virtualized environment without putting an entire general-purpose Linux distribution inside it.

There is a catch: MirageOS does not take an arbitrary server application and shrink-wrap it into a tiny appliance. Dependencies still matter. If your program expects a particular filesystem or calls external command-line tools, you need to work out how those requirements fit the new environment.

The design starts with understanding the application.

Fewer components mean fewer openings

The security appeal is reduced attack surface: fewer interfaces and capabilities that an attacker might exploit.

If an image contains no shell, an intruder cannot use that shell to issue commands. Removing unnecessary administration services also leaves fewer components to inspect, patch, and maintain.

Useful, certainly. Sufficient, hardly.

An authorization bug can expose another user’s records without ever launching a shell. A service with excessive database privileges can misuse those privileges without installing a single package. Application logic and access rights remain part of the security problem.

The internal architecture matters, too. Many unikernels put application code and operating-system functionality in one address space. They therefore lack the same internal process boundaries found in a conventional operating system.

A hypervisor can provide isolation between the unikernel and other workloads. How well that boundary protects the system depends on the surrounding setup.

Small images and limited privileges are separate properties. Removing software can reduce what an attacker has available. Restricting permissions reduces what a compromised service can reach. Both deserve attention.

AI could change the development economics

Unikernels also ask developers to give up familiar conveniences. Existing dependencies may need adaptation. Debugging workflows may need to change. Tools that work on a conventional server may not be available inside the deployed image.

AI coding agents could help with that work. They can assist with dependency analysis, code changes, and initial tests. If that assistance proves effective, a specialized runtime could become less expensive to build and maintain.

That possibility is more interesting than the amount of code an agent produces.

A successful compilation proves only so much. A port may handle normal requests while failing when connections drop or storage runs out. Authentication and cryptographic behavior need deliberate validation, regardless of who wrote the code.

The useful measures are the time needed to verify the required behavior and the defects that emerge in operation. Whether agents improve those measures needs to be established in actual projects.

If they lower the cost enough, teams may revisit designs they previously passed over because a general-purpose environment was easier to support.

Keep the workshop separate from the service

A coding agent’s workspace and a deployed service have different jobs.

The agent needs to read and edit files, run compilers and tests, and sometimes install dependencies. Its workspace needs enough functionality to support those activities.

A finished service may only need to accept a defined request and return a defined response. Carrying every development tool into production adds capabilities that its job may never require. That makes services with clear responsibilities and well-understood dependencies plausible candidates for a unikernel.

The deployment still needs careful boundaries. Limit the data and credentials the service can access. Restrict outbound connections to required destinations. Make sure operators can diagnose failures and replace the image with a corrected version.

For systems that need to run many different tools during operation, these constraints may be costly. Suitability depends on the workload.

The useful question is what disappeared when the server got smaller: unnecessary code, exploitable interfaces, excessive permissions—or some combination of them. A smaller image becomes a security improvement when you can explain which opportunities it removed from an attacker.