Enclaves & security

An enclave is the security boundary in Halyard. Every project belongs to one enclave, fixed at creation, and that boundary determines which credentials, machines, and AI accounts the project’s agents can ever reach. Enclaves exist to prevent cross-pollution — for example, keeping a public open-source agent from ever touching corporate-private credentials.

What an enclave scopes

Three things are tied to an enclave:

• AI provider links — which CLI account is logged in on which node. The agent authenticates locally on the node; no AI account key is stored centrally.
• Enclave AI API keys — Halyard-owned provider keys (one per provider) that Halyard itself uses for server-side AI features such as AI-assisted task breakdown. These are encrypted at rest and write-only through the API: you can set them, but only a masked hint (the last few characters) is ever read back.
• Git credentials — the tokens used to clone repositories and open pull requests, stored encrypted.

Nodes also belong to an enclave, and a project’s sessions are only ever scheduled onto nodes within the matching enclave.

Enforced at dispatch, not just in the UI

Enclave membership is checked when a session is scheduled — not merely hidden in the interface. A session for a project in one enclave cannot be placed on a node in another, and cannot use credentials from another. The boundary is a scheduling and credential-resolution rule, so it holds even if the UI is bypassed.

Choosing an enclave

Because the enclave is permanent for a project, pick it to match the code’s sensitivity when you create the project. A common setup is separate enclaves for corporate-private and open-source work, each with its own AI accounts, nodes, and Git tokens — so the two never share a credential surface.