Package Traffic Controller (PTC)

Overview

Even with Artifactory deployed as their artifact management backbone, developers and AI coding agents routinely bypass it by pulling packages directly from public registries. This creates a dual problem: a system of record that is structurally incomplete — making compliance audits unreliable — and proactive security policies (JFrog Curation) that apply only to a fraction of actual traffic.

JFrog Package Traffic Controller (PTC) solves this at the network layer. PTC is a network-level package proxy that integrates with enterprise SASE infrastructure (currently Zscaler Internet Access) to automatically intercept all outbound package requests — npm, PyPI, Docker, Hugging Face, and more — and transparently redirect them through Artifactory, where JFrog Curation inspects and enforces policy before serving the package. Developers and agents run the same commands they always have; nothing changes for them.

The result is a complete, auditable software supply chain that covers 100% of developer and agentic traffic: Curation policies that fire universally rather than selectively, and every download logged, policy-enforced, and recorded in Artifactory as the authoritative system of record.

The technical entry point is the package-reroute service (Router path /package-reroute, REST API under /artifactory/api/package-reroute/). Any process on a configured workstation — with ZCC, the trust store, and ZIA policies in place — is governed the same way, whether it originates from a human developer or an AI coding agent.

Public vs private packages (important)

Public packages (intended use): PTC is designed for public packages from public registries.

What the redirect does not carry: SASE providers send clients to Artifactory without each developer’s or agent’s personal registry credentials on that first hop. The entry path is anonymous relative to Artifactory (per your Package Reroute and virtual configuration). If an artifact requires the package manager to authenticate as that user to the public registry hostname (private npm scopes, org-only feeds, token-gated metadata, and similar cases), relying only on the redirect from the public registry URL will not supply those credentials.

How Artifactory reaches the upstream: Authentication from Artifactory to the public registry is configured on the remote repository (stored tokens, user/password, and so on). That is not the same as the redirect carrying the developer’s npm token. The remote’s settings govern whether Artifactory can proxy and cache from the upstream when the registry requires authentication. In practice, PTC traffic is anonymous inbound, so placing high-privilege upstream credentials on that remote is often not recommended (shared secret, broad access through anonymous entry)—but organizations may still choose to do so where policy and risk acceptance allow.

Private packages (what to do instead): For packages that require client-presented auth to the registry, point the package manager at your Artifactory virtual URL and configure client-side tokens (for example .npmrc or pip config)—do not depend on the PTC redirect alone.

Supported Package Types (GA)

The following ecosystems are in scope for general availability. Exact client versions and edge cases can vary by release—confirm entitlements and the current matrix with your JFrog account team.

• npm — supported clients: npm, pnpm, and yarn
• Python (PyPI) — supported clients: pip, pipenv, Poetry, and uv
• Docker / OCI — container images and trust configuration; JFrog-validated engines, CLIs, and tools are listed under Docker / OCI, Hugging Face, and other types. Podman is not supported for PTC in this documentation.
• Hugging Face — see Docker / OCI, Hugging Face, and other types

Supported workstation operating systems

• Windows
• macOS
• Linux

Install scripts, certificate placement, and environment variables are maintained per OS in the repository scripts/ README; use that README for version-specific notes.

Supported SASE / edge security

Today, PTC is integrated with Zscaler Internet Access (ZIA) (with Zscaler Client Connector on the workstation). Additional SASE vendors may be supported over time; availability and roadmap should be confirmed with your JFrog account team rather than assumed from this document.

How It Works

sequenceDiagram
    participant Dev as DeveloperMachine_ZCC
    participant ZIA as Zscaler_ZIA
    participant AF as JFrog_Artifactory
    participant Repo as NPM_Repository
    participant Cur as CurationEngine
    participant Pub as PublicRegistry

    Dev->>ZIA: npm install GET registry.npmjs.org/package
    ZIA->>ZIA: SSL Inspection and URL Match
    ZIA-->>Dev: HTTP 307 Redirect to Artifactory
    Dev->>AF: Follow redirect to /package-reroute
    AF-->>Dev: Redirect to NPM Repository
    Dev->>Repo: Request package
    Repo->>Cur: Check curation policies
    alt Package Approved
        Cur-->>Repo: Approved
        Repo->>Pub: Fetch package
        Pub-->>Repo: Return package
        Repo-->>Dev: Package delivered
    else Package Blocked
        Cur-->>Dev: Policy violation error
    end

The sequence diagram illustrates the path when JFrog Curation is enabled on the remote that resolves the package. If Curation is not enabled for that repository, the Repo → CurationEngine steps and the approve/block branch do not occur.

Step-by-Step Flow

1. Request: The developer runs npm install express. The package manager sends a GET request to https://registry.npmjs.org/express.
2. Interception: ZCC routes the request through Zscaler. ZIA performs SSL inspection on the HTTPS traffic using the Zscaler CA certificate installed on the developer's machine.
3. URL Match: ZIA checks the destination URL against the custom URL category (JFrog_Target_Registries). The URL registry.npmjs.org matches.
4. Redirect: ZIA blocks the direct request and returns an HTTP 307 Temporary Redirect to your Artifactory /package-reroute endpoint. Zscaler appends the original destination URL as the percent-encoded url query parameter—for example:

<YOUR_ARTIFACTORY_URL>/package-reroute?url=https%3A%2F%2Fregistry.npmjs.org%2Fexpress

(The url value is percent-encoded in real redirects and in correct curl tests—see Step 6: Verify the Redirect Endpoint.)

5. Package-reroute Router endpoint: The JFrog Router receives the request at /package-reroute, parses the query parameter, and issues another redirect to the appropriate virtual repository in Artifactory.
6. Virtual or Remote Repository Resolution: The virtual/remote repository resolves the request through its configured remote repository.
7. Curation Check (only if enabled for this repository): The Curation Engine and JFrog Catalog are involved only when JFrog Curation is enabled on the remote repository (or curated path) that actually resolves the package. In that case, before the remote fetches from the public registry, Curation evaluates the request against your policies—a metadata-only check (sub-millisecond). If Curation is not enabled for that repository, this step is skipped and no Catalog policy gate runs for that request.
8. Result:
   • Curation on, approved: The remote repository fetches the package from the public registry, caches it locally, and returns it to the developer via the virtual repository. If Compliant Version Selection (CVS) is enabled in Curation, the version delivered can be a policy-compliant choice that is not the latest upstream release (for example the highest version that passes policy within a semver range when the newest release is blocked). Exact behavior follows your CVS / fallback settings; requests for a version that policy rejects may still fail instead of substituting. For product details, see Compliant Version Selection.
   • Curation on, blocked: The developer receives a policy violation error. The package is never downloaded.
   • Curation off for that remote: Resolution and caching proceed without a Curation Catalog check (other Artifactory rules and settings still apply).

Scoped vs Unscoped Deployment

You can apply PTC to everyone who hits the configured registries, or limit who is affected by scoping Zscaler ZIA rules. Group-based scoping, rule construction, identity/group membership, and directory sync are Zscaler ZIA features—not something JFrog implements or can change in your tenant. For requests about how Groups work in ZIA, policy precedence, or troubleshooting Zscaler-side behavior, contact Zscaler support and documentation; JFrog supports Artifactory, Curation, and the redirect endpoint—not Zscaler’s admin console.

Rollout recommendation: JFrog recommends a gradual rollout using scoped rules first (pilot or departmental Groups), then expanding; see Gradual Rollout Recommendation. The ZIA Groups filter is the standard way to keep blast radius small until you are ready for organization-wide coverage.

Unscoped (Organization-Wide): All users' traffic matching the URL category is intercepted and redirected. SSL inspection and URL filtering rules apply globally (subject to your other ZIA policies).

Scoped (Group-Specific, ZIA): Both the SSL Inspection rule and the URL Filtering rule include a Zscaler Groups filter (e.g., "R&D"). This means:

Document Map

Frequently Asked Questions

This section provides answers to frequently asked questions about Package Traffic Controller (PTC).

Related Topics

• Deployment and Rollout
• Prerequisites and Installation Script
• Configure Artifactory for PTC