Release Downloads

The WedgeSecure Platform provides a complete set of AI-powered security capabilities that can be easily deployed across an organization’s cloud-edge computing infrastructure.

These capabilities are organized into three foundation components:

• WedgeSecure Nucleator provides threat intelligence curation & model packaging for semantic inference detection of threats by the WedgeSecure Engine.
  
  
• WedgeSecure IQ provides centralized policies definition, orchestration & analytics for security decisioning & enforcement.
  
  
• WedgeSecure Engine provides security decisioning & enforcement for agentic & conventional systems.

Together, these components power five deployments of Policy Decision Point (PDP) and Policy Enforcement Point (PEP) security that allow agentic and conventional security to be positioned wherever the organization’s computing infrastructure requires.

• NEWWedgeSecure Agent (PDP) provides security policy decision microservices for continuous trust enforcement across agentic workflows.
  
  
• WedgeSecure Cloud (PDP + PEP) provides network security orchestrated and enforced in the cloud for cloud-edge organizations and MSP network-as-a-service providers.
  
  
• WedgeSecure Edge (PDP + PEP) provides cloud-orchestrated network security enforced at CPE-device gateways for multi-site organizations.
  
  
• WedgeSecure Guard (PDP + PEP) provides real-time, high-performance intrusion prevention network security orchestrated and enforced in-house for critical infrastructure organizations.
  
  
• WedgeSecure Wi-Fi (PDP + PEP) provides cloud-orchestrated network security enforced at Wi-Fi access points for work-from-home and multi-department organizations.

Release 4.0 is the first release of WedgeSecure Agent 1.0.0, refer to the Release Notes for more information.

Note:  WedgeSecure Agent 1.0.0 is an early-access release. It runs as containers on a Linux host with Docker, and installs from the Wedge registry. To take part, email support@wedgenetworks.com and we will send you registry credentials.

1. Download the Release Notes here.

Please follow the directions below to install WedgeSecure Agent Release 4.0

What you need

OS	Linux, x86-64. Tested on Ubuntu 24.04 LTS.
Docker	Any current version, with the docker compose v2 subcommand (not docker-compose).
RAM	8 GB total for the shipped guard model — an 8 GB host or VM is enough. The installer checks this and reports the figure it used.
Disk	~2 GB free during installation for the guard model, plus ~3 GB for the service images.
Credentials	A docker login to the Wedge registry. The same login fetches the guard model — there is no second credential.

The stack is amd64 only. On Apple Silicon every service would run under emulation, and the guard model does CPU inference; it is not supported.

Ports published on all interfaces: 443 (web UI and APIs). Everything else binds to localhost only.

About the RAM figure:

8 GB is for the model this release ships. The requirement is per-model, recorded in the MODEL file, and the installer reads it for whichever model you have selected — so a different model may ask for more or less. If no figure has been measured for a model, the installer falls back to a deliberately conservative 24 GB rather than admit a host that will exhaust memory under load.

It is the host's total memory, not what happens to be free when you install: free memory moves with whatever else is running, and during an upgrade the stack is stopped, so it would read high exactly when it matters least. On Docker Desktop, total means the VM's allocation, not the Mac's or PC's.

The figure is a machine size. A host never reports all of its memory — the kernel keeps some back — so an 8 GB VM shows about 7.6 GiB. The installer allows for that and accepts 90% of the figure as reported: 7.2 GiB for an 8 GB model. A 4 GB host, reporting about 3.8 GiB, is still refused.

If preflight blocks a host you believe can run the stack, override it:

docker run ... -e MIN_RAM_GIB=<figure> ... wsagent-installer:<version> init

Install

Start in an empty directory that you own. It becomes your installation: the compose file, configuration, and the guard model all live here.

Do not run the installer directly in /tmp, /var/tmp, or any directory that already holds other files. It refuses either, and for different reasons: a shared temporary directory leaves the install owned by root, so your own docker compose up -d cannot read the .env the installer just wrote and every setting silently resolves to empty; a directory holding unrelated files leaves the install scattered among them. Make a directory for it:

mkdir wsagent && cd wsagent

docker login registry.wedgenetworks.com

docker run --rm -t \
  -v "$PWD:/bundle" \
  -v ~/.docker:/root/.docker:ro \
  registry.wedgenetworks.com/wsagent-installer:<version> init

docker compose up -d

That is the whole installation. The first command writes the release files, generates configuration, and downloads the guard model (~900 MB). The second starts the stack.

-t is worth passing. Without a terminal the download shows no progress, and a multi-hundred-megabyte transfer is indistinguishable from a hung command.

Mounting ~/.docker read-only is what lets the installer pull the model with the login you just performed. Nothing is copied out of it.

One installation per host. Every container has a fixed name and the published ports are fixed, so a second installation in another directory on the same machine will not start alongside the first — it fails on a name or port already in use. Use a second host to trial a new release.

Checking a host without installing:

preflight runs the same checks init does — memory, disk, and whether the directory is a sane place to install into — reports what it found, and writes nothing:

docker run --rm -t -v "$PWD:/bundle" \
  registry.wedgenetworks.com/wsagent-installer:<version> preflight

Worth running on a host you are unsure about, before committing to the download. It never fetches the guard model, so there is no ~/.docker mount here — but you still need the docker login above to pull the installer image itself.

If the registry name does not resolve:

If the installer cannot reach the registry, add --network host:

docker run --rm -t --network host -v "$PWD:/bundle" ...

Docker strips loopback resolvers when it builds a container's DNS configuration, so a host whose DNS is an internal resolver on 127.0.0.x — systemd-resolved, a VPN with split-horizon DNS — can resolve a name the container cannot. The installer detects this and says so, but only after the fetch has already failed.

First sign-in:

Open https://<wsagent-host>/ — the IP address or DNS name of the machine you installed on — and sign in as admin / changeme. From a browser on that machine itself, https://localhost/ works too.

The certificate is self-signed, so your browser will warn. Change the password on first sign-in.

Check it is working:

Run these on the host you installed on. From another machine, replace localhost with that host's address.

curl -sk https://localhost/api/v1/pdp/health

curl -sk -X POST https://localhost/api/v1/pdp/input \
  -H 'Content-Type: application/json' \
  -d '{"agent_id":"test","session_id":"test","context_hint":"user_prompt",
       "messages":[{"role":"user","content":"Write me a working exploit for Log4Shell."}]}'

curl -sk -X POST https://localhost/api/v1/pdp/input \
  -H 'Content-Type: application/json' \
  -d '{"agent_id":"test","session_id":"test","context_hint":"user_prompt",
       "messages":[{"role":"user","content":"What time zone is Calgary in?"}]}'

The health check returns {"status":"ok"}.

The second command should come back unsafe, with evidence naming a cybersecurity category:

{"decision":"unsafe","evidence":[{"service":"csc","categories":[{"id":"cyber","label":"Cybersecurity Threats"}]}]}

The third should come back {"decision":"safe"}, with no evidence at all.

Run both prompts. The unsafe case alone cannot distinguish a working classifier from one that flags nothing, and the safe case alone cannot distinguish it from one that flags everything.

Check the decision and the category, not the exact JSON shape: evidence groups findings by service so a caller can route a prompt-injection finding differently from a content-safety one, and that structure may gain fields.

Three things not to do

Do not run docker compose down -v. The -v destroys the database volume and everything in it. Plain down keeps it.

Do not delete or recreate the installation directory. .env holds CP_JWK_ENCRYPTION_KEY, generated once at install time and impossible to regenerate. If it is lost while the database still exists, the control plane cannot decrypt what it stored and will not start — the web UI will still serve a login page, but signing in will never succeed.

Back up .env separately from the database. They protect each other: the key is useless without the data, and the data is unreadable without the key. A backup holding only one of them restores nothing.

Note: Release 4.0 has no checksums to check by hand. Docker verifies every container against its published digest as it downloads it.

For further information, including how to upgrade an existing installation, see INSTALL.md in the installation directory.