AI agents: see /llms.txt for a full index of this site, or /llms-full.txt for concatenated documentation.

Network Rules

Control network connections across your fleet

Network rules bring application-level firewalling to Santa. Decide exactly what each process is allowed to talk to, audit before you enforce, and manage every rule from Workshop.

Beta

Matchers

Who, where, and how

A network rule pairs a target with a decision. Scope the target by the local process, the remote peer, and the transport, and Santa applies the rule to both outgoing and incoming connections.

Process identity

Scope a rule to specific software by CDHash, Signing ID, or Team ID, the same identifiers you use for execution rules everywhere else in Santa. Or leave the process open and apply a rule to all traffic. Rather than trusting a binary everywhere it runs, you decide exactly what it is allowed to talk to.

Remote peer

Match an exact hostname, a domain and all of its subdomains (example.com also matches api.example.com), or an IP address or CIDR range, IPv4 and IPv6 alike. Allow a single service, an entire domain, or a whole network in one rule.

Transport

Narrow a rule to single ports or port ranges, to specific protocols like TCP, UDP, or ICMP, and to a direction: outbound, inbound, or both.

Actions

Four actions for every posture

Flows that match no rule fall back to a per-tag default action. Set an overall default-allow or default-deny posture for each group of hosts, then let individual rules carve out the exceptions.

Allow

Permit matching flows. Carve out exactly what a process is allowed to reach, then tighten the default posture around it.

Deny

Block matching flows and notify the user with a notification explaining what was blocked and why.

Silent Deny

Block matching flows without notifying the user. Useful for known-bad destinations where feedback might tip off an attacker.

Audit

Allow matching flows but log every one to Workshop. See exactly what a rule would catch before you enforce it.

Rollout

Start with Audit

Roll out network policy the same way you roll out execution rules: watch before you block. Audit shows you exactly which flows a rule would match before a single user is interrupted.

1

Write rules in Audit

Pair your first rules with the Audit action. Matching connections proceed as normal, and every one emits an event to Workshop, so nothing breaks while you learn.

2

Review what matched

Watch matched activity arrive in Workshop with the process, the remote hostname, and the rule that matched, so you know exactly what a Deny would have interrupted.

3

Switch to Deny

Flip the action once you are confident the rule will not disrupt users. The updated rule syncs down to your fleet like any other Santa rule change.

4

Tighten the default

Put broad defaults on low-priority tags and exceptions on higher-priority ones, then move each group's default action toward deny as your rule coverage grows.

User experience

Blocks that explain themselves

When Santa denies a connection, the user is not left guessing. Blocks surface the same way execution blocks do, with a message you control, so people know what happened and where to get help.

  • A block dialog from Santa

    When a connection is denied, Santa surfaces its own block dialog, in the same place users already see execution blocks. No mystery failures, no hung apps with no explanation.

  • Custom message and URL

    Each rule can carry its own message and link, just like execution rules. Point users at an internal help page or explain exactly why a connection was denied.

  • Terminal-aware

    For command-line tools, Santa can also write the reason for the block to the controlling TTY, so CLI users see why a connection failed instead of staring at a timeout.

Telemetry

Every block on the record

Network rules do not just enforce, they explain. Every block and audit is recorded in telemetry with the context an investigation needs, and it lands in the same event pipeline as the rest of your fleet's activity.

  • Every block and audit is an event

    Each deny, silent deny, and audit verdict is recorded as a network flow event and streamed to Workshop, where matched activity shows up in your network activity view.

  • DNS-correlated hostnames

    Flow events carry the remote hostname the process was actually talking to, not just an IP address, so investigations start from names you recognize.

  • Full process attribution

    Every flow ties back to the binary and signing identity that opened it, using the same process identity model as the rest of Santa's telemetry.

  • Explainable verdicts

    Events record the rule that matched and the decision Santa made, and competing rule IDs are captured too, so you can always answer why a rule won or lost.

Use cases

Where teams use it

Egress control for sensitive processes

Lock a tool to a single destination. Allow a developer tool to reach your internal package registry and nothing else, or pin a backup agent to one storage endpoint.

Stop exfiltration and beaconing

Prevent a compromised or curious process from reaching an attacker-controlled host, even one you otherwise allow to run. Deny unexpected inbound connections to contain lateral movement.

Audit shadow IT

Turn on Audit for the traffic you care about and see which unsanctioned tools are talking to which services, with full process attribution, before deciding what to enforce.

Beta
Network rules are in beta and require Santa 2026.6 and Workshop 2026.6. The Santa network extension is enabled per tenant, so contact us to turn it on for your fleet.