Wardengate
Guide

Command & connection control

Least privilege is not just about who connects — it is about what they can do once connected. Wardengate evaluates commands and connection patterns at the gateway before they reach production.

Why gateway-side control matters

Shell history on a target can be altered. Database audit plugins miss ad-hoc clients. Gateway-side filtering sees every command and query in the brokered stream — tied to identity and policy version — before execution completes on the target.

Command filtering

Define allow and deny lists per role, target class, or session type. Block destructive patterns — rm -rf, DROP DATABASE, kubectl delete — or require approval for matches. Regex and literal rules combine; deny wins. Operators see a clear rejection with policy reference, not a silent failure.

Connection ACLs

Restrict which source networks, client tools, or time-of-day windows may initiate sessions. Pair with JIT grants so standing connection rights never accumulate. Vendor identities get tighter connection ACLs by default — shorter sessions, fewer protocols, mandatory recording.

Approval-gated actions

High-risk commands can pause the session and route an approval ticket to ServiceNow or your ITSM. The approver sees session context — who, what target, which command — before release. Approved actions are recorded with approver identity for audit export.

Operational docs

Ready to deploy? Continue in documentation

Ready to evaluate?

See the platform on your architecture

Walk through gateway brokering, recording, and audit exports in a working session — or start with the interactive demo.