Open-weight enterprise AI shifts control back inside the tenant

At a glance

What this is: Redblock argues that enterprise AI should run inside customer-controlled environments, with open-weight models keeping inference close to the data and inside the tenant boundary.

Why it matters: This matters because identity and access teams still have to govern who and what can execute privileged AI work inside the tenant, even when the model itself is no longer external.

Context

Open-weight enterprise AI changes the control boundary, not the control problem. When inference moves inside a customer tenant or on-premises environment, data exposure may shrink, but the organisation still has to govern which identities can invoke models, feed them data, and trigger privileged actions.

For IAM, PAM, and NHI teams, the important question is not whether the model is hosted externally or internally. It is whether access to AI execution is lifecycle-managed, scoped, and monitored like any other privileged workload in the estate.

Key questions

Q: How should teams govern open-weight AI running inside their tenant?

A: They should govern it as a privileged workload with a named owner, scoped permissions, and clear revocation paths. Tenant-local hosting reduces external exposure, but it does not remove the need to control who can invoke the model, what data it can touch, and whether it can trigger downstream actions. The right control model combines IAM, PAM, and lifecycle enforcement.

Q: Why do local AI auth files create a high-value identity risk?

A: Because they often contain reusable credentials, especially refresh tokens, that outlive a single session and can be abused from another host. Once those files are exposed, the attacker may not need a password or interactive login at all, only the stolen token material and a place to use it.

Q: What breaks when AI agents have production access without containment?

A: What breaks is the assumption that identity permission alone is enough to control impact. If an AI agent can reach production systems directly, one mistaken action can delete environments, modify configurations, or disrupt services before review processes can intervene. Containment must limit where the permission can be exercised, not just what the identity is allowed to request.

Q: How do identity teams decide whether customer-controlled AI is safer than external inference?

A: They should compare control over permissions, logging, dependency management, and revocation rather than assuming local hosting is automatically safer. Customer-controlled AI is preferable when the organisation can actually enforce access boundaries and operate the stack responsibly. If not, the internal deployment may simply substitute one dependency risk for another.

Technical breakdown

Why tenant-local inference changes the trust boundary

Open-weight deployment inside a tenant moves the model runtime under customer control, which reduces dependence on external API paths and third-party inference services. That changes the attack surface from vendor-managed model access to local controls over who can call the model, what data it can reach, and which downstream systems it can touch. The key architectural point is that deployment location does not equal governance maturity. If privileged workflow triggers, connectors, or agents can execute without tight entitlements, the tenant still inherits the risk. In practice, identity becomes the gating layer for model invocation and post-inference action.

Practical implication: Treat tenant-local AI execution as a privileged workload and enforce access boundaries at invocation time.

Identity, privilege, and delegated AI actions

When AI systems perform operational work inside identity infrastructure, they behave like non-human operators with delegated authority. That creates a governance problem similar to service accounts and automation tokens, but with more dynamic behaviour and less predictable action paths. The real control issue is not just authentication, but authorisation scope, task duration, and revocation. If an AI system can read data, transform it, and trigger remediation, its permissions need to be narrower than the process it supports. This is where NHI governance intersects with agentic AI: the identity of the model runtime, its credentials, and its downstream permissions become inseparable.

Practical implication: Map every AI runtime to an identity, define its allowed actions, and remove any permission it does not need.

Operational resilience depends on control of the execution layer

Open-weight systems are often positioned as resilience plays because they reduce exposure to upstream API changes, pricing shifts, and vendor outages. That resilience only exists if the organisation can actually operate the model stack, patch it, and govern its dependencies without reintroducing shadow control paths. In other words, internal hosting shifts dependency risk from external service availability to internal platform discipline. For security teams, the lesson is that self-hosted AI is only resilient when access, monitoring, and configuration are managed as first-class controls, not ad hoc engineering choices.

Practical implication: Build AI runtime governance into existing IAM, PAM, and change-control processes rather than treating it as a separate stack.

NHI Mgmt Group analysis

Tenant-local AI shifts the control problem from data egress to identity governance. Keeping inference inside the tenant can reduce exposure to external processing, but it does not remove the need to govern who can invoke models and what those models can do next. The meaningful security boundary becomes the set of identities, permissions, and execution paths around the model runtime. Practitioners should treat the tenant boundary as a governance zone, not a guarantee of safety.

Open-weight deployment creates a clearer case for treating AI runtimes as non-human identities. When a model or agent can execute inside an enterprise environment, it behaves like a privileged workload that needs ownership, lifecycle, and revocation rules. That framing aligns with NHI governance more closely than traditional application hosting models do. The practitioner takeaway is to inventory AI execution identities with the same discipline used for service accounts and automation tokens.

Execution inside customer infrastructure does not eliminate blast radius. It relocates it. The organisation may avoid external inference exposure, but it can still suffer overbroad permissions, weak connector governance, and unclear accountability for automated actions. This is the same governance pattern seen in many NHI programmes: control improves only when identity scope, not just hosting location, is managed. Teams should assume internal hosting still demands explicit privilege boundaries.

Open-weight enterprise AI will push security teams toward control-plane thinking. The real question is not which model family is used, but how access to the model, its tools, and its downstream workflows is mediated. That shifts attention to authorisation, logging, and operational separation across the AI stack. The practical conclusion is that AI security and IAM will converge around runtime governance, not model preference.

Identity governance is becoming the organising principle for customer-controlled AI. As enterprises keep more AI execution inside their own boundary, they need a way to decide which workloads can act, which data they can touch, and when their permissions expire. That is a governance design problem, not a procurement one. Practitioners should align AI deployment decisions with NHI and PAM controls from the start.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Read next: Privileged Access Management Guide

What this signals

Tenant-local AI is becoming an IAM problem as much as an AI architecture choice. As more inference moves inside customer boundaries, security teams will need to govern the identities of model runtimes, connectors, and orchestration layers with the same rigor applied to privileged administrative accounts. The organisations that get ahead will be the ones that define ownership and revocation before the AI stack becomes operationally embedded.

Open-weight deployment creates a new form of control-plane sprawl. Every additional model, tool chain, and local deployment option adds another place where permissions can drift and automated action can escape oversight. That makes lifecycle discipline more important than the hosting model itself, because the security outcome depends on whether execution remains observable, bounded, and revocable.

For practitioners

• Define AI runtime identities Assign each model, agent, or orchestration layer a unique identity and owner so execution can be authorised and reviewed like any other privileged workload.
• Scope model permissions tightly Limit what the AI runtime can read, write, and trigger, especially where it can touch identity systems, remediation workflows, or production data.
• Separate inference from action Keep model generation distinct from remediation, provisioning, or administrative execution so a prompt or output cannot directly become privileged change.
• Review internal AI dependencies Map connectors, APIs, and on-premises components that support tenant-local inference so platform resilience does not hide ungoverned execution paths.

Key takeaways

• Open-weight enterprise AI can reduce external data movement, but it does not remove the need to govern model invocation, privileges, and downstream execution.
• The central security question shifts from where the model runs to who controls the identities, permissions, and action paths around it.
• IAM, PAM, and NHI controls need to extend into AI runtimes if customer-controlled deployment is going to improve security rather than just move the risk boundary.

Key terms

• Tenant-Local AI Inference: Tenant-local AI inference is the practice of running model execution inside the customer’s own environment rather than sending data to an external service. This shifts operational control inward, but it also moves governance responsibilities onto the organisation’s own identity, access, and runtime controls.
• AI Runtime Security: AI runtime security is the set of controls that inspect, constrain, and respond to model behavior while the application is live. It includes detection, masking, policy enforcement, and response shaping, all aimed at reducing the blast radius of unsafe model interactions.
• Delegated AI Authority: Delegated AI authority is the permission a person gives an assistant to act inside business systems on their behalf. It turns a conversational tool into an execution layer, which means security teams must govern scope, auditability, and revocation with the same seriousness they apply to privileged access.
• Governance Control Plane: The layer where identity policy is enforced across approvals, reviews, and revocations. It becomes materially stronger when it can consume external risk signals in real time, because access decisions are no longer isolated from the security state of the identities they govern.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners apply consistent control thinking to AI runtimes, service accounts, and other privileged automation.