Securing LLM Access with Trusted Egress IPs

Access to most hosted LLM endpoints is protected by a shared API key coded into client configurations. API keys are straightforward to deploy but easy to share, leak, or exfiltrate — and with LLM inference compute being expensive, unauthorized usage can generate significant and unexpected costs.

This is both a security problem and a cost-governance problem.

Jamf's Network Relay combined with trusted egress IP restrictions addresses this gap with a zero-touch approach.

The Problem: API Keys Alone Aren't Enough

A typical hosted LLM deployment example:

The organization deploys a model (e.g., Llama 3, Mistral, or a fine-tuned variant) on internal infrastructure or within a cloud VPC (AWS, Azure, GCP).
An API endpoint is exposed — often OpenAI-compatible — that accepts requests authenticated with a shared API key.
The API key is distributed to clients via configuration profiles, MDM, environment variables, or developer documentation.

The problem is that API keys are static, long-lived secrets that are easy to leak:

A developer copies the key into a personal project or notebook.
The key is committed to a Git repository (even a private one).
An employee shares the key with an unauthorized colleague or contractor.
A device with the key configured is lost or compromised.

Once a key is in the wild, anyone with it can consume your LLM resources from any device, any network, anywhere. Given that LLM inference can cost anywhere from fractions of a cent to several dollars per request depending on the model and prompt length, unauthorized usage can generate substantial bills — or worse, expose sensitive internal data if the model has been fine-tuned on proprietary information.

Traditional mitigations like key rotation help, but introduce operational complexity and don't solve the fundamental issue:

The key alone cannot verify that the request originates from a trusted, managed device.

The Solution: Network Relay + Trusted Egress IP Lockdown

Jamf's Network Relay, built on Apple's native MASQUE protocol and Managed Device Attestation (MDA), enables organizations to restrict LLM endpoint access to verified, managed Apple devices — with zero end-user interaction required.

The architecture:

1. Traffic from Managed Devices Routes Through Jamf Security Cloud

When Network Relay is deployed via MDM, all traffic destined for your LLM endpoint's domain is automatically tunneled through Jamf's Security Cloud using encrypted MASQUE/HTTP3 tunnels. The device's identity is cryptographically verified using hardware-bound keys from the Apple Secure Enclave via Managed Device Attestation, so only genuine, company-managed devices can establish these tunnels.

2. Traffic Egresses via Known Jamf IP Addresses

Once traffic passes through the Jamf Security Cloud and policy evaluation, it exits (egresses) to the internet — and therefore to your LLM endpoint — from a known, deterministic set of Jamf IP addresses. These can be:

Shared egress IPs from one of Jamf's global data center regions.
Dedicated egress IPs that are uniquely assigned to your organization — providing two highly available public IPs per region that no other Jamf customer uses.

3. Your LLM Endpoint Restricts Access to Trusted IPs Only

With your traffic now arriving from a known and trusted set of IP addresses, you configure your LLM infrastructure to only accept connections from those Jamf egress IPs — rejecting all others. This is standard IP allowlisting applied at the network layer:

Cloud-hosted LLMs (AWS/Azure/GCP): Configure Security Groups, Network Security Groups, or firewall rules to only permit inbound HTTPS (TCP/443) from your Jamf egress IPs. See below for an example on AWS Bedrock Link to My Heading
On-premise LLMs: Configure your edge firewall or reverse proxy (e.g., nginx, HAProxy, Caddy) to only accept connections from the Jamf egress IP ranges.
API Gateway / LLM Proxy (e.g., LiteLLM, OpenWebUI): Many LLM gateway solutions support IP allowlisting at the application layer as an additional defense-in-depth measure.

The result: even if an API key is leaked, it is useless unless the request originates from a managed device routing through your Jamf Security Cloud tenant.

Why Network Relay

The key difference from traditional VPN-based IP lockdown is the zero-touch, zero-agent deployment model:

No app installation required. Network Relay is configured entirely via MDM configuration profiles deployed from Jamf Pro. There is no VPN client to install, no Jamf Trust app required for basic relay functionality, and no user login or activation step.
No user interaction. Once the relay profile is installed on a managed device, it activates automatically. The user does not see a VPN toggle, enter credentials for network access, or get interrupted. Traffic to the defined LLM domains is tunneled transparently.
Hardware-rooted device trust. Managed Device Attestation uses the Apple Secure Enclave to cryptographically prove that a device is genuine Apple hardware, managed by your organization's MDM, and has not been tampered with. This provides a stronger identity signal than software-only agents.
Per-domain precision. Unlike a full-tunnel VPN that routes all traffic, Network Relay operates on a per-domain basis. You define exactly which domains (e.g., llm.internal.yourcompany.com) should be tunneled through Jamf — leaving all other traffic unaffected. This minimizes performance impact and avoids the "all or nothing" tradeoff of legacy VPN architectures.
Works across Apple platforms. Network Relay is supported on macOS, iOS, iPadOS, and visionOS, and can be managed from a single configuration.

*N.b. It is also possible to use IP lock-down with Jamf's ZTNA solution on non-Apple Platforms.

Deployment Overview

The following steps outline the end-to-end configuration:

Step 1: Configure Egress in Jamf Security Cloud

In the Jamf Security Cloud (RADAR) console, navigate to Integrations > Access Gateways and either note your Shared egress IPs for your preferred region, or create a Dedicated Internet Gateway to receive two unique public IPs assigned exclusively to your organization.

For dedicated gateways, you can create multiple regional gateways and group them so that devices automatically use the nearest egress point based on their connection to the Jamf Security Cloud.

Step 2: Create an Access Policy for Your LLM Endpoint

Navigate to Policies > Access Policies and create a new policy:

Define your LLM endpoint's domain(s) (e.g., llm.yourcompany.com, api.ai.internal.yourcompany.com).
Set the routing to use your chosen egress gateway (shared or dedicated).
Configure the policy to apply to the appropriate device groups.

Step 3: Deploy the Network Relay Profile

Navigate to Devices > Activation Profiles and create or update your Network Relay activation profile:

Under Service Capabilities, ensure Zero Trust Network Access is selected.
Under Authentication, select Managed Device Attestation for zero-touch, passwordless activation.
Deploy the resulting configuration profiles to your managed devices via Jamf Pro.

Once deployed, devices will automatically begin routing traffic to your LLM domains through the Jamf Security Cloud.

Step 4: Lock Down Your LLM Endpoint to Jamf Egress IPs

On the LLM infrastructure side, restrict inbound access to only your Jamf egress IP addresses. Examples:

AWS Security Group:

Inbound Rule:
  Type: HTTPS (TCP 443)
  Source: <Jamf Egress IP 1>/32, <Jamf Egress IP 2>/32
  Description: Jamf Trusted Devices Only

nginx reverse proxy:

server {
    listen 443 ssl;
    server_name llm.yourcompany.com;

    # Only allow Jamf egress IPs
    allow <Jamf Egress IP 1>;
    allow <Jamf Egress IP 2>;
    deny all;

    location / {
        proxy_pass http://localhost:8080;  # Your LLM inference server
    }
}

Azure Network Security Group:

Inbound security rule:
  Priority: 100
  Source: <Jamf Egress IP 1>/32, <Jamf Egress IP 2>/32
  Destination port: 443
  Protocol: TCP
  Action: Allow

Inbound security rule:
  Priority: 200
  Source: Any
  Destination port: 443
  Protocol: TCP
  Action: Deny

Step 5: Validate and Monitor

From a managed device with the relay profile deployed, confirm that requests to your LLM endpoint succeed.
From an unmanaged device (or with the relay profile removed), confirm that requests are blocked.
Monitor access logs on your LLM infrastructure to verify that all inbound connections originate from your expected Jamf egress IPs.
Review connection logs in the Jamf Security Cloud Reports > Access section for visibility into which users and devices are accessing the LLM endpoint.

Extending to Managed LLM Services: AWS Bedrock

The same trusted egress IP approach applies beyond self-hosted models. If your organization uses Amazon Bedrock for managed LLM inference, you can enforce IP-based restrictions using AWS IAM policies with aws:SourceIp conditions — ensuring that only requests originating from your Jamf egress IPs can invoke Bedrock models.

Unlike self-hosted deployments where you control the network layer (Security Groups, firewalls), Bedrock is a fully managed AWS service. You don't configure inbound firewall rules on Bedrock itself. Instead, you attach IAM policies that deny model invocation unless the request comes from a trusted IP.

IAM Deny Policy: Restrict Bedrock Invocation by Source IP

Attach the following policy to the IAM users, roles, or groups that have Bedrock access. The explicit deny overrides any allow statements, ensuring Bedrock calls are blocked unless they originate from your Jamf egress IPs:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyBedrockUnlessTrustedIP",
            "Effect": "Deny",
            "Action": [
                "bedrock:InvokeModel",
                "bedrock:InvokeModelWithResponseStream"
            ],
            "Resource": "arn:aws:bedrock:*:*:model/*",
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": [
                        "<Jamf Egress IP 1>/32",
                        "<Jamf Egress IP 2>/32"
                    ]
                }
            }
        }
    ]
}

This policy allows all other Bedrock permissions (e.g., listing models, managing provisioned throughput) to function normally — it only restricts the inference invocation actions to trusted IPs. If your existing IAM policies already contain explicit DENY rules, you may need to add an explicit ALLOW statement for trusted IPs instead of relying on implicit allow.

Service Control Policy (SCP) for Organization-Wide Enforcement

If you want to enforce the IP restriction across all AWS accounts in your organization — not just individual IAM principals — apply it as an SCP in AWS Organizations:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnforceBedrockIPRestriction",
            "Effect": "Deny",
            "Action": [
                "bedrock:InvokeModel",
                "bedrock:InvokeModelWithResponseStream"
            ],
            "Resource": "*",
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": [
                        "<Jamf Egress IP 1>/32",
                        "<Jamf Egress IP 2>/32"
                    ]
                },
                "BoolIfExists": {
                    "aws:ViaAWSService": "false"
                }
            }
        }
    ]
}

The aws:ViaAWSService condition is included so that the deny does not inadvertently block Bedrock calls made by other AWS services on your behalf (e.g., a Lambda function invoking Bedrock within your VPC, Step Functions workflows calling Bedrock, or SageMaker notebooks using Bedrock for inference). It ensures the IP restriction only applies to direct API calls — which is exactly the path that end-user devices take through the Jamf relay.

Key Considerations for Bedrock

aws:SourceIp applies to direct API calls over the public internet. This is the expected path when traffic flows from a managed device → Jamf Security Cloud → Jamf egress IP → AWS Bedrock API endpoint.
VPC Endpoint access: If you also access Bedrock via a VPC endpoint, aws:SourceIp is not evaluated. Use aws:VpcSourceIp or VPC endpoint policies to control access in that path separately.
Bedrock cross-region inference: If you use cross-region inference profiles, ensure your policy Resource covers the relevant regions or use a wildcard as shown above.
Testing: Use the IAM Policy Simulator or make test InvokeModel calls from both a managed device (should succeed) and an unmanaged device (should receive AccessDenied) to validate the policy before broad deployment.

Defense in Depth: Layering IP Lockdown with API Keys

It's important to note that IP-based access restriction complements API key authentication — it does not replace it. The recommended posture is to layer both controls:

Layer	Control	What It Proves
Network	Jamf egress IP allowlist	Request originates from a managed, attested device
Application	API key / token	Request is authorized for the specific LLM service
(Optional) Identity	IdP integration / OAuth	Request is tied to a specific authenticated user

With this layered approach, an attacker would need to simultaneously possess a valid API key and be operating from a Jamf-managed, hardware-attested device — a significantly higher bar than either control alone.

Summary

Self-hosted LLMs represent a significant infrastructure commitment for organizations that need to control their data, costs, and AI supply chain. That commitment is undermined if access relies solely on shared API keys that can be leaked and used from any device on the internet.

Deploying Network Relay with trusted egress IP restrictions provides:

Cryptographic device trust rooted in Apple hardware attestation, not a software token or shared secret.
Zero-touch, zero-agent deployment with no VPN clients, no user interaction, and no activation steps.
Deterministic source IP addresses that enable straightforward IP allowlisting on any LLM infrastructure.
Per-domain routing precision that avoids the performance and privacy tradeoffs of full-tunnel VPNs.
Layered security that combines network-level device trust with application-level API authentication.

The net effect is that only trusted, managed devices can reach the LLM infrastructure, without requiring any change to end-user workflows.

Securing LLM Access with Trusted Egress IPs