Private AI inference does not automatically mean secure inference. When applications and models run inside the same Kubernetes cluster, the difficult question is often simpler than model selection: which workload is allowed to call which model, and how is that permission proven? Kubernetes service account tokens offer one way to answer it without distributing long-lived shared API keys to every application.

Microsoft’s September 2026 Foundry Local on Azure Local extension release, version 2609, added Kubernetes service account token (SAT) authentication for in-cluster inference. Microsoft documents short-lived, audience-bound tokens that identify a Kubernetes workload and authorize access to a particular ModelDeployment. The capability is in preview and applies to data-plane inference, not to the platform’s control plane. That scope distinction is essential for architecture and procurement reviews.

Why a shared inference key becomes a governance problem

Consider three applications using a local model endpoint: a customer-support assistant, a finance document processor and an internal developer tool. A single static API key copied into all three workloads makes access convenient but creates a weak attribution boundary. If the key leaks, the platform may not be able to distinguish the original caller from an unauthorized one solely from that credential.

A service account is a Kubernetes workload identity. With a projected SAT, the caller receives a token intended for a particular audience and with a bounded lifetime. Foundry Local validates that identity against authorized service account names and namespaces in the model deployment configuration. This is not a universal substitute for application-level authorization: the model endpoint can know the workload, but it does not automatically know whether an individual employee is permitted to see a specific document.

Understand the four-part trust chain

Boundary Required control Question to test
Workload Dedicated Kubernetes service account Can an unapproved pod impersonate the caller?
Token Projected, expiring, audience-bound SAT Will a wrong-audience or expired token fail?
ModelDeployment Explicit authorized service account and namespace Can another service account invoke this model?
Network Internal endpoint, TLS and controlled routing Is the endpoint reachable beyond intended clients?

This is an editorial trust-boundary model, not a vendor security certification. Microsoft’s setup guide calls for a dedicated service account, automountServiceAccountToken: false, and a separately projected token volume. The documented example uses the audience foundry-local and a one-hour token lifetime. Kubernetes rotates projected tokens; the client must reread the token file instead of caching the initial value indefinitely.

Workload identity is not permission to create any workload

One of the most important details in Microsoft’s guidance is easy to miss. Kubernetes RBAC does not provide a general use privilege for choosing a service account in a pod specification. A person or automation allowed to create pods with the authorized serviceAccountName could potentially run a workload under that identity. Microsoft therefore recommends restricting who can create or modify workloads and using admission policy to reject unauthorized service-account selection.

That makes the deployment pipeline part of the inference authorization boundary. Review the privileges of developers, GitOps controllers, CI runners and namespace administrators. If an untrusted deployment system can schedule a pod using a privileged inference identity, a short-lived token alone will not solve the problem. This complements the distinction between credentials and permissions in enterprise automation token migration and the broader agent tool authorization analysis.

Five acceptance tests for an enterprise pilot

Test Expected outcome Evidence
1. Authorized workload Approved service account can invoke only the intended model endpoint Successful synthetic inference request
2. Identity mismatch Wrong service account or namespace is denied Failed request and deployment configuration
3. Audience and expiry Incorrect-audience and expired tokens are rejected; rotated token succeeds Token claims and timed test
4. Pod impersonation Unapproved actor cannot schedule a pod using the protected service account Admission-policy denial and role review
5. Network boundary Only approved network paths reach the endpoint; production TLS is trusted Connection test and certificate validation

These are proposed tests; they have not been run against the user’s environment. Avoid logging live bearer tokens. A testing command that disables TLS certificate verification can help diagnose a laboratory deployment with a self-signed certificate, but should not become a production integration pattern. Test negative cases using a separate, disposable namespace and synthetic data.

Where SAT authentication does and does not fit

Microsoft describes SAT authentication for callers running in the same Kubernetes cluster as the model deployment, including callers in another namespace. It does not cover external applications or control-plane operations. Foundry Local also supports API keys and Microsoft Entra ID authentication for different deployment scenarios. The right choice depends on caller location, identity lifecycle and operational connectivity.

Foundry Local on Azure Local runs on Arc-enabled Kubernetes, supports local inference and can operate in disconnected environments. That makes Kubernetes-native credentials appealing for factories, regulated environments and other sites where reliance on a remote identity provider may be undesirable. But preview status matters: enterprises should verify the exact extension version, supported runtime, upgrade behavior and support commitments before production procurement.

The operating model matters as much as the credential

Platform teams should own service-account creation, namespace policy, certificate trust and token-rotation tests. Application teams should own user-level permissions, prompt-data classification and observability. Security should review the ability to impersonate identities through workload creation, not merely confirm that the inference API requires a bearer token.

Document the result in a short access matrix: workload identity, namespace, allowed model, endpoint exposure, expected token audience and named owner. Repeat tests after a cluster upgrade, deployment template change or model migration. Pair this work with a broader agent-fleet isolation design and a realistic self-hosted inference cost framework. A private model is only as controlled as the workloads that can reach it.

Sources and scope

Related posts:

  1. Agent Fleet Infrastructure: How to Buy Density Without Losing Isolation
  2. How AI Fits into the Enterprise Technology Stack
  3. When Should an Enterprise Self-Host an AI Model? A Break-Even Framework
  4. LLM Prefix Cache Isolation: The Multi-Tenant Security Test Inference Buyers Miss