Air-gapped Network
You build an air gapped network by disconnecting target computers from the public internet. You also block all wired and wireless links to outside corporate local networks. Security teams set up this wall to protect critical systems from outside attackers. Inside the closed room, operators still log in to run updates and fix bugs. Teams often grant broad admin roles to make this local work fast. Those wide permissions create huge risks if an insider runs a bad command. How an air gapped networ
Network: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You build an air gapped network by disconnecting target computers from the public internet. You also block all wired and wireless links to outside corporate local networks. Security teams set up this wall to protect critical systems from outside attackers. Inside the closed room, operators still log in to run updates and fix bugs. Teams often grant broad admin roles to make this local work fast. Those wide permissions create huge risks if an insider runs a bad command.
How an air gapped network works in practice
A true air gapped network has zero network routes to the outside world. Packets cannot travel in or out through routers, switches, or wireless access points. Teams often disable network cards or remove wireless hardware from the motherboards. To move software updates in, staff must carry physical drives into the room. First, they scan the drive on a separate check station for bad files. Then they walk the clean drive over to the isolated server rack.
Inside the closed boundary, servers and databases still talk to each other. Local directory services check user names and passwords when operators log in. Admins assign local roles that decide which servers a person can reach. Database engines check local role tables before they let a user read data. Even without internet links, the internal setup looks like a normal server room.
What physical isolation solves and what it misses
Physical separation stops remote hackers from reaching your servers over the web. It blocks automated phishing links and stops data leaks over public network lines. For factories, power grids, and defense labs, this barrier is a vital base. Outside attackers cannot scan ports or exploit bugs from across the ocean.
Still, physical walls only control how traffic enters the room. They do not control what happens after a trusted user logs in. Operators and third-party vendors still need hands-on sessions to maintain the apps. Because moving files in takes time, admins often give staff permanent admin roles. They do this so engineers do not get stuck during a system outage.
Once an engineer opens a session, the local role gives them full power. The server setup checks who logs in, not what each command does. An operator can run a drop table query by mistake during routine work. A vendor can query sensitive tables and read raw emails or card numbers. Standard local logs often miss the exact queries or shell commands someone ran. You know who entered the room, but not what they touched inside.
Network: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Why local roles need command-level checks
Relying only on network walls leaves your databases and servers open to mistakes. When every local user holds a root key, one typo can wipe data. Teams need a way to inspect every single query and shell command live. Instead of trusting a broad login session, you should check actions in flight.
Adding query rules and data masking fixes the gap inside the closed network. Masking rewrites matched fields like phone numbers or national IDs in query results. Approval rules can pause risky commands until a second team member says yes. Detailed logs record every statement and attach it to a real person. This keeps your isolated data safe from both human errors and bad insiders.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Can data still leak from an air gapped network?
Yes, insiders or contractors with broad local roles can copy data to USB drives. Without field masking and query controls, staff can read and export sensitive records.
How do teams update software inside an isolated network?
Engineers load patches onto physical media and scan them at a check station. They then carry the media into the room and run the updates locally.
Why are broad admin roles common in offline systems?
Fixing broken permissions takes longer when experts cannot log in from home. Teams often grant wide admin roles up front to avoid delays during outages.