Day 142 — Cilium Network Policy: Securing AI Workloads with eBPF-Powered, Application-Aware Controls

21st May 2026, Netherlands — AI workloads are not like traditional web applications.

A normal microservice may call a database, cache, and a few internal APIs. But an AI workload may communicate with model registries, vector databases, object storage, embedding services, GPU nodes, observability backends, feature stores, external APIs, and sometimes third-party LLM providers.

That means the network surface becomes much larger.

For SREs, DevOps Engineers, Platform Engineers, and AI Engineers, this creates a very important question:

How do we make sure every AI workload can talk only to the systems it genuinely needs, and nothing else?

Cilium Network Policy steps in.

Cilium brings Kubernetes network security closer to the application layer. It supports standard Kubernetes NetworkPolicy, but also extends it with Cilium-specific policies such as CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy, enabling L3/L4/L7 controls, DNS-based egress control, identity-aware rules, and deeper visibility through eBPF. Cilium documents three Kubernetes-native policy formats: standard NetworkPolicy, CiliumNetworkPolicy, and CiliumClusterwideNetworkPolicy. Standard Kubernetes NetworkPolicy supports L3/L4 ingress and egress controls, while Cilium-specific policies extend the model with richer capabilities. (Cilium Documentation)

What Is Cilium Network Policy?

A network policy defines which network communication is allowed or denied between workloads.

In Kubernetes, without network policy, pods are usually free to communicate with each other depending on the CNI behavior. This is convenient during development, but risky in production.

Cilium Network Policy helps define rules such as:

• Which pods can talk to which pods.
• Which namespaces can communicate.
• Which ports are allowed.
• Which external domains are allowed.
• Which HTTP paths and methods are allowed.
• Which cluster-wide rules should apply everywhere.
• Which traffic should be explicitly denied.

In simple words:

Cilium Network Policy gives us a programmable network security boundary around workloads.

For AI workloads, this is extremely important because AI systems often handle sensitive data, tokens, prompts, embeddings, training datasets, model artifacts, and business-critical inference traffic.

Why Cilium Is Different from Traditional Network Policy

Traditional Kubernetes NetworkPolicy is useful, but limited. It mostly works at:

• Layer 3: IP address or pod selection.
• Layer 4: TCP/UDP port and protocol.

Cilium extends this with more advanced policy types, including application-aware Layer 7 controls. Cilium’s documentation and examples describe policy capabilities across L3, L4, and L7, including rules for HTTP, DNS, Kafka, services, CIDRs, entities, and FQDN-based egress.

This makes Cilium very suitable for AI platforms where we need fine-grained controls.

For example, instead of saying:

“This pod can talk to the model gateway on port 8080.”

We can say:

“This pod can only send POST requests to /v1/inference, but not access /admin, /debug, or /metrics.”

That is a much more precise security model.

Core Policy Types in Cilium

1. Kubernetes NetworkPolicy

This is the standard Kubernetes policy object.

It is portable and supported by many CNIs. With Cilium, you can still use standard Kubernetes NetworkPolicy for basic ingress and egress controls.

Example use case:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-inference-api
  namespace: ai-prod
spec:
  podSelector:
    matchLabels:
      app: inference-api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

This policy says:

Only pods with label app=frontend can access pods with label app=inference-api on TCP port 8080.

This is a good starting point, but for AI workloads, we usually need more than this.

2. CiliumNetworkPolicy

CiliumNetworkPolicy is a Cilium-specific policy object that provides advanced capabilities beyond standard Kubernetes NetworkPolicy.

It can be used for:

• L3/L4 pod-to-pod control.
• L7 HTTP-aware rules.
• DNS-based egress rules.
• FQDN rules.
• CIDR rules.
• Entity-based rules.
• Service-based rules.
• Explicit deny rules.

Example:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: restrict-inference-api
  namespace: ai-prod
spec:
  endpointSelector:
    matchLabels:
      app: inference-api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "POST"
                path: "/v1/inference"

This policy allows only the frontend to call the inference API using HTTP POST on /v1/inference.

This is very useful when an AI service exposes multiple endpoints but only one endpoint should be consumed by application clients.

3. CiliumClusterwideNetworkPolicy

CiliumClusterwideNetworkPolicy applies across the cluster instead of being limited to a single namespace.

This is useful for platform-wide security baselines.

For example:

• Deny all workloads from accessing cloud metadata service.
• Allow DNS only to approved DNS servers.
• Restrict access to sensitive platform services.
• Apply common egress controls to all namespaces.
• Enforce global security posture for AI workloads.

Cilium’s Kubernetes policy documentation identifies CiliumClusterwideNetworkPolicy as one of the supported policy formats alongside standard NetworkPolicy and namespaced CiliumNetworkPolicy.

Example:

apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: block-cloud-metadata
spec:
  endpointSelector: {}
  egressDeny:
    - toCIDR:
        - 169.254.169.254/32

This denies all workloads from accessing the cloud metadata endpoint.

For AI workloads, this is important because compromised pods should not be able to steal cloud credentials from metadata services.

How Cilium Policy Works Conceptually

Cilium is built on eBPF, which allows it to enforce network policies efficiently inside the Linux kernel.

Instead of relying only on traditional iptables rules, Cilium can use workload identity, labels, and eBPF maps to make policy decisions close to the network path.

The general flow looks like this:

Pod starts
   ↓
Kubernetes labels are assigned
   ↓
Cilium maps pod labels to security identity
   ↓
Policy is evaluated against that identity
   ↓
Allowed traffic passes
   ↓
Denied traffic is dropped
   ↓
Hubble can observe the flow

This identity-based model is powerful because pod IPs are temporary, but workload identity through labels is more stable.

In an AI platform, your training jobs, inference services, vector databases, and feature services may scale up and down frequently. If your policy depends only on IP addresses, it becomes fragile. If your policy depends on labels and identities, it becomes much easier to manage.

L3, L4, and L7 Policy Explained

L3 Policy: Who Can Talk to Whom?

Layer 3 policy controls communication based on source and destination identity or IP.

Example:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-api-to-vector-db
  namespace: ai-prod
spec:
  endpointSelector:
    matchLabels:
      app: vector-db
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: rag-api

This allows the rag-api workload to talk to the vector-db workload.

AI scenario:

Your RAG application should access the vector database, but your frontend pod should not directly access it.

L4 Policy: Which Port and Protocol?

Layer 4 policy controls communication based on TCP/UDP ports.

Example:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-rag-to-vector-db-port
  namespace: ai-prod
spec:
  endpointSelector:
    matchLabels:
      app: vector-db
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: rag-api
      toPorts:
        - ports:
            - port: "6333"
              protocol: TCP

This allows rag-api to access vector-db only on TCP port 6333.

AI scenario:

If you are using a vector database such as Qdrant, Milvus, Weaviate, or similar systems, only approved AI services should access the database port.

L7 Policy: What Exactly Can Be Called?

Layer 7 policy controls application-level behavior.

For HTTP, it can filter based on:

• Method
• Path
• Host
• Headers, depending on policy support and configuration

Example:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: restrict-model-api-path
  namespace: ai-prod
spec:
  endpointSelector:
    matchLabels:
      app: model-gateway
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: rag-api
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "POST"
                path: "/v1/inference"
              - method: "GET"
                path: "/health"

This allows:

• POST /v1/inference
• GET /health

But blocks other paths such as:

• /admin
• /debug
• /metrics
• /internal/config

For AI workloads, this is very valuable because model serving platforms often expose operational endpoints that should not be accessible from every service.

DNS and FQDN-Based Egress Policy

AI workloads often need to call external services.

Examples:

• api.openai.com
• huggingface.co
• storage.googleapis.com
• s3.amazonaws.com
• pypi.org
• docker.io
• model registries
• SaaS observability tools

Allowing unrestricted internet access is dangerous.

Cilium supports DNS-based policies and FQDN-based egress controls. Cilium’s DNS policy documentation explains that DNS-based policies can be used to control egress access to services outside the cluster, including wildcard domain patterns and combinations of DNS, port, and L7 rules. (Cilium Documentation)

Example:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-only-approved-ai-egress
  namespace: ai-prod
spec:
  endpointSelector:
    matchLabels:
      app: embedding-service
  egress:
    - toEndpoints:
        - matchLabels:
            k8s-app: kube-dns
            io.kubernetes.pod.namespace: kube-system
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
          rules:
            dns:
              - matchName: "api.openai.com"
              - matchName: "huggingface.co"
    - toFQDNs:
        - matchName: "api.openai.com"
        - matchName: "huggingface.co"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

This policy allows the embedding service to resolve and connect only to approved AI-related domains over HTTPS.

Why this matters:

If a compromised AI pod tries to send data to an unknown external domain, the policy can block it.

Default Deny: The Foundation of Zero Trust

A common mistake in Kubernetes networking is to allow everything by default.

For production AI workloads, a better approach is:

Deny by default, allow only what is required.

Example default deny ingress:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: ai-prod
spec:
  endpointSelector: {}
  ingress: []

Example default deny egress:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: default-deny-egress
  namespace: ai-prod
spec:
  endpointSelector: {}
  egress: []

After applying default deny, you create specific allow policies.

For AI workloads, this is useful because every component gets only the communication path it needs:

frontend → rag-api
rag-api → vector-db
rag-api → model-gateway
model-gateway → model-runtime
training-job → object-storage
embedding-service → approved external API

Everything else is blocked.

That is how you move from “network is open” to “network is intentional.”

Practical AI Workload Architecture

Consider this AI platform:

User
 ↓
Frontend
 ↓
RAG API
 ↓
Vector Database
 ↓
Model Gateway
 ↓
Model Runtime
 ↓
GPU Node

Additional dependencies:

Training Job → Object Storage
Training Job → Model Registry
Inference API → Observability Backend
Embedding Service → External LLM API

Without network policy, any compromised pod may try to access:

• Vector database.
• Model registry.
• Object storage.
• Metadata service.
• Internal APIs.
• External internet.
• Observability credentials.
• Training data.

With Cilium Network Policy, you can design precise controls:

AI ComponentShould AccessShould Not AccessFrontendRAG APIVector DB, model runtime, object storageRAG APIVector DB, model gatewayCloud metadata, training bucketsTraining JobObject storage, model registryFrontend, user-facing APIModel RuntimeModel gateway, telemetryInternetEmbedding ServiceApproved external embedding APIUnknown domainsObservability AgentMetrics/logs/traces backendBusiness data stores

This is the type of segmentation required for serious AI platforms.

Example: Securing a RAG Application with Cilium

Let us assume a RAG application has these components:

frontend
rag-api
vector-db
embedding-service
model-gateway

Step 1: Deny Everything by Default

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: default-deny
  namespace: ai-prod
spec:
  endpointSelector: {}
  ingress: []
  egress: []

Step 2: Allow Frontend to RAG API

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: frontend-to-rag-api
  namespace: ai-prod
spec:
  endpointSelector:
    matchLabels:
      app: rag-api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "POST"
                path: "/query"
              - method: "GET"
                path: "/health"

Step 3: Allow RAG API to Vector Database

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: rag-api-to-vector-db
  namespace: ai-prod
spec:
  endpointSelector:
    matchLabels:
      app: rag-api
  egress:
    - toEndpoints:
        - matchLabels:
            app: vector-db
      toPorts:
        - ports:
            - port: "6333"
              protocol: TCP

Step 4: Allow RAG API to Model Gateway

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: rag-api-to-model-gateway
  namespace: ai-prod
spec:
  endpointSelector:
    matchLabels:
      app: rag-api
  egress:
    - toEndpoints:
        - matchLabels:
            app: model-gateway
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "POST"
                path: "/v1/inference"

Step 5: Allow Embedding Service to Approved External API

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: embedding-service-egress
  namespace: ai-prod
spec:
  endpointSelector:
    matchLabels:
      app: embedding-service
  egress:
    - toEndpoints:
        - matchLabels:
            k8s-app: kube-dns
            io.kubernetes.pod.namespace: kube-system
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
          rules:
            dns:
              - matchName: "api.openai.com"
    - toFQDNs:
        - matchName: "api.openai.com"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

Now the embedding service can call only the approved external API.

Why This Is Important for AI Workload Management

1. Protecting Sensitive Training Data

Training jobs often access large datasets from object storage.

If a training pod is compromised, it may try to exfiltrate data to an external endpoint.

Cilium policies can restrict the job to:

• Approved object storage endpoints.
• Approved model registry.
• Approved telemetry endpoint.
• No arbitrary internet access.

This reduces data leakage risk.

2. Protecting Vector Databases

Vector databases may contain embeddings generated from internal documents, customer data, knowledge bases, or proprietary content.

Even if embeddings are not raw documents, they can still represent sensitive business knowledge.

Network policy can ensure only approved services access the vector database.

Example:

Allowed:
rag-api → vector-db

Denied:
frontend → vector-db
training-job → vector-db
unknown-pod → vector-db

This protects the RAG backend from accidental or malicious access.

3. Controlling External LLM API Access

Many AI applications call external LLM providers.

Without egress control, any pod could potentially call external services and leak prompts, context, or documents.

With Cilium FQDN policies, you can allow only approved domains and ports. Cilium specifically documents DNS-based controls for external services and supports matching DNS names and patterns for egress policy design. (Cilium Documentation)

This is important for governance, compliance, and cost control.

4. Reducing Blast Radius During Incidents

In incident response, the most important question is:

If this pod is compromised, what else can it reach?

Network policy reduces the blast radius.

A compromised frontend should not reach:

• Model registry.
• Kubernetes API.
• Cloud metadata service.
• Vector database.
• Training data bucket.
• Internal admin endpoints.

Cilium policies make lateral movement harder.

5. Supporting Platform Engineering Standards

Platform teams can create reusable policy templates for AI workloads.

For example:

• Default deny namespace policy.
• Allow DNS.
• Allow observability.
• Allow approved model registry.
• Allow approved object storage.
• Deny metadata service.
• Restrict model runtime access.
• Restrict vector database access.

This helps teams move faster without sacrificing security.

Observability: Debugging Network Policy with Hubble

Network policy is powerful, but it must be observable.

Cilium integrates with Hubble, which provides visibility into network flows. This is extremely useful when debugging why traffic is allowed or denied.

For an SRE, this helps answer:

• Which pod tried to connect?
• Which destination was accessed?
• Was the traffic allowed or dropped?
• Which policy affected the traffic?
• Which DNS name was resolved?
• Which HTTP path was requested?

This is especially useful in AI platforms where workloads are dynamic and dependencies are complex.

Example debugging mindset:

Problem:
RAG API cannot connect to vector database.

Check:
1. Is default deny active?
2. Does RAG API have correct labels?
3. Does vector DB have correct labels?
4. Is the port correct?
5. Is namespace selector required?
6. Is DNS allowed?
7. What does Hubble show?

Policy without observability can become guesswork. Policy with Hubble becomes operationally manageable.

Common Design Patterns for AI Workloads

Pattern 1: Namespace-Level Default Deny

Apply this to every production AI namespace.

endpointSelector: {}
ingress: []
egress: []

Then open only required flows.

Pattern 2: Separate Training and Inference Traffic

Training and inference workloads should not have the same network permissions.

Training may need:

• Object storage.
• Dataset registry.
• Experiment tracking.
• Model registry.

Inference may need:

• Model runtime.
• Feature store.
• Telemetry.
• Limited API access.

Do not reuse the same policy for both.

Pattern 3: Restrict Model Registry Access

Only CI/CD pipelines and training jobs should push models.

Inference workloads may only pull models.

This prevents accidental or unauthorized model changes.

Pattern 4: Restrict Vector Database Access

Only RAG services should access vector databases.

Frontend applications should not directly query vector DBs.

Pattern 5: Restrict External LLM Calls

Only approved workloads should call external LLM APIs.

Use DNS/FQDN-based egress control.

Pattern 6: Block Cloud Metadata Access

Use a cluster-wide policy to deny access to cloud metadata service.

This reduces credential theft risk.

Pattern 7: Allow Observability Explicitly

AI workloads should send metrics, logs, and traces to approved observability systems.

But they should not communicate with every monitoring endpoint freely.

Best Practices for Cilium Network Policy

1. Start with Visibility Before Enforcement

Before applying strict policies, observe current traffic.

Use Hubble to understand real communication paths.

Then convert observed flows into intentional policies.

2. Use Labels Carefully

Cilium policies depend heavily on labels.

Bad labels create bad policies.

Use consistent labels such as:

app: rag-api
team: ai-platform
environment: prod
data-classification: confidential
component: inference

Good labeling is the foundation of good policy.

3. Prefer Workload Identity Over IP Addresses

Pod IPs change frequently.

Labels and identities are more stable.

Use fromEndpoints and toEndpoints wherever possible.

4. Use Default Deny in Production

Default allow is risky.

Default deny is safer and more predictable.

5. Separate Ingress and Egress Policies

Ingress controls who can reach the workload.

Egress controls what the workload can reach.

For AI workloads, egress is especially important because data exfiltration usually happens outbound.

6. Be Careful with Wildcards

FQDN wildcard policies are useful, but dangerous if too broad.

For example:

matchPattern: "*.example.com"

This may allow more than expected.

Use exact matchName wherever possible.

7. Test Policies Before Production

Network policy mistakes can break applications.

Test in lower environments.

Roll out gradually.

Use observability to validate.

8. Create Reusable Policy Templates

Platform teams should create standard templates for:

• RAG applications.
• Training jobs.
• Inference services.
• Batch jobs.
• GPU workloads.
• Observability agents.
• External API clients.

This improves governance and developer experience.

Where Cilium Network Policy Helps SREs

For SREs, Cilium Network Policy is not only a security feature. It is also a reliability tool.

It helps with:

• Reducing incident blast radius.
• Preventing accidental dependency access.
• Making service communication explicit.
• Improving auditability.
• Supporting zero-trust networking.
• Reducing noisy and unexpected traffic.
• Debugging network flows with Hubble.
• Protecting critical AI infrastructure.

In AI platforms, reliability and security are tightly connected. A misconfigured network can cause model downtime, data leakage, high cloud bills, or unreliable inference paths.

Where Cilium Network Policy Helps DevOps and Platform Engineers

For DevOps and Platform Engineers, Cilium policies can become part of the platform contract.

You can manage them through GitOps:

Policy YAML → Git → Pull Request → Review → Argo CD → Kubernetes → Cilium Enforcement

This gives teams:

• Version control.
• Peer review.
• Audit history.
• Rollback capability.
• Standardized security patterns.
• Repeatable AI workload onboarding.

This is very important when multiple AI teams deploy workloads into shared Kubernetes clusters.

Where Cilium Network Policy Helps AI Engineers

AI Engineers may not always think deeply about network security, but their applications depend on it.

Cilium policies help AI Engineers by making the runtime safer:

• RAG apps can safely access vector DBs.
• Training jobs can access only required datasets.
• Inference APIs can expose only required endpoints.
• External LLM calls can be controlled.
• Model artifacts can be protected.
• Sensitive embeddings can be isolated.

This allows AI Engineers to focus on model quality while the platform enforces safe boundaries.

Real-World Scenario: Preventing Data Exfiltration from an AI Pod

Imagine an AI document analysis service.

It processes internal PDFs, extracts embeddings, stores them in a vector DB, and calls an LLM API for summarization.

Without egress policy:

document-analyzer → any external domain

If compromised, the pod could send internal documents to an attacker-controlled endpoint.

With Cilium policy:

document-analyzer → vector-db
document-analyzer → approved-llm-api.com
document-analyzer → observability-backend
document-analyzer → everything else denied

This changes the security posture completely.

The workload still functions, but the risk is reduced.

Real-World Scenario: Protecting GPU Model Runtime

GPU workloads are expensive and critical.

A model runtime should not receive traffic from every pod.

Only the model gateway should call it.

Allowed:
model-gateway → model-runtime

Denied:
frontend → model-runtime
debug-pod → model-runtime
training-job → model-runtime
unknown-service → model-runtime

This protects GPU-backed inference from abuse, accidental overload, and unauthorized access.

Real-World Scenario: Controlling Cost in AI Platforms

AI workloads can be expensive.

A compromised or misconfigured service may call paid external APIs repeatedly.

Network policies can restrict which workloads are allowed to call paid APIs.

Example:

Only embedding-service can call external embedding API.
Only model-gateway can call external LLM API.
Batch jobs cannot directly call paid inference APIs.

This helps control cost and prevents surprise bills.

Important Pitfalls to Avoid

Pitfall 1: Forgetting DNS

If you apply egress default deny, DNS may break.

Applications need DNS access to resolve service names and external domains.

Always allow DNS intentionally.

Pitfall 2: Wrong Labels

A policy is only as good as the labels it selects.

If labels are missing or inconsistent, traffic may be blocked unexpectedly.

Pitfall 3: Overusing Broad Rules

Avoid rules like:

toCIDR:
  - 0.0.0.0/0

This defeats the purpose of egress control.

Pitfall 4: Not Testing L7 Rules

L7 policies are powerful, but they must be tested carefully.

A wrong path or method can break production traffic.

Pitfall 5: Treating Policy as One-Time Work

Network policy must evolve with the application.

Every new dependency should trigger a policy review.

Recommended Rollout Strategy

For production AI workloads, I recommend this rollout approach:

Phase 1: Observe

Use Hubble to understand current traffic.

Identify:

• Internal dependencies.
• External dependencies.
• DNS queries.
• Unexpected flows.
• Sensitive paths.

Phase 2: Document

Create a communication matrix.

Phase 3: Enforce Namespace Default Deny

Start with non-production.

Apply default deny.

Then add allow policies.

Phase 4: Add L7 Controls

Restrict HTTP methods and paths for sensitive services.

Phase 5: Add FQDN Egress Controls

Restrict external AI API calls.

Phase 6: Automate with GitOps

Store policies in Git.

Review changes through pull requests.

Deploy through Argo CD or another GitOps tool.

Phase 7: Monitor Continuously

Use Hubble and observability tools to detect denied flows, unusual traffic, and policy drift.

Final Thoughts

Cilium Network Policy is not just a Kubernetes security feature.

For AI workloads, it becomes a governance, reliability, cost-control, and platform engineering capability.

As AI systems become more connected, the network becomes one of the most important control planes. Your AI workload may be powerful, but if its network path is open and uncontrolled, it becomes a risk.

Cilium helps us move from this:

Every pod can talk to everything.

To this:

Every workload can talk only to what it needs.
Every external call is intentional.
Every sensitive service is protected.
Every denied flow is observable.

For SREs, DevOps Engineers, Platform Engineers, and AI Engineers, learning Cilium Network Policy is not optional anymore. It is becoming a core skill for building secure, reliable, and production-grade AI platforms.