Build Plane

What the build plane does

The build plane is the pre-production layer where AI agents are assembled, parameterised, and exercised before they are allowed to act in production. Its job is to shape the agent’s default behaviour, tools, policies, and test outcomes, not to grant live operating authority.

This separation matters because build-time approval can create a false sense of safety. A system may look well-reviewed in a controlled environment and still behave differently once it receives live data, real permissions, or production integrations.

Why the build plane is security-relevant

The build plane is where many of the conditions that later become production risk are introduced, including unsafe defaults, overly broad tool access, weak evaluation criteria, and incomplete isolation between environments. If these conditions are accepted upstream, they become harder to unwind once the agent is deployed.

It is also where security teams need to distinguish design assurance from operational assurance. A secure build process can reduce risk, but it does not prove that the agent will remain safe under production prompts, workflows, or chained actions.

How the build plane relates to runtime control

The build plane should be treated as a different control surface from runtime governance. Build-time checks answer whether an agent was prepared according to policy, while runtime controls answer whether that agent should be allowed to continue, escalate, or invoke tools in the current context.

That distinction is important in agentic systems because configuration, memory, tools, and permissions can drift after launch. Security review therefore needs both pre-deployment validation and live operating controls, rather than assuming one substitutes for the other.

What good build-plane assurance looks like

Effective build-plane assurance focuses on reproducibility, policy enforcement, and testability. The organisation should know what model version, instructions, tools, guardrails, and environment settings were used to assemble the agent, and should be able to retest those conditions when changes are made.

SLSA is a useful reference point for build integrity thinking because it emphasises provenance, controlled build steps, and resistance to tampering in the pipeline that produces software artefacts. For agent systems, the same mindset helps teams preserve trust in how an agent was created and tested.

OWASP SAMM is relevant where teams want to mature security into the delivery process itself, including the practices that define, review, and verify agent behaviour before release.

Risk and Threat Considerations

The build plane can become a hidden source of downstream compromise when unsafe instructions, poisoned test data, weak dependency controls, or overbroad tool settings are accepted before production. If those choices are not revisited later, the agent may carry a built-in weakness into live operation.

Failure mechanism: An attacker or careless internal change introduces malicious or overly permissive behaviour at build time, then that behaviour is preserved through deployment because the runtime environment trusts the build artefact or configuration.

Impact: The resulting agent may execute actions that were never intended, bypass policy expectations, or expose sensitive systems and data once it operates against real users and live services.

Practitioner Guidance

Why practitioners should care: The build plane is where many agent risks are created, even if they only become visible later. Teams should treat build-time approval as one assurance layer, not as evidence that live behaviour is safe.

Governance implication: Ownership needs to be clear across engineering, security, and platform teams, because the build plane defines what is released into production and what assumptions downstream controls must inherit.

Practitioner takeaway: If the agent’s behaviour, permissions, or test outcomes change meaningfully after build, the release should be treated as a new security decision rather than a routine redeploy.

Related resources from NHI Mgmt Group

• Should organisations build their own authorization control plane or use managed tooling?
• What breaks when teams build AI agents with direct connections to models and internal tools instead of a governed control plane?
• What breaks when teams try to build distributed orchestration without a controller based control plane?
• What should security teams do first when a vulnerability affects a management plane or build pipeline?