Why do open source models increase identity governance pressure?

Why This Matters for Security Teams

Open source models change the identity problem because they invite AI execution into environments the enterprise already controls. That means the burden shifts from vendor-managed guardrails to internal governance for permissions, secrets, service accounts, and operational change. NHI guidance in the Ultimate Guide to NHIs and the Top 10 NHI Issues shows that the real risk is not model provenance alone, but unmanaged identity sprawl once the model becomes operational.

This is where many programmes underestimate pressure. Security teams may approve an internal deployment as if it were just another application, then discover the model is now calling APIs, reading data, writing code, or orchestrating infrastructure with broader access than a human operator would receive. The identity layer becomes more complex because the workload is not static: it can be reconfigured, embedded in pipelines, and extended through tool use. Current guidance from the NIST Cybersecurity Framework 2.0 still applies, but open source models increase the number of identities, tokens, and approvals that must be tracked continuously. In the 2026 Infrastructure Identity Survey, Teleport reported that 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments.

In practice, many security teams encounter over-privilege and untracked machine access only after the model has already been embedded in production workflows.

How It Works in Practice

Open source models increase identity governance pressure because the organisation becomes the operator of the full stack. That includes the runtime environment, the inference service, any orchestration layer, and every secret the workload can reach. For that reason, governance should treat the model as a non-human workload identity, not as a user. Best practice is evolving toward short-lived credentials, workload identity, and policy evaluation at request time rather than durable access grants.

A practical control pattern looks like this:

• Bind the model or agent runtime to a workload identity, not a shared human account.
• Issue ephemeral secrets or tokens per task, then revoke them automatically when the task ends.
• Scope access to the smallest API set needed for a defined job, not the broadest access that seems convenient.
• Evaluate requests at runtime using policy-as-code rather than trusting a one-time approval.
• Log every tool invocation, data access, and privilege change as a distinct identity event.

This maps well to workload identity approaches such as SPIFFE and to runtime authorisation models described in CISA Zero Trust Maturity Model guidance, but the operational challenge is still identity lifecycle management. The State of Non-Human Identity Security report highlights that lack of credential rotation and over-privileged accounts remain major causes of NHI-related attacks, which becomes even more dangerous when the workload can generate new actions autonomously. The control objective is not to eliminate model capability, but to make every capability explicitly granted, short lived, and attributable.

These controls tend to break down when open source models are deployed inside fast-moving data science or platform teams that can create new service accounts and API integrations faster than central security can review them.

Common Variations and Edge Cases

Tighter identity controls often increase deployment friction, requiring organisations to balance speed of experimentation against auditability and revocation. That tradeoff is especially visible in research environments, developer sandboxes, and hybrid deployments where one model instance may be promoted from test to production without a clean identity reset.

There is no universal standard for this yet, but current guidance suggests treating every environment boundary as an identity boundary. A model fine-tuned by a data science team may need different permissions than the same model packaged into a customer-facing service. Likewise, a local open source deployment may look safer than a SaaS model, yet it can create more governance pressure because the organisation now owns patching, secrets handling, logging, and permission review. NHIMG’s Ultimate Guide to NHIs emphasises that lifecycle discipline matters as much as initial provisioning, and the same principle applies here.

Edge cases also appear when open source models are wrapped in agents that can chain tools or call other services. In those environments, identity governance must account for delegated access, downstream token reuse, and hidden privilege amplification. That is why the practical question is not simply whether the model is open source, but whether the enterprise can continuously prove who or what is acting, on whose behalf, and with which rights.

Related resources from NHI Mgmt Group

• Why do online identity verification workflows create more governance pressure than in-person checks?
• Why is it important to integrate identity and data governance?
• How should teams use cybersecurity benchmark reports in identity governance planning?
• How should teams use DSPM findings in identity governance reviews?