Project Gleipnir

Project Gleipnir is an environment built by Patrick Robinson, an industrial electrician and automation tech, to utilize AI coding agents for studying and building while ensuring their safe operation on a home Linux workstation. The key elements of this setup include separate identities for each AI agent, sandboxed launch, controlled network egress, and a shared knowledge base with controlled permissions.

Each agent operates as its own Linux user, preventing them from running as the user. Agents are launched through systemd with sandboxing, limiting access to read-only system directories, hidden home directories, and only explicitly listed paths. Resource limits are set to prevent runaway processes from compromising the machine. Network egress is controlled through per-agent firewall rules, ensuring that each agent can only communicate with its designated AI provider via a local filtering proxy.

The agents are also subject to policy controls, which serve as an additional layer of security. The agents' own permission settings further restrict access to sensitive areas within the system, providing an additional layer of protection. A shared knowledge base, consisting of study notes, is stored on a separate filesystem with group ownership, setgid directories, and default ACLs, allowing all agents to access it while keeping project records, paid course material, and application configuration read-only or invisible to the agents.

To ensure recovery, hourly Git snapshots of the shared notes are taken, allowing for restoration in case of any accidental deletions or corruption. Nightly encrypted backups are also performed, with a restore procedure tested for functionality. The user works by drafting changes, having them reviewed by the other agent, and then approving the changes themselves. Any privileged changes are performed manually, one step at a time.

Thorough testing is conducted to ensure the security of the setup. Structured tests are run to intentionally attack various controls, verifying that they refuse to execute unauthorized actions and recording the exact error messages. Honest records are maintained through a findings register, daily logs, and a policy changelog with checksums of all installed software.

The user emphasizes the importance of verifying which layer each test proves, as stacked layers can create a false sense of security if not properly documented.

The user's experience highlights the importance of testing the actual controls rather than relying solely on settings that say "deny." In some cases, multiple sandbox layers can stop unauthorized actions before reaching the deepest level of protection. The user recommends documenting which layer each test validates to avoid misunderstandings about the system's security.

In terms of recovery, the user emphasizes that recovery steps should not be included within the main runbook. Instead, they should be documented separately, as experienced a situation where following a procedure step-by-step led to an unintended rollback of changes. The recovery steps are now kept in a separate file for easy access and to prevent accidental execution.

Looking ahead, the user plans to apply the same rigorous security measures to networking, starting with a virtualization host for isolated lab segments, followed by physical networking, and finally an OT segment with PLC/HMI equipment and industrial protocols. This approach combines the user's electrical and automation background with security expertise.

The documentation of the architecture, controls, testing methodology, and reasoning behind them will remain private, as they pertain to operational details not intended for public dissemination.