Ask, see, and probe the network — from one chat.

NetBot is the conversational front door for diagnosing and (carefully) acting on PBFS's network. It does three things, and only those three.

1. Ask questions about the live network

   "Why is wesuite-prod getting 502s?" · "Who's been talking to the Private Endpoint at 10.100.48.x in the last hour?"
2. See network health at a glance

   WAF posture, top denied flows, DNS failures, firewall status — refreshed every 30 seconds.
3. Run real probes from real vantage points

   Ping, traceroute, DNS lookups, port scans, packet captures — from disposable VMs that already live on every VWAN-connected VNet. Every probe needs a human click.

Who it's for

What it isn't

• Not a configuration tool. You can't change firewall rules, NSGs, or DNS records from inside NetBot. Future admin actions will be gated behind a separate group with mandatory MFA and full audit; today, that surface doesn't exist.
• Not a replacement for Sentinel or Grafana for sustained monitoring. Use it for ad-hoc questions and event-driven probing.
• Not magic. It can be wrong. Treat the chat output as a senior engineer's first guess — verify before acting.

Sign in

Go to netbot.cloud.pyebarkerfs.com. You'll be redirected to Microsoft sign-in; use your PBFS account. You need to be a member of the sg-netbot-users Entra group — your manager or the platform team can add you. First sign-in takes about ten seconds; subsequent visits within an hour are silent.

Layout

NetBot has a header, a tab bar, and a content area. The header carries the wordmark on the left and a Help menu and Sign out link on the right. Tabs sit just below.

• Overview — default landing. Live network-health dashboard.
• Chat — conversational troubleshooting with the AI agent.
• Probes — form-driven probe execution under approval.

Overview is what loads first. It's the answer to "is anything on fire right now?" — refreshed every thirty seconds.

Top to bottom

• KPI row — four big-number cards: firewall status, App Gateways in Prevention mode, DNS failures in the last hour, probe VMs running.
• VWAN App Gateways — WAF Posture — every AG with its operational state, WAF mode (Prevention / Detection), and the WAF policy attached. Highlights gateways with no policy or in Detection-only mode.
• Top Denied at Firewall — top source IPs generating denies, and top destination IPs being denied to. Click a row to seed a chat question about it.
• Top WAF Hits by Client — top external client IPs and the AG hostname they're hitting most.
• DNS Health — count of NXDOMAIN responses plus the top failing FQDNs.
• Footer — last refresh timestamp and a "Refresh now" link.

Workflow · Are we under attack? Glance at the KPI row. If Top WAF Hits is dominated by a single client IP and that AG has been logging 4xx codes for five or more minutes, switch to the Chat tab and ask "summarize WAF blocks for that AG in the last 30 minutes."

Chat is where you ask. The agent reads logs, queries Resource Graph, and shows its work. It runs Claude Sonnet 4.6 via Azure AI Foundry, with about thirty tools wired into the live network.

What it can reach

• Resource Graph — list and find VMs, VNets, NSGs, App Gateways, public IPs, private endpoints.
• Azure Monitor & Log Analytics — firewall logs, WAF logs, AG access logs, NSG flow logs, DNS resolver logs.
• Topology — VNet peerings, route tables, effective routes, "find the VNet by CIDR," "which AG fronts which app."
• WAF & firewall policy — list rules, find rules, check what's enabled.
• Probes — propose ping, traceroute, DNS, TCP, port scan, HTTPS, and packet capture. These always need approval — see §5.

What you can do with it

• Follow-ups understand prior turns. "…and what about port 443 on the same target?" works.
• Conversation persists across page reloads. Click New chat in the tab toolbar to start fresh.
• Markdown and Mermaid. Network diagrams render inline when the agent thinks they help.
• File attachments. Paperclip accepts images (Vision reads screenshots and CLI captures) and packet captures (.pcap, .cap, .pcapng — analyzed via pcap_summary).
• Starter prompts appear on an empty chat — "Show me VWAN health," "Top WAF blocks last hour."

What it's good at

• "Why is <app> slow?" — walks the path: AG status → WAF mode → backend pool health → flow logs → probe-VM ping if needed.
• "Who's been talking to 10.100.X.Y?" — flow-log query joined with NSG and firewall context.
• "Summarize WAF blocks for tagquest-prod in the last 30 minutes." — aggregated rule hits + top clients.

What it's not yet good at

• Multi-step workflows that need "wait and check again in ten minutes." Sessions don't pause and resume mid-tool-chain. Use a probe instead.
• Anything that requires writing to Azure — not in scope.
• Speculative architecture decisions. It can describe state but won't recommend changes.

Probes are network tests run from disposable VMs that sit on every VWAN-connected VNet. They give you ground-truth reachability from a real source vantage — answering questions logs can't.

The catalog

How a probe runs — the human-in-the-loop gate

This is the most important thing to understand about NetBot.

1. You fill in a form.

   Target, port, source VM. The source VM is explicit so the probe runs from the network vantage you intend.
2. You click Submit.

   The form sends a natural-language prompt to the agent.
3. The agent proposes a probe.

   It reconstructs the command from a templated whitelist. You see the exact command before you click anything else.
4. An approval card appears.

   "NetBot wants to run a ping probe from net-test-plat-nonprod to 10.100.18.5 (count 4). Approve / Deny."
5. You click Approve.

   The probe runs — typically 30 to 90 seconds. Packet captures take their advertised duration plus a ~30 second flush.
6. The result appears.

   stdout, stderr, exit code, executed command. For pcaps: a Download .cap link and an Analyze capture button that ships the file into the embedded chat for summary.

The probe VMs

Twelve of them, named net-test-{env}-{slot}, one per VWAN-connected VNet across AVD, TagQuest, WeSuite, Workday, PAYG-routing, and Platform. Small Linux VMs (~$8/month each), deallocated by default, auto-stop after 30 minutes of idle. Approved probes auto-wake them in about sixty seconds.

Workflow · Can the AVD desktop reach SQL? Probes tab → Port scan → source net-test-avd-prod → target = SQL server private IP → ports 1433, 5432, 3389. Approve. The result tells you in thirty seconds whether ports are open, filtered, or refused — from the actual AVD VNet. Definitive, no logs archaeology.

Both the Chat tab and the Probes-tab embedded chat support file attachments. Click the paperclip in the composer.

Up to four files per message. Each becomes a chip above the text input. Click × on a chip to remove it. Files are dropped from the tray after sending.

Privacy on attachments

• Images and pcaps live in PBFS-owned blob storage (netbotec2c3340, chat-uploads container).
• A 7-day lifecycle policy auto-deletes them.
• Read URLs are short-lived (1 hour) user-delegation SAS — they expire even if leaked.
• Don't upload secrets-bearing material. Chat history is persisted server-side and recoverable in the audit log.

Analyze capture — the zero-upload path

After a packet_capture probe completes, the result card has an Analyze capture button. Clicking it server-side copies the pcap from probe storage into chat-uploads and stages it as an attachment in the embedded chat. No download/re-upload roundtrip; the agent reads it the moment you press Send.

NetBot is actively developed. The header's Help dropdown has two flows that file work directly into the team's ADO backlog.

Both open the same simple modal — title plus free-text description. The backend automatically attaches a triage block containing your UPN, the page URL you were on, your NetBot session id, and an excerpt of your last ten chat turns — so triage doesn't have to ask "where were you when this happened." A toast confirms the new work item id and links to it.

Quick triage — under sixty seconds

1. Land on Overview.

   KPI red? Click into the affected card.
2. WAF Posture has a "Detection only" callout?

   That's the row to investigate first.
3. Top Denied shows a familiar internal IP?

   Switch to Chat. "Why is <IP> denied to <destination>?"

Is this a network problem? — under five minutes

1. Chat:

   "Show me firewall denies for <my host> in the last 10 minutes."
2. If empty, Probes:

   Ping from the closest probe VM to the target.
3. If ping works but app fails, Probes:

   TCP port check on the actual application port.
4. If TCP works but the app still fails:

   It's the app, not the network.

Investigate an attack signal

1. Overview → Top WAF Hits.

   One client IP dominating? Click through.
2. Chat:

   "Pull WAF rule hits for <IP> in the last hour, grouped by rule id."
3. Probes → packet capture

   From the AG's backend VNet, filtered to that source IP, 30 seconds.
4. Click Analyze capture.

   "Summarize this capture — what's the attacker doing?"

Verify a change you just made

1. Wait sixty seconds.

   Let routes converge.
2. Probes → ping or traceroute

   From the affected VNet's probe VM.
3. Chat:

   "Compare denied flows for <host> in the last 5 minutes vs. an hour ago."

What we store

• Sessions — chat history, tool calls, tool results, in Azure Table Storage (auditlog + sessions). Encrypted at rest.
• Attachments — chat-uploads blob container, 7-day TTL, user-delegation SAS read URLs (1h validity).
• Audit rows — every chat turn, every probe approval/denial, every feedback submission, every rate-limit reject. Append-only.
• Probe pcaps — per-subscription npcap* storage accounts, 7-day TTL.

Where the AI runs

The agent runs Claude Sonnet 4.6 via Azure AI Foundry in the david-mouks6j7-eastus2 deployment. Calls go through PBFS managed identity (netbot-ai-uami) — no API keys leave PBFS infrastructure. Foundry deployments have no data retention for prompts or completions.

What you should not put in chat

• Customer PII outside of normal PBFS support workflows.
• Bearer tokens, PATs, cloud credentials, private keys.
• Anything covered by a stricter retention or DLP policy.

When in doubt, treat NetBot like an internal Slack channel: the conversation is logged for support and audit.

Auth model

Sign-in via Entra ID (PBFS tenant). MFA required per the org's standard CA policy. Backend trusts every request that reaches it — APIM has already validated the JWT before forwarding. NetBot doesn't store passwords or session tokens itself. An expired session redirects to /login — no flash of UI, no leaked data.

VWAN

Azure Virtual WAN — the hub-and-spoke topology PBFS uses for cloud networking. NetBot focuses on VWAN-connected resources.

Probe VM

A small Linux VM that NetBot can run network tests from. Twelve of them, one per VWAN-connected VNet. Deallocated when idle.

HITL

"Human in the loop" — every probe needs a person to click Approve before it executes.

WAF

Web Application Firewall, attached to App Gateways. Modes are Detection (logs only) and Prevention (blocks).

AG

Azure Application Gateway — Layer-7 load balancer in front of public-facing apps.

Flow log

Per-flow record from Azure Network Watcher describing traffic: source IP, destination IP, port, action, bytes.

Resource Graph

A real-time queryable index of all Azure resources. NetBot uses it for inventory questions.

NXDOMAIN

DNS response code meaning "this name does not exist." Spikes can indicate misconfig or malware beaconing.

Session

One conversation thread with the agent. The Chat tab and Probes tab keep separate sessions.

APIM

Azure API Management — validates your Entra JWT before requests reach NetBot's backend.

bff-auth

The platform's standard OAuth client that handles sign-in for NetBot and other PBFS apps.

ADO

Azure DevOps — where Help-menu tickets and feature requests land as User Stories.