AI builders are the developers and teams that create, modify, deploy, or maintain AI models and applications. They influence the security posture of AI systems by shaping permissions, integrations, and data flows, so their identities and activities need monitoring like any other privileged technical role.
Expanded Definition
AI builders are the people and teams that shape AI systems by creating models, wiring integrations, tuning prompts or workflows, and maintaining the surrounding application stack. In NHI security, the term matters because builder identities often carry privileged access to code, cloud resources, model endpoints, and data pipelines, which makes them part of the trust boundary rather than just ordinary users.
Definitions vary across vendors and organisations, but the practical distinction is that AI builders influence both what the system can do and what it can reach. That places them closer to privileged engineering roles described in the NIST Cybersecurity Framework 2.0 than to general application users. Their activity should be treated as security-relevant when it changes permissions, data access paths, tool integrations, or deployment settings.
The most common misapplication is treating AI builders as a generic development group, which occurs when their access to secrets, production environments, and model controls is not separately governed.
Examples and Use Cases
Implementing controls for AI builders rigorously often introduces workflow friction, requiring organisations to balance speed of iteration against tighter approval, logging, and access constraints.
- A machine learning engineer updates a retrieval pipeline so the model can query internal documents; builder access must be monitored because the change affects data exposure and retention.
- A platform team deploys an agent with tool access to tickets, cloud APIs, and source control; the team’s identities need privileged oversight similar to other administrative roles.
- A prompt engineering group tests production prompts against live customer data; that activity should be traced because prompt changes can reshape output handling and leakage risk.
- An SRE team rotates API keys used by an AI application; key custody and rotation should align with secrets governance, not informal developer convenience.
- A security team reviews a high-risk code path after the DeepSeek breach to understand how builder choices contributed to exposed training and operational assets.
These scenarios map closely to the operational concerns discussed in The State of Secrets in AppSec, where developer behaviour and secret handling directly affect system risk.
Why It Matters in NHI Security
AI builders are a governance chokepoint because they often determine who can modify model behaviour, connect external tools, and access sensitive data. If their identities are not strongly authenticated and their privileges are not bounded, attackers can abuse the same paths builders use to deliver legitimate changes. This is why NHI programmes should treat builder accounts, service identities, and delegated automation as a single operational surface, not separate problems.
NHIMG research shows the operational gap is real: only 44% of developers are reported to follow security best practices for secrets management in The State of Secrets in AppSec, and that weak discipline becomes more dangerous when builders have access to model controls and production integrations. The risk is not just leakage, but silent persistence, broad data reach, and accelerated misuse once credentials are exposed. Builder governance also aligns with NIST Cybersecurity Framework 2.0 because it demands asset visibility, access control, and continuous monitoring across development and deployment.
Organisations typically encounter the impact only after a model leaks data, an agent acts outside its intended scope, or a compromised builder account is used to alter production behaviour, at which point AI builder governance becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Covers agent and builder misuse risks where tool access and execution authority can be abused. |
| OWASP Non-Human Identity Top 10 | NHI-01 | AI builder identities often carry privileged access and need strict lifecycle governance. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions and privilege management are central to builder risk reduction. |
| NIST Zero Trust (SP 800-207) | SC.L2-3 | Zero trust principles apply when builders access models, data, and tools across boundaries. |
| NIST AI RMF | AI RMF addresses human and organisational actors that shape AI system risk and controls. |
Restrict builder-facing agent permissions and review every tool integration before production release.
Related resources from NHI Mgmt Group
- Why do AI app builders create new identity and data risks in enterprise environments?
- How should security teams govern AI-powered website builders so they can move fast without creating unsafe products?
- How should security teams govern no-code AI app builders in enterprise environments?
- What is Agentic AI and how does it differ from traditional generative AI?
