Getting Started
¶
What this is¶
Your workspace starts empty. Nothing appears until a scanner reports from your own
infrastructure. This page takes you from a new workspace to seeing your own AI applications:
connect a scanner, choose what it watches, and check that data arrives.
The scanner runs in your environment. It records AI traffic and the dependencies of your
applications and sends the results only to your workspace.
What you see on day one¶
- First sign-in. Welcome to AI Hypervisor asks for your role: Executive,
Security Engineer, Platform Engineer, Compliance or Developer. Pick one and
click Continue. The role only sets how Briefing is arranged. - Briefing shows No applications scanned yet and a Scanner deploy command box with
the Kubernetes commands. They already contain your workspace address and your scanner key. For
AWS ECS on EC2, AWS Fargate or a macOS endpoint, open Settings → Scanners — the Scanner
deploy command there has a tab for each. - Every other page stays empty until the scanner reports.
- Code and Mirroring are hidden from the sidebar by default. Turn them on in
Settings → Features.
To open Settings: click your name at the bottom of the sidebar, then Settings.
Connect a scanner¶
Choose where your AI applications run. The exact commands, with your values filled in, are in
Settings → Scanners under Scanner deploy command, in four tabs: Kubernetes,
AWS Fargate, AWS ECS on EC2 and macOS endpoint.
The commands contain your scanner key. Treat it as a secret.
Kubernetes¶
You need kubectl and helm connected to the cluster, and permission to run a privileged
DaemonSet.
The app's install block offers two ways — Helm (the key in a Kubernetes Secret) and GitOps
(ArgoCD) (see below). Each shows its own numbered steps; the steps here are the Helm ones.
Install into namespace. The Kubernetes namespace the scanner
itself runs in. higgs-system works on any cluster; change it only if your cluster keeps tools in
another namespace, and every command (and the GitOps Application) follows. It is not a name for the
cluster. Namespaces to scan is a different input: the namespaces your AI applications run in,
which the last step labels (step 5).
Cluster name (optional). What AI Hypervisor calls this cluster
everywhere — Infrastructure, the graphs, filters and reports — for example audit. Leave it empty
to keep the name the scanner detects (on many clusters there is none, and the app falls back to a
namespace or the cloud location). 1-63 characters: letters, digits, space, ., _, -. It is a
label only: renaming a cluster later (helm upgrade … --set clusterName=…, or a Git commit) never
splits or merges its data. Fargate and ECS take it as the CLUSTER_DISPLAY_NAME environment value.
-
Add the Helm repository:
helm repo add wallarm https://charts.wallarm.com && helm repo update -
Install the scanner. Copy this command from the app — it carries your workspace address and
keeps the key off the command line:
helm upgrade --install aih-scanner wallarm/aih-scanner --version <version> --set config.backendUrl="<your workspace>" --set existingSecret.name=aih-scanner-private-key
The chart creates the namespacehiggs-systemand runs one scanner pod on each node. -
Store the key in a Kubernetes Secret (copy it from the app too):
kubectl create secret generic aih-scanner-private-key -n higgs-system --from-literal=scanner-private-key="<your key>"
The pods start as soon as the Secret exists. A secret manager (Vault, External Secrets, Sealed
Secrets) can produce this Secret instead. -
Check the scanner is running:
kubectl get pods -n higgs-system. The pods should be
Running. -
Choose what to watch. The scanner records nothing until you opt a namespace in. Type the
namespaces your AI applications run in under Namespaces to scan; the app builds one command
per namespace, for examplekubectl label namespace payments higgs.scan=enabled.
The scanner re-reads labels every 60 seconds.
Monitor or Enforce. Put one of these labels on each namespace:
| Label | Mode | What it does |
|---|---|---|
higgs.scan=enabled |
Monitor | Records traffic, sessions and personal data. Never blocks anything. |
higgs.io/enforce=enabled |
Enforce | Everything Monitor does, plus blocking by your policies. |
Blocking needs the scanner's proxy. To use Enforce, turn on Enable blocking under step 2
before you copy the install command: it adds --set proxy.enabled=true and changes the opt-in
step to the Enforce label.
What works without a restart. Labeling a namespace never restarts anything, and never breaks
a running pod:
| Pods running before you labeled | Pods created after | |
|---|---|---|
| Discovery, sessions, personal data on HTTPS (OpenSSL, Go, Java, GnuTLS) | Yes, within a minute | Yes |
| Destinations and outbound requests of Rust apps using rustls | Yes, within a minute | Yes |
| Destination policy, kill session | Yes | Yes |
| Content-level policy on HTTPS (body inspection, redaction, prompt blocking) | After a restart | Yes |
A running pod does not trust the proxy's certificate, so the proxy passes its HTTPS through
without decrypting it until the pod restarts. Nothing breaks either way: a connection the proxy
cannot decrypt is passed through, and connection-level policy still applies.
Settings → Scanners shows, per app, what the proxy actually did with its HTTPS in the last
15 minutes (scanner 2.19.0 and later):
| Badge | Meaning | What to do |
|---|---|---|
| Content inspected | The proxy decrypted the app's HTTPS. Content-level policy applies. | Nothing. |
| Connection-level · N pods | The pods started before they were opted in, so they do not have the proxy's certificate. | Restart them (below). |
| Not inspected · N pods | The app's TLS library rejects the proxy's certificate even though the pod has it, for example a client that only trusts its own built-in roots or pins certificates. Its HTTPS is passed through. | A restart does not help; the pods are listed so you can check the client's trust settings. |
| Partly inspected | Some pods are decrypted, others reject the certificate. | As above, for the listed pods. |
| No HTTPS yet | The proxy has not seen an HTTPS connection from the app. | Nothing. |
To restart the pods that need it, either expand the app and click Restart to inspect content,
or in Registry click Adopt on the namespace. Both are rolling restarts of the Deployments,
StatefulSets and DaemonSets. You can also restart them yourself, for example
kubectl rollout restart deployment -n <your-namespace>.
Opting a namespace in sets its Pod Security level to privileged, because the scanner's agent
needs it.
Opt in from the app instead. A namespace whose pods call AI services appears under
Registry → Shadow even before you label it — the scanner reads cluster DNS for AI provider
domains. Click Monitor or Enforce on that namespace. It takes effect on the scanner's next
cycle. Revert removes it. When Supply Chain is empty and the scanner has seen a
namespace calling AI services, it offers the same two buttons for that namespace.
If your cluster's CoreDNS configuration is managed elsewhere (for example by GitOps), the
scanner's DNS logging change can be overwritten and Shadow stays empty. Label namespaces with
kubectl instead.
Kubernetes with GitOps (ArgoCD / Flux)¶
Git holds the chart version and values; the key never goes into Git. Settings → Scanners →
Kubernetes builds the complete ArgoCD Application — commit it as it is (scanner 2.17.3 and later).
-
Set Install into namespace if you keep the scanner somewhere other than
higgs-system. -
Pick the Key source: a Secret your tooling creates (
aih-scanner-private-key, key
scanner-private-key), the External Secrets Operator, the Vault Secrets Operator, Sealed Secrets
or the Vault agent injector. Fill in the names it asks for (your secret store, Vault path); the
copy button appears when the Application is complete. -
Commit the Application. What it sets, and why:
-gitops: true— every render is identical. The proxy CA, the internal tokens and the webhook
certificate are created once by a PreSync Job; the webhook writes its own CA into its
configuration. No cert-manager and no certificate values needed.
-namespace.create: falsewithsyncOptions: [CreateNamespace=true]and the
pod-security.kubernetes.io/enforce: privilegedlabel — the namespace must exist before that
Job runs.
- The in-cluster upgrader stays off: Git owns the version. -
Label the namespaces to scan (step 5 above) — in Git as well.
-
Upgrade by changing
targetRevisionin Git; Settings → Scanners shows GitOps-managed
scanners thetargetRevisionto set. -
Rotate the key in your secret manager; the scanners pick it up without a restart. Give each
cluster or team its own key (Settings → Scanners → Scanner keys → Add key) so one can be
rotated or revoked without touching the others.
Flux runs a real helm install, which can look objects up: it needs neither gitops: true nor
the namespace settings. Also settable: your own proxy CA (proxy.ca.existingSecret), your PKI for
the webhook (webhook.tls.certManager or webhook.tls.existingSecret), pod annotations and labels
(podAnnotations, podLabels), metadata on the key Secret (secret.annotations,
secret.labels) and extra env sources (extraEnvFrom).
AWS ECS on EC2¶
-
Copy the scanner task definition from the app. Replace the
<paste …>spot with your ECS
task execution role ARN. -
Register it and create the DAEMON service with the two commands shown. One scanner runs on
each instance; new instances are covered automatically. -
Opt applications in: add
"dockerLabels": { "higgs.scan": "enabled" }to each task
definition you want scanned.
Instances need an ECS-optimized Amazon Linux 2023 AMI and a security group that allows outbound
traffic. For production, move SCANNER_PRIVATE_KEY out of the task definition into AWS Secrets
Manager and reference it with secrets[].valueFrom.
AWS Fargate¶
Fargate has no hosts to run a scanner on, so the scanner runs as extra containers inside your
application's task.
-
Copy the containers JSON from the app into your application's ECS task definition.
-
Replace the two
<paste …>spots: your ECS task execution role ARN and your application's
container image. If your application does not listen on port8080, change8080in
AppPortsandportMappings. -
Register the task definition. Your service redeploys automatically.
Optional: to also scan dependencies for known vulnerabilities, merge the add-on shown in the app
("pidMode": "task" and the SYS_PTRACE capability). Skip it if your account does not allow
pidMode. Registry → Shadow onboarding does not apply to Fargate.
macOS endpoint¶
Records AI traffic from a Mac, for example a developer laptop.
-
Install the signed package your admin gives you:
sudo installer -pkg AIHDiscoveryHost.pkg -target / -
Open System Settings → Privacy & Security. Click Allow for the "Wallarm, Inc." system
extension, then allow it to filter network content. -
Point it at your workspace (copy the command from the app):
sudo defaults write /Library/Preferences/com.wallarm.aih BACKEND_URL "<your workspace>"
The Mac enrolls itself — no key or account to enter. It appears in your workspace within a
minute. Its AI calls show up in Traffic and Topology, and per person and program in
Egress (which only endpoints feed).
Check that data arrives¶
-
Open Settings → Scanners. Under Scanner Targets, the header shows how many scanner
daemons are online and how many applications they monitor. Each opted-in application is a
row; a new row shows No scan data yet until its first scan uploads. -
As the scanner detects your applications, they appear in Registry (agents, MCP servers,
LLMs, APIs, data sources) and Topology. After the first scan, their dependencies and known
vulnerabilities appear in Supply Chain. -
Traffic fills only when an application makes AI calls — LLM requests, MCP or tool calls.
An application that makes no AI calls has no sessions. -
Briefing fills once there is something to rank.
Most pages have an application dropdown at the right of the page title. All applications
shows everything; pick one application to see only its data. Applications are grouped by where
they run, for example Kubernetes ·
Nothing appears? Check, in this order:
-
The scanner pods are Running:
kubectl get pods -n higgs-system. -
The namespace carries the label:
kubectl get namespace <your-namespace> --show-labels. -
The scanner can reach your workspace address over outbound HTTPS.
Add more sources (optional)¶
- Source code. Turn on Code in Settings → Features, then connect your repositories
on the Code page. The switch shows the page; scanning also needs Code enabled for your
workspace deployment — if connected repositories stay Pending, ask Wallarm support. See
Code. - Cloud accounts. Turn on Mirroring in Settings → Features, then click
+ Add Account on the Mirroring page. See Mirroring. - Teammates. Open Settings → Data, click Team Members, type an address into
Invite by email, pick a role and click Invite.
Finding help¶
Every page has a ? icon next to its title. It opens the guide for that page. All guides are
listed in the documentation index.
Where to go next¶
- Registry — the inventory of what the scanner found.
- Traffic — every AI session, step by step.
- Briefing — what needs attention, ranked.
- Settings — scanners, features, team and workspace preferences.
How you get here¶
- The ? next to No applications scanned yet on Briefing.
- The ? next to Scanner deploy command in Settings → Scanners.