Once you’ve got multiple teams, model services, and AI applications sharing the same Kubernetes cluster and GPU pool, IAM stops being enough on its own. Roles and permissions tell you who can touch what — they say nothing about which workloads are allowed to talk to each other over the network. That’s a separate problem, and it’s the one AI-Stack Network Policy is built to solve.
In practice, it comes down to a handful of questions any platform team runs into sooner or later:
- Which subnets should be allowed to reach a given AI workload — and which should be locked out?
- Where is that workload allowed to connect out to, and what should be off-limits?
- Inside one project, which containers actually need a policy applied to them at all?
AI-Stack closes that gap with built-in Network Policy: users set ingress and egress rules on the platform and apply them to specific pods in a project.
Every policy has three parts — ingress (allowed and excluded source subnets), egress (allowed and excluded destination subnets), and scope (which pods it applies to). Together, they let you draw real security boundaries between workloads on shared infrastructure.
What Network Policy Actually Controls
Network Policy on AI-Stack works across four layers:
Ingress control. Allow and exclude source subnets to decide what can reach a workload.
Egress control. Allow and exclude destination subnets to decide where a workload can connect out to.
Pod-level scope. Apply a policy to specific pods in a project, so different workloads run under different rules.
Project-level isolation. Turn on Enhanced Network Isolation Mode and AI-Stack enforces the boundary between projects automatically — no per-workload setup required.
Two Modes, Two Philosophies
Not every team needs the same level of control. Some want to hand-tune ingress and egress rules around their own architecture; others want hard multi-project isolation with zero room for user error.
AI-Stack covers both with two distinct modes:
- Standard Mode — you configure the rules, workload by workload.
- Enhanced Network Isolation Mode — the system enforces isolation for you, no exceptions.
One is about flexibility. The other is about guarantees.
Standard Mode: Rules That Fit the Workload
Standard Mode fits when access boundaries need to vary by application, by model service, or by your existing network architecture.
Users can build a Network Policy directly in AI-Stack, setting ingress and egress rules (allow/exclude subnets) and choosing exactly which pods in a project each policy applies to.
Ingress rules — allow and exclude subnets that define exactly which source networks are in scope.
Egress rules — the same idea, applied outbound.
A RAG application that only ever needs to hit a couple of internal subnets can be scoped down to just those, instead of leaving its egress wide open.
Scope — which pods in the project the policy actually touches. This is what lets workloads in the same project run under completely different rules, for example:
- Lock the model server down with a tight ingress policy
- Open the RAG application up to the internal subnets it genuinely needs
- Give the web application its own separate set of ingress and egress rules entirely
The result: access control shaped around what each workload actually does, not a one-size-fits-all rule.
Enhanced Network Isolation Mode: The System Draws the Line
On higher-security shared infrastructure, letting people manage their own Network Policy isn’t always good enough — rules drift, get misconfigured, or get forgotten. That’s the gap Enhanced Network Isolation Mode closes.
Instead of leaving policy to users, AI-Stack takes over completely: once enabled, pods in one project simply can’t reach pods in another.
Take an example:
- Project A — vLLM, a RAG application, a web application
- Project B — a model service, an AI application, a dev pod
With this mode enabled, Project A and Project B are walled off from each other by default — no direct pod-to-pod connections, no exceptions. Because the boundary lives at the system level, not in a config someone could get wrong, there’s no way for a missing rule or a bad edit to break isolation later.
Standard Mode vs. Enhanced Network Isolation Mode
| Standard Mode | Enhanced Network Isolation Mode | |
| Who manages it | You do | AI-Stack does |
| Ingress / egress rules | Configurable (allow/exclude subnets) | AI-Stack does |
| Scope | You pick the target pods | Applied system-wide |
| What it’s for | Fine-grained control per workload | Guaranteed isolation between projects |
| Best fit | Teams needing flexible rules | High-security, multi-tenant setups |
In short:
Standard Mode decides which networks a pod can talk to.
Enhanced Network Isolation Mode decides whether pods in different projects can talk to each other at all — and the answer is no.
FAQ
How does Network Policy control Ingress and Egress?
Network Policy defines separate Ingress and Egress rules to control allowed or blocked network traffic, enabling network isolation between workloads.
What’s the core difference between the two modes?
Standard Mode puts you in the driver’s seat: you build the policies, set the subnets, pick the pods. Enhanced Network Isolation Mode takes that decision away and enforces project-to-project isolation from the system side.
What exactly can I configure in Standard Mode?
Ingress allow/exclude subnets, egress allow/exclude subnets, and which pods in a project each policy applies to.
Can I tweak Enhanced Network Isolation Mode rules myself?
No — by design. It’s a system-level control, not a user-facing one, so a misconfigured or outdated rule can never quietly open a gap between projects.
What does Enhanced Network Isolation Mode actually block?
Direct pod-to-pod communication across projects — cutting off a whole class of cross-project access and lateral-movement risk.
When does Enhanced Network Isolation Mode make sense?
It’s the right call when:
- Multiple departments share one GPU cluster
- Multiple customers share the same AI infrastructure
- Different projects handle data with different sensitivity levels
- You have real multi-tenancy requirements
- Project isolation needs to be mandatory, not something a user can dial back
- You want isolation enforced by the system, not left to individual users
Can I switch Enhanced Network Isolation Mode on or off after installing?
No. It’s decided once, at install time — changing it later means a full reinstall.
The Bottom Line
AI infrastructure rarely stays a single model and a single team for long — it grows into multiple models, applications, and projects sharing the same Kubernetes and GPU resources. At that point, one layer of network control isn’t enough.
That’s why AI-Stack offers both. Standard Mode gives users fine-grained control shaped around each workload’s needs. Enhanced Network Isolation Mode takes the opposite approach — no configuration, no exceptions, just a guaranteed boundary enforced by the system itself.
Together, they let flexible workload-level policy and hard project-level isolation coexist — so shared Kubernetes and GPU infrastructure doesn’t force a trade-off between flexibility and security.
Curious how AI-Stack Network Policy and Enhanced Network Isolation Mode could fit into your own environment? Reach out to the INFINITIX team.
