DEV Community: David Boggs

Least Privilege Is a Policy Until the System Can Say No

David Boggs — Sat, 12 Sep 2026 14:51:45 +0000

Least Privilege Is a Policy Until the System Can Say No

A technician needs to change one DNS record. The ticket is approved. The access request says "least privilege." The technician receives membership in a group that can edit the entire zone.

The workflow followed policy. The permission did not match the task.

This is where many least-privilege programs stop: someone has justified a role, approved its assignment, and perhaps scheduled a review. But the running system still permits substantially more than the work requires.

For a buyer, the useful question is not "Do you support least privilege?" It is:

"What prevents someone authorized for this task from performing a different one?"

That question separates an access policy from an enforced boundary. It also gives you a practical way to evaluate a vendor without accepting "role-based access control" as a complete answer.

A role is not necessarily a task boundary

Role-based access control, or RBAC, assigns permissions through roles. It is useful for organizing access, and it can represent fine-grained permissions. There is nothing inherently incompatible between RBAC and action-level authorization.

The problem is how roles are often defined.

A "help desk" role might allow password resets across a broad user population. A "DNS operator" role might allow changes throughout a zone. Those permissions can remain available between tickets, even when the technician has no current reason to use them.

An approval process does not narrow those permissions unless the system enforces the approved scope. A ticket saying "change this record" does not stop a credential from changing another record.

Action-level authorization moves the boundary closer to the requested work. Instead of granting general authority over a resource, the system permits a defined operation against an allowed target, with constraints on its inputs.

Consider a hypothetical DNS request:

Allowed operation: update an A record
Allowed target: app.example.com in the example.com zone
Allowed value: the address authorized for this change

The important property is what happens when the caller changes that request. Can they update a different hostname? Change a different record type? Supply an unapproved address?

A narrow screen is not enough. The underlying authorization must reject requests outside the allowed operation.

Action scope and access duration are also separate dimensions. A short-lived administrator session still permits broad actions while it is active. An action console can enforce narrow operations while leaving permission to invoke them available indefinitely. Buyers need to evaluate both.

Turn the claim into a testable contract

Before a demo, pick one routine administrative task. Avoid starting with the vendor's entire permission model.

Write down what an authorized technician should be able to do. Then write down the nearest things they should not be able to do.

For a password reset, you might allow resets for a designated employee population while excluding privileged accounts. For file-lock release, you might allow work on specified file servers while excluding other systems.

These are your requirements, not assumptions about what every product supports.

A useful evaluation worksheet looks like this:

Boundary	Write down before the demo
Caller	Which person or group may invoke the action?
Operation	What exact operation is permitted?
Target	Which objects or systems are eligible?
Inputs	Which values or options are accepted?
Duration	When should invocation permission stop?
Evidence	What should the record of execution show?

Use this worksheet to run the following checks in a controlled test environment.

1. Test the nearest forbidden action

Ask the vendor to demonstrate the permitted task, then attempt a closely related forbidden task using the same identity.

For DNS, that could mean changing a neighboring record. For password resets, it could mean targeting an excluded account. A useful denial test stays close enough to the approved workflow that it exposes a real boundary.

Watch where enforcement occurs.

A disabled button or hidden menu demonstrates a user-interface restriction. It does not establish that the backend will reject the request. Have the vendor exercise the relevant service endpoint or another supported test path with an out-of-scope request.

The acceptance condition is concrete: the unauthorized operation must not execute.

Record the denial, but also verify the target's state. An error message alone is weak evidence if a change could already have occurred.

2. Inspect inputs that can widen the action

An operation can have a narrow name and still expose broad authority through its parameters.

"Remediate vulnerability" sounds specific. If the caller can provide arbitrary shell commands, choose any script, or modify execution arguments without restriction, the effective permission may be general remote execution.

Ask to see the action's input contract. Which fields does the caller control? Which values are fixed or validated by the service? Can a target identifier point outside the approved system set?

Test a modified request that widens one of those inputs.

Do not assume every variable input is dangerous. Technicians need useful choices. The issue is whether those choices remain inside the intended authority boundary.

A credible answer explains how the backend validates the request. "Our technicians know which values to enter" describes training, not enforcement.

3. Find the authority behind the console

A console may prevent technicians from receiving administrator credentials while still using a privileged identity to perform work on their behalf.

That can be a meaningful improvement. It also moves the trust boundary to the service executing the action.

Ask how that service authenticates to the target systems and how its authority is restricted. Find out who can change action definitions or expand the allowed target set.

Two permissions deserve separate attention:

Permission to invoke an existing action.
Permission to create or modify what that action does.

If the same technician can rewrite an approved action into an arbitrary command, the action boundary offers little protection against that technician.

You do not need a universal architecture requirement here. You need to understand where powerful authority resides, who controls it, and what a compromise of that component would expose.

4. Test revocation separately from task scope

A tightly scoped action can still be available to the wrong person for too long.

Remove a test user's permission while they have an authenticated session. Attempt the action again. Ask the vendor to explain when revocation takes effect, including any caching or session behavior.

If your requirements include ticket-bound or time-limited authorization, test those explicitly. Close the test ticket or let the authorization expire, then retry.

Do not treat these controls as automatic consequences of "least privilege." A product may constrain operations well without connecting authorization to individual tickets.

That may be acceptable for recurring help desk work. For less frequent, higher-impact changes, you may require an additional approval or time boundary. Write that distinction into your evaluation instead of relying on the label.

5. Reconstruct the change from its audit record

"Every action is logged" leaves substantial room for interpretation.

After the test, ask a colleague who did not watch the demo to explain what happened using the available records.

Can they identify the human caller, rather than only the backend service account? Can they determine the requested operation and target? Does the record distinguish a submitted request from a successfully completed change?

For asynchronous operations, look for a way to connect the request to its eventual outcome. For failures, determine whether the record makes partial execution visible.

Also ask who can modify or delete records and how your team would retrieve them during an investigation.

Logging requires judgment. Recording passwords, reset secrets, or other sensitive input can create a new exposure. Define what investigators need while excluding values that should not appear in logs.

A log is useful when it supports reconstruction, not merely when it exists.

6. Exercise the exception path

Routine demonstrations tend to show valid input and a healthy target. Operational pressure arrives when those conditions disappear.

Test what happens when the requested target is unsupported or the backend fails. Ask how technicians handle work that has no approved action.

An exception path that routinely hands out broad administrator access can undermine the narrower workflow. That does not mean emergency access must disappear. It means you should evaluate its authorization and accountability separately.

Also ask what it takes to add or revise an action. Someone must maintain the operation as systems change, validate it, and manage failures. A tightly constrained console is less useful if the approved action catalog cannot keep up with actual work.

The buyer's question is whether the operational cost is manageable enough that staff will consistently use the controlled path.

Decide based on the demonstrated boundary

After the evaluation, summarize results in plain statements:

Demonstrated:
The test identity could reset passwords for the allowed population.
The same identity could not reset an excluded privileged account.

Unresolved:
Revocation behavior during an existing session was not demonstrated.

Required before acceptance:
Provide and test the expected revocation behavior.

This is more useful than assigning a vendor a generic "least privilege" checkmark.

Action-level controls also have limits. An authorized operation can still be a bad decision. Updating the correct DNS record to the wrong approved address can cause an outage. Releasing a file lock can disrupt active work.

Authorization constrains who can do what. It does not replace change validation or recovery planning.

Where our own product lands on this

Foyer, the Least-Privilege Action Console in Adaptive IP Services' Hub division, applies this approach to administrative work.

IT staff receive a web console that runs only approved operations against allowed systems, without shared admin credentials or root. Every action is logged. The stated patterns include self-service DNS record changes, file-lock release, password resets, and vulnerability remediation.

Those are the product's stated boundaries. Use the same evaluation above to examine them. Requirements such as ticket integration, time-limited grants, or particular audit-record fields should be verified directly; they should not be inferred from the phrase "least privilege."

For your next evaluation, bring one real task and its nearest forbidden variation. Make the vendor show both the successful operation and the rejected request. That is where a policy claim becomes something you can inspect.

Disclosure: I work at Adaptive IP Services, a Dallas based IT and security firm.

David J. Boggs
Founder and CEO, Adaptive IP Services

Foyer, Least-Privilege Action Console

Your AI vendor says "zero egress." Here is how to actually check.

David Boggs — Sat, 12 Sep 2026 13:06:29 +0000

Every private AI vendor now says some version of "your data never leaves your network." It is a good claim. It is also one of the easiest claims in the industry to make and one of the least often checked.

I build and deploy this category of system for a living, so this is not a neutral post. But the test procedure below is vendor neutral, it runs in an afternoon, and it works just as well pointed at my product as at anyone else's. If you are evaluating a self-hosted AI knowledge base, RAG platform, or internal assistant, this is the part of the evaluation that nobody does and everybody should.

"Zero egress" is three separate claims wearing one coat

When a vendor says zero egress, they could mean any of these, and the gap between them is where the surprises live.

The inference path. Your prompts and your retrieved document chunks are not sent to a third party model API. This is the claim people think they are buying. It is also the one most likely to be true, because it is the headline.

The data plane around inference. Embeddings, reranking, OCR, speech to text, document parsing, image description. A system can run the chat model locally and still ship every page of every indexed document to a hosted embedding endpoint. If your document set is the sensitive thing, and it usually is, this path leaks more than the chat path does.

The control plane. Telemetry, crash reporting, usage analytics, license check-in, auto-update, model pulls, container registry pulls, DNS, NTP. None of this is your document text. All of it is metadata about your environment, and some of it is a live outbound channel into your network that you did not deliberately open.

A product can be entirely honest about the first claim and still fail the second and third. Ask about all three separately, in those words, and watch which ones get a crisp answer.

The paths that actually leak

From evaluating and building these stacks, this is the list I work through. None of it is exotic. All of it has shown up in real deployments of real products.

Hosted embedding models. The most common one. Local chat model, remote embeddings. Ask specifically: what model generates the vectors, and where does it run.
Sidecar services. OCR, transcription, and layout parsing are often the piece a vendor did not want to build, so they called an API. If the product ingests scanned PDFs or audio, ask what handles them.
Reranking. Same story, one layer down the retrieval pipeline, and easy to miss because it only fires on queries, not on ingest.
Error and crash reporting. A Sentry-class SDK will happily transmit stack traces containing prompt fragments, file paths, usernames, and query strings. This is usually an oversight rather than a design, which does not make it better.
Product analytics. Event streams with document counts, seat counts, feature usage, and sometimes query text for "search quality improvement."
License and entitlement check-in. A phone home on a timer. Often the hardest thing to remove, because the business model depends on it, and often the thing that silently breaks an air-gapped install thirty days after it worked fine.
Runtime model and dependency fetching. If model weights are downloaded on first run instead of baked into the image, you have an outbound dependency and a supply chain question at the same time.
DNS. Even with egress blocked at the firewall, if the resolver is upstream then hostname lookups still describe your internal traffic to whoever runs that resolver. DNS query logs are the highest signal per unit of effort in this entire test.
Outbound integrations you turned on yourself. Email notifications, webhooks, chat alerts, SSO to a cloud identity provider, connectors to SaaS sources. These are legitimate and deliberate. They are still egress, and they belong on the diagram.

How to test it in an afternoon

You do not need a lab. You need one host, a packet capture, and a representative workload.

Step 1: default deny, and log the drops. Put the deployment behind an egress policy that denies everything outbound and logs every denied packet. Do not start with allow-and-observe. Start denied, then read what screams. On Linux, an nftables or iptables OUTPUT chain with a log target on the drop rule is enough. The log is your finding list.

Step 2: check the container network topology before you trust anything else. If it ships as containers, inspect the network the AI services actually attach to. A bridge network created in internal mode has no gateway and no route out, which is a structural property you can verify in one command rather than a policy someone has to keep enforcing. Confirm which services sit on which network. The interesting finding is usually a single service that is on both.

Step 3: sinkhole DNS and read the query log. Point the deployment at a resolver you control that answers everything with a black hole address and logs every query. Then run a full workload. The query log is a plain text list of every remote host the software wanted to reach, including the ones the firewall already blocked and the ones that fail silently. I have never run this test and learned nothing.

Step 4: run a representative workload, not a smoke test. Index a real document set with real file types, including a scanned PDF and something with an embedded image. Ask twenty questions, including one that returns no good answer, because error paths are where crash reporters fire. Upload a document through the UI. Log in and out. Have an admin change a setting. Let it sit idle overnight, because timers are the point of the whole exercise.

Step 5: capture the traffic, not just the logs. Run a packet capture on the host interface for the whole window. Then look at what remains after you filter out your own management traffic. You are looking for TLS handshakes to hosts you cannot explain, and you are looking at timing, because a beacon on a fixed interval is a beacon regardless of what is inside it.

Step 6: pull the cord. Remove the default route entirely and repeat the workload. Write down what breaks and how it breaks. Good behavior is full feature parity, or a clear degradation on a documented feature. Bad behavior is a hang, a silent failure, or a licensing error two days later. If a vendor says the product supports air-gapped operation, this test either confirms it in an hour or ends the conversation early, which is also a good outcome.

Step 7: ask how the isolation is enforced, not just whether it holds today. The result you got is a snapshot of one build. The question that matters for the next three years is whether isolation is verified automatically on every build, or whether it was verified once by a person who has since moved teams. A vendor who can describe an automated check in their release pipeline is telling you something structurally different from a vendor who can only describe an architecture diagram.

Questions that are hard to bluff

Send these before the demo. The answers, and how fast they come back, tell you most of what you need.

Which components make outbound network calls at any point in normal operation, including timers and background jobs?
Where do embeddings get generated, and by what model?
What handles OCR, transcription, and document parsing?
Is telemetry present, can it be disabled, and does disabling it stop the process or only stop the transmission?
Does licensing require a periodic check-in, and what happens on day thirty with no route out?
Are model weights and dependencies present in the artifact you ship, or fetched at first run?
Is network isolation asserted in your release pipeline on every build, and what exactly does that check assert?
What is the complete list of hostnames the product would resolve in a month of normal use?

That last one is my favorite. A vendor who has genuinely built for isolation can answer it from memory or from a config file. A vendor who has not will need to go ask engineering, and the delay is the answer.

Where our own product lands on this

Adaptive Reservoir is a private AI knowledge platform that runs on hardware you own, on premise or in your own cloud account. It exists because the alternative most companies pick is banning AI outright and eating the productivity loss.

Against the checklist above: the AI runs on an internal-only container network with no route to the internet, and that isolation is asserted by an automated release gate on every build rather than only claimed in documentation. It runs with no internet connection at all. There is no cloud account, no external API key, and no per-token bill, because the model runs on your hardware. The target footprint is a single Linux host with an NVIDIA GPU, and 16 GB of GPU memory is the practical sweet spot. Answers cite the documents and decisions they came from, which is its own small audit property: a citation you can open and read is a retrieval path you can verify by hand.

The honest caveat, because a post about verifying claims should not hide behind its own. Reservoir offers optional connectors that pull AI activity from platforms you already use, through each vendor's official compliance API. Those connectors are outbound by definition. They are scoped, they are something you choose to enable, and they belong on your network diagram in a different color from the inference path. Any vendor telling you their product has literally zero outbound sockets under every possible configuration is describing marketing, not networking.

Base pricing starts at $395 per month and scales with deployment size and the optional modules you turn on. Details at adaptiveips.com/adaptive-reservoir.

Run the test

The point of this post is not the product. The point is that "your data never leaves" is a testable assertion, and almost nobody tests it. A DNS sinkhole, a default deny rule, and a representative workload will tell you more in one afternoon than a security questionnaire will tell you in six weeks.

Run it against whatever you are evaluating. Including ours.

Disclosure: I work at Adaptive IP Services, a Dallas based IT and security firm, and we build Adaptive Reservoir.