Open models expand who can run, modify, and connect AI systems, so identity controls become the main way to limit misuse. They increase the number of human and non-human identities, tokens, and tool permissions that must be authenticated, authorized, monitored, and revoked across training, deployment, and runtime.
What open models change about identity governance
Open models lower barriers to entry for experimentation, fine-tuning, hosting and integration, which means more people and systems can create access paths to the same model estate. That makes identity governance a core control plane for who may do what, under which credentials, and with which tools.
The governance problem is not only “who can call the model,” but also who can change prompts, weights, adapters, inference endpoints, plugins, and deployment settings. As the number of operators grows, so does the need for clearer ownership, entitlement design, and reviewable access boundaries.
Why openness increases the number of identities to govern
Closed model stacks often concentrate control in one vendor or one platform team. Open models distribute control across developers, ML engineers, platform operators, third-party hosting providers, and sometimes external collaborators, each of whom may hold different permissions and credentials.
That distribution creates more identity surfaces to inventory. Human accounts, service accounts, API keys, deployment tokens, and CI/CD identities can all become part of the model lifecycle, and each one needs a defined owner, purpose, and expiry or review process.
Open ecosystems also encourage reuse, forks, and custom deployment paths. When teams reuse the same model artifact across environments, identity governance becomes the way to preserve separation between development, test, and production access, rather than assuming the model itself provides that boundary.
Authentication, authorization, and revocation become the control layer
Because open models are easier to copy and move, the decisive question becomes who can authenticate to the surrounding systems and what they can authorize themselves to do. Identity governance ties those decisions to named actors, not to the model package alone.
That includes controlling who can publish a model, who can attach tools, who can approve new permissions, and who can rotate or revoke secrets used by model-serving infrastructure. In practice, governance must span training jobs, registries, inference services, orchestration layers, and adjacent data sources.
When access is granted too broadly, the model may be technically “open” while the operational environment becomes opaque. Good governance reduces that opacity by making permissions legible, reviewable, and removable.
Why runtime monitoring matters as much as initial approval
Open models change faster than many organisations change their access lists. That means the risk often appears after initial approval, when new tools are added, a fine-tune is published, or a deployment pipeline gains broader reach than intended.
Identity governance therefore has to watch for drift: stale tokens, unused accounts, overprivileged service identities, and abandoned integrations that still have live permissions. The control objective is not just admission, but continuous authority management across the model’s lifecycle.
Runtime visibility also helps distinguish legitimate operational activity from misuse. If a model-connected identity begins calling unusual systems, expanding scope, or using credentials outside its normal pattern, that is a governance signal as much as a detection signal.
Risk and Threat Considerations
Open models increase exposure because they multiply the number of parties, identities, and integrations that can touch the same AI system. The main risk is not the openness itself, but the widened trust boundary, which can turn weak ownership, excessive privilege, or poor revocation into model misuse, data access abuse, or unintended tool execution.
Failure mechanism: Attackers or careless insiders exploit overbroad permissions, stolen tokens, shared credentials, or forgotten service accounts to modify model behaviour, access connected systems, or persist through trusted integrations after the original change has been forgotten.
Impact: Organisations can lose control over model outputs, connected data, and downstream systems, while also making compromise harder to detect because the activity comes from identities that look operationally legitimate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Open models rely on credentials and tokens across training and deployment access. |
| IA-9 — Service Identification and Authentication | Model services, pipelines, and tooling authenticate as non-human actors in open-model estates. | |
| AC-6 — Least Privilege | Open-model ecosystems expand access paths, making privilege minimisation central to governance. | |
| Recommendation — Rotate, expire, and revoke model-related credentials and API tokens on a defined schedule. Authenticate model-serving workloads and automation with distinct service identities. Limit each model-related identity to the minimum permissions needed for its role. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | The term is about governing who may access, modify, and connect open model systems. |
| Recommendation — Apply identity and access controls to every human and non-human identity involved with the model. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Open models increase the number of machine identities whose permissions can exceed their purpose. |
| Recommendation — Audit model-adjacent machine identities for excessive permissions and trim unused access. | ||
Practitioner Guidance
Why practitioners should care: With open models, governance has to follow the identities and permissions around the model, not just the model artifact itself. Treat every training, deployment, and runtime credential as part of the security boundary, because those identities determine who can alter behaviour and who can connect the model to sensitive systems.
Common misunderstanding: “Open” does not mean “uncontrolled.” The right response is not to block openness, but to make ownership, entitlement review, secret rotation, and revocation more deliberate. A model that is easy to obtain still needs disciplined access management around its environment.
Practitioner takeaway: If an organisation cannot explain who owns each model-related identity, what it can do, and how quickly it can be removed, then the governance model is already too weak for open-model deployment.
Related resources from NHI Mgmt Group
- Why do open source models increase identity governance pressure?
- Why does NIS2 make identity governance more important for critical sectors?
- Why does NYDFS make identity governance more important than login tooling alone?
- Why do distributed data environments make traditional governance models less effective for sensitive data?