Platform — FowlGuard

Access is an entitlement, not a network

A legacy VPN puts a device on the network and trusts it from then on. FowlGuard resolves what a person's groups allow at connect time, server-side, and routes only that — so a compromised laptop reaches the two subnets its owner needed, not the estate.

Direct paths where possible. Peer-to-peer with NAT traversal, falling back to a server route when the network refuses, so a hostile network degrades rather than fails.
Entitlement is never client-asserted. Routes are computed server-side; a modified client cannot grant itself more.
One machine, one entry. Devices are recognised across reconnects, so the fleet list stays a fleet list.

console screenshot
img/devices.png

The fleet: what is connected, on which tunnel address, and which policy revision each device has applied.

Rules you can read in the order they apply

Categories, hostnames and keywords, scoped to a person or a group and evaluated first-match. When two rules overlap there is one answer, you can see which rule gave it, and you can move it above the other if that was wrong.

Report before enforce. Any rule can run report-only, so a policy is watched in the logs before it cuts anyone off.
Your block page. Your wording and branding, or your own HTML — with a request route so a wrong rule gets corrected rather than worked around.
Exceptions stay separate. Approved one-off requests become their own rules, kept out of the list you maintain by hand.

console screenshot
img/filtering.png

A rule expanded: audience, blocked categories, allowed sites, and the report-only switch.

Content classified before it leaves

Outbound content is inspected and graded across four sensitivity tiers. You choose the tier and the confidence at which anything happens, and whether that is a log entry or a refusal.

Validated, not guessed. Card numbers, national identifiers and account numbers are checked against their own check digits, so a random sixteen-digit string is not an incident.
Never stores the match. An alert records the detector and the count, never the value — an alert queue quoting card numbers recreates the leak it exists to prevent.
Sensitive destinations are never inspected. Banking, healthcare and government are excluded before any certificate is minted, so for those it does not happen at all.

console screenshot
img/security-policy.png

Tier and confidence thresholds, the action on a match, and the hosts never inspected.

Policy written for you, decided by you

Policy goes stale because writing it is tedious and reviewing it is worse. Describe the intent — or the organisation — and get back a complete, valid proposal using only the categories and groups your tenant actually has.

It never applies anything. Every suggestion arrives switched off and report-only; a person saves it or discards it.
It cannot invent. Groups and categories are validated against your tenant, so a draft that could not be saved is never offered.
It says what it assumed. Proposals carry their reasoning and the things to check before enabling.

console screenshot
img/ai-policy.png

A described organisation, the posture proposed for it, and the cautions attached.

The parts nobody demos, and everybody needs.

A security product is judged on its worst day, not its demo. These are the pieces that matter when something has gone wrong and somebody is asking you what happened.

Access logs

Every connection and every block, filterable by user, device and host, with real paging rather than an endless scroll.

Rollout visibility

Each policy change carries a revision, and the console shows which devices have applied it — so "saved" and "in force" stay distinguishable.

Groups, routes and limits

Entitlement and bandwidth defined once and applied per group or per person, with the stricter of the two winning.

Four controls, one console, one policy.