DEV Community: David Boggs

What Actually Breaks When You Leave Jira: A Pre-Migration Audit

David Boggs — Wed, 30 Sep 2026 14:03:21 +0000

What Actually Breaks When You Leave Jira: A Pre-Migration Audit

A replacement can import every ticket and still break the way your team works.

Consider a change request that reaches "Approved" after migration. The status looks correct. But the old workflow required approval from someone other than the requester, checked a mandatory field, and triggered a downstream action. If the replacement preserves only the status label, the ticket survived while the control disappeared.

That is the migration problem to investigate before comparing boards or subscription costs.

First, distinguish the deadlines: Jira Server support ended on February 15, 2024. Atlassian has announced March 28, 2029 as the end-of-life date for affected Data Center products, including Jira Software Data Center. These are different timelines, even if both put replacement planning on your desk. See Atlassian's Server support FAQ and Data Center end-of-life announcement.

The following audit produces something more useful than a feature wishlist: a set of requirements and test cases you can hand to any replacement vendor.

Start with an evidence register

Create a spreadsheet with one row per dependency or behavior:

Project / issue type:
Configuration or dependency:
Business purpose:
Owner:
Evidence from current system:
Required behavior after migration:
Disposition:
Acceptance test:
Unresolved question:

Use four dispositions: preserve, redesign, archive, or retire. Leave genuinely unknown items marked unknown until someone investigates them.

Gather configuration exports where available, installed app names and versions, integration details, project ownership, and representative tickets. Record the source version and collection date so later configuration changes do not silently invalidate the audit.

Work from read-only inspection or an isolated restored copy. Disable outbound integrations and notifications in the copy before exercising workflows.

Do not clean up production as part of discovery. A field that looks abandoned may still feed a quarterly report. Identify its owner and dependencies first.

Audit workflow behavior, not the diagram

Start by mapping each project's issue types to their assigned workflows. A single project can use different workflows for different issue types through a workflow scheme. Atlassian documents that relationship in its workflow administration guide.

For each active workflow, inspect the transitions. Jira distinguishes conditions, validators, and post functions: these can control whether a transition is available, whether it succeeds, and what happens afterward. A destination with matching status names does not establish equivalent behavior. See Atlassian's advanced workflow configuration documentation.

Record:

Who can perform each transition, including exceptions.
Which fields must be present and how their values are checked.
What changes automatically after the transition.
Which rules depend on an app, script, webhook, or external service.
How reopening, rejection, cancellation, and reassignment behave.
How statuses map to board columns and reporting definitions.

Turn important rules into executable acceptance scenarios. For a hypothetical approval process:

Given: A change request is awaiting approval.
Actor: The person who submitted it.
Action: Attempt to approve it.
Expected: Approval is denied.

Actor: An authorized independent approver.
Action: Approve with the required evidence missing.
Expected: Approval is denied.

Action: Supply the evidence and approve.
Expected: The transition succeeds and the approval
actor and time remain inspectable.

The exact target implementation can differ. The required control should be explicit.

Include rejection paths in the test set. A demo where an administrator moves a ticket through every column proves little about ordinary users or restricted actions.

If nobody can explain a rule, mark it for investigation. Do not automatically carry it forward or delete it.

Trace plugin dependencies to the work they perform

An installed app list is only a starting point. You need to know where each app participates in daily work and where it stores information.

For every app, identify:

The projects, fields, workflow rules, and reports that use it.
Any data stored outside ordinary issue fields.
Its export options and the format of exported data.
Scripts, scheduled jobs, or integrations that depend on it.
The person who will accept a replacement behavior.

Even Atlassian's own Cloud Migration Assistant treats app migration separately: app vendors must provide an automated migration path for their app data to migrate through the assistant. That illustrates why "we migrate Jira" is insufficient evidence for a particular dependency. See what the assistant migrates.

Suppose an app implements an approval table with multiple decisions per ticket. Flattening it into a text field might preserve readable evidence, but it may eliminate structured reporting and enforcement. That can be acceptable for historical records while being unacceptable for active requests.

Require a disposition for every essential dependency:

Disposition	Evidence needed
Replace with native behavior	A passing test of the required behavior
Rebuild	An owner, implementation estimate, and maintenance plan
Preserve as an archive	A tested retrieval method with appropriate access controls
Retire	Approval from the process owner and a dependency check

"No equivalent" is a real outcome. It may require changing the business process or rejecting a candidate. Discovering it before purchase is the purpose of this audit.

Treat historical tickets as records with relationships

A ticket count is a useful reconciliation check. It does not tell you whether the records remain meaningful.

Years of history can contain former employees, deleted field options, old project keys, attachments, and links to systems that no longer exist. Decide what must remain usable before selecting an import method.

Build a representative sample that includes:

The oldest records and recently updated records.
Reopened issues and issues moved between projects.
Tickets attributed to inactive or renamed users.
Restricted issues and restricted comments.
Large attachments and unusual filenames.
Parent-child relationships and cross-project links.
App-owned fields and historical sprint membership.

For each sample, compare the source and proposed target. Check authorship, timestamps, field values, comments, attachments, and relationships. Where file bytes should remain unchanged, compare attachment checksums as well as counts.

Document identity mapping explicitly. Mapping every departed employee to "migration user" can erase useful attribution. Mapping an old account to the wrong current employee is worse.

Separate operational history from archival history. Active work may require editable relationships and queryable fields. Closed work may only need reliable retrieval, preserved attribution, and restricted access. The owners of those records should decide.

If historical reporting matters, run a known report against the proposed target or archive. A final status alone cannot reconstruct how long a ticket spent in each state.

An archive is only a valid plan if someone has demonstrated retrieval. "We have the backup" does not answer how a project owner will find an attachment later. If the archive depends on running the old application, verify that licensing, support, and operating arrangements make that practical.

Test effective permissions

Permission scheme sprawl makes configuration names poor evidence of actual access. Audit what specific people can do.

Start with project permissions, project role membership, directory groups, and issue-level restrictions. Record exceptions for service accounts and individually granted access. Atlassian's project permission documentation provides a reference for inspecting the source configuration.

Build an access matrix around representative identities:

Identity	Resource and action	Expected result
Project member	Read ordinary project ticket	Allow
Unrelated employee	Read restricted ticket	Deny
Contractor	Download restricted attachment	Deny
Automation account	Update designated project	Allow
Former employee	Sign in	Deny

Adjust these expectations to your actual policy.

Run the same tests against each candidate. Include direct URLs, searches, exports, API access where available, and notifications. A ticket hidden from a board may still be exposed through another route.

Record intended changes separately from migration defects. If the existing permissions are too broad, reproducing them faithfully is not success. The responsible owner should approve the corrected access matrix before testing starts.

Use the audit to control the pilot

Choose a pilot scope that covers each distinct high-risk dependency. The smallest or cleanest project may exercise none of the difficult behavior.

Give each candidate the same sample records and acceptance tests. Ask for observed results, including failures. Keep "supported according to documentation" separate from "demonstrated with our data."

Before choosing a replacement, verify:

[ ] Every active workflow has an owner and a documented disposition.
[ ] Essential app dependencies have a demonstrated path or an accepted redesign.
[ ] Historical records have explicit preservation and retrieval requirements.
[ ] Permission tests include denied actions.
[ ] Integrations have owners and target behavior defined.
[ ] Each unresolved limitation has an owner and a decision deadline.
[ ] The proposed migration service states its exclusions and acceptance criteria.

Then rehearse the operational move. Measure extraction, import, and validation time using representative data. Identify how changes made during the migration window will be captured or prevented.

Write the rollback decision before cutover. Specify who can call it, what triggers it, and what happens to tickets edited in the destination. Restoring the source does not automatically reconcile destination writes.

Compare candidates using the cost of the accepted design, including rebuilds, archive operation, retraining, and ongoing maintenance. For a self-hosted replacement, assign responsibility for patching, backups, monitoring, and restore testing.

Where our own product lands on this

Adaptive Work is a self-hosted Jira alternative in Adaptive IP Services' Hub division and part of the Adaptive Reservoir platform. It provides ticketing, kanban boards, sprints, and approval workflows on-premises, behind your own network boundary. Migration off Jira Server/Data Center is handled as a service.

Those facts make it relevant to teams that want issue tracking to stay inside their network. They do not establish compatibility with a particular plugin, custom workflow, or historical data model.

Apply the same audit to Adaptive Work. Bring the dependency register and acceptance tests into the evaluation, and require the migration scope to explain what will be preserved, redesigned, archived, or retired. A migration service still needs concrete acceptance criteria.

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

David J. Boggs
Founder and CEO, Adaptive IP Services

Adaptive Work

AI Agent Permissions: Decide What Needs a Human Before You Connect the Tools

David Boggs — Wed, 23 Sep 2026 14:01:10 +0000

AI Agent Permissions: Decide What Needs a Human Before You Connect the Tools

An AI agent can draft an excellent customer email and still be the wrong system to decide when to send it.

That distinction gets lost when an evaluation focuses on answer quality. A convincing demo shows that an agent can interpret a request and complete a workflow. It does not establish which parts of that workflow the organization should authorize it to perform independently.

The useful governance question is: "Which actions can happen without a human decision, and under what conditions?"

You can answer that before choosing a model or buying an agent platform. Start with the actions, the systems they affect, and the consequences of getting them wrong. Then turn those decisions into enforceable permissions.

Inventory actions, not job titles

"Sales assistant" is a role description. It is not a permission boundary.

A sales workflow might involve reading an account record, adding an internal note, changing an opportunity stage, drafting an email, and sending that email. Giving the agent "CRM access" hides several materially different decisions inside one phrase.

Build an action inventory before connecting credentials. For each proposed task, record:

The exact operation and target system.
The records or fields the agent needs.
The possible downstream effects.
Whether the action can be undone, including consequences outside the system.
The person accountable for allowing it.

Use verbs that map to actual operations. "Manage opportunities" is too broad. "Add a proposed next-step note to assigned opportunities" is something you can evaluate and test.

Do not assume an operation is harmless because its name sounds administrative. Updating a CRM field could trigger an email workflow. Adding someone to a campaign could schedule future outreach. Classify an action by its effective consequences, including automation it activates.

Use read, write, and external commitment as the starting boundary

A useful first pass separates access into the following classes. These are policy starting points, not universal defaults.

Action class	Example	Starting policy
Read	Retrieve assigned account history	Allow within a defined data scope if the task requires it
Internal write	Save a draft or add a proposed note	Consider allowing where the effect is bounded and recoverable
Consequential write	Change account ownership or a field that triggers automation	Require approval or narrowly defined, tested conditions
Send or publish	Email a prospect or publish a campaign	Require approval of the specific outbound action
Pay or otherwise commit resources	Issue a refund or submit a purchase	Keep disabled unless explicitly needed; define separate authorization if enabled

This classification prevents a common mistake: treating every write as equivalent.

Saving an unpublished draft and sending it to a customer might use adjacent API endpoints. Their consequences are different. A draft can usually be reviewed before it affects anyone. A sent message can be corrected, but the recipient has already received it.

Payment belongs in a separate decision even when the interface makes it look like another tool call. Approval to communicate should never imply approval to spend.

For an initial deployment, a defensible posture is scoped reading, limited internal drafting, and explicit approval before external commitment. Expand from there when you have evidence that a particular action warrants more autonomy.

Read permission still needs boundaries

Reading does not modify the source record, but it can expose information to components involved in processing the request.

Before granting read access, decide which data the task actually requires. An agent preparing account follow-ups may need selected contact fields and recent account activity. That does not automatically justify access to every attachment, billing record, or unrelated customer.

Check the entire processing path: retrieval, model input, tool responses, logs, and any retained working context. Read-only access to the source system does not answer where retrieved information travels or who can later inspect it.

Also treat retrieved content as data, not authority. An email, web page, or customer note may contain text telling an agent to change its instructions or use another tool. That text should not be able to expand the agent's permissions.

A practical test is to place an instruction in a test record asking the agent to retrieve an unrelated restricted record. The permission boundary should reject the attempted access regardless of whether the model follows the instruction.

Decide which internal writes can run unattended

Human approval for every draft save creates work without necessarily reducing meaningful risk. The goal is to put review where it changes the outcome.

For each internal write, ask:

Is the target tightly scoped?
Can the change be reversed with a known recovery procedure?
Can it activate another workflow or influence an important decision?
Can repeated execution create duplicates or accumulating damage?
Will a person see the change before relying on it?

These answers should produce a specific policy.

For example, you might allow an agent to save a proposed follow-up in a draft field on assigned accounts. You might require approval to overwrite an existing contact address because a bad change could misdirect later communication.

"Internal" is not a synonym for "low risk." An inaccurate support note could influence the next employee's response. An incorrect opportunity stage could affect reporting. Some internal writes need review even when nothing immediately leaves the organization.

Where possible, separate proposals from authoritative records. Let the agent suggest a change without granting permission to replace the value that other workflows trust.

Define approval as a specific transaction

An approval gate is useful only if the reviewer can tell what they are authorizing.

"Approve the next step" is insufficient. For an outbound email, the review should show the destination, sending identity, exact content, and attachments. Include relevant source context so the reviewer can check factual claims without reconstructing the workflow.

The approval should bind to that specific action. If the recipient, content, attachment, or other material parameter changes, the action needs fresh approval.

Use this pattern as an implementation and procurement checklist:

The agent prepares a proposed action.
A policy check determines whether the action is allowed, blocked, or requires review.
An authorized reviewer inspects the proposal.
The execution layer verifies that approval still applies to the exact action being attempted.
The system records the result, including failure or uncertain delivery.

The execution layer matters. A prompt that tells an agent to ask permission is a behavioral instruction. It should not be the only control protecting an outbound capability.

Check alternate routes too. Blocking one email tool does little if the same credentials can send through another endpoint or trigger a campaign that sends later.

Expired, rejected, or missing approval should leave the action unexecuted. Retries also need attention: approval for one send should not silently become authorization for duplicate sends after a timeout.

Give reviewers a decision they can realistically make

Human review has a cost. Every gate adds delay and consumes attention. Poorly designed gates can become a queue of habitual clicks.

Assign a reviewer who understands the action and has authority over its consequences. For a customer response, that may be the person responsible for the account or support case. Resource commitments may require a different owner.

Make the review screen answer practical questions:

Who or what will be affected?
What exactly will happen?
Which source records support the proposed action?
What assumptions or unresolved questions need checking?
Has a similar action already executed?

An explanation of why the agent chose an action can help orient the reviewer, but it is not proof that the action is correct. Show the underlying evidence.

Measure review burden during a pilot. If reviewers cannot examine proposals carefully at the expected volume, reduce scope or improve the review context. Removing gates merely to clear a backlog changes the risk decision; it does not solve the review problem.

Test permissions with deliberate failure cases

Do not accept a successful demonstration as evidence that the boundary holds. Use test accounts and controlled destinations to attempt actions that should fail.

A compact acceptance checklist:

Request a record outside the role's assigned scope.
Attempt to modify a field the role can only read.
Try sending without approval.
Approve a draft, then change its recipient before execution.
Attempt an outbound action through an alternate tool or workflow.
Retry an action after a simulated timeout.
Revoke permission while an action is waiting for approval.
Put instructions in retrieved content that ask for broader access.

For each test, define the expected outcome before running it. Capture whether execution was prevented and whether the record explains what happened.

Distinguish "the model declined" from "the tool or execution layer denied the operation." Both are useful observations. The latter is the stronger evidence that a permission boundary is enforced.

Where our own product lands on this

EMS, the Employee Management System in Adaptive IP Services' Hub division, uses a conservative boundary for outbound activity: a human approves every outbound action.

EMS lets organizations onboard and manage AI virtual employees for sales, marketing, and support. Each virtual employee is isolated and has a role. It pairs with the CRM to support an acquisition loop.

In the framework above, that per-role approval-gate model puts human review at the point where work leaves the organization. It is a concrete answer to the outbound-permission question, with an explicit review burden attached.

That description does not settle every implementation question. Buyers should still use the checklist above to examine data scope, internal changes, approval behavior, and enforcement. Those are evaluation criteria, not additional EMS capability claims.

Write the policy before the pilot

Choose one role and one bounded workflow. List every operation it needs, classify the consequences, and name the reviewer for anything requiring approval.

For each allowed operation, document its scope and failure behavior. For each approval gate, specify exactly what the human must see and what changes invalidate approval. Then run the failure tests before introducing real recipients or consequential records.

The policy is ready when another person can use it to predict which actions will execute, which will wait, and which will be denied.

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

David J. Boggs
Founder and CEO, Adaptive IP Services

Learn more about EMS

Your SOP Is Probably Wrong. Build a Way to Notice.

David Boggs — Wed, 16 Sep 2026 14:04:09 +0000

Your SOP Is Probably Wrong. Build a Way to Notice.

An SOP can look finished long after it stops describing the work.

The screenshots still load. The numbered steps still make sense in isolation. But a permissions change means step 6 no longer works, so experienced staff use a workaround. New hires discover that workaround by asking someone. The document stays untouched because updating it feels like a separate project.

That is how process documentation becomes actively misleading. Nobody needs to decide to neglect it. Keeping the process running simply takes priority over describing it again.

The useful question is not "How do we get everyone to write more documentation?" It is "How do we make changes visible, cheap to document, and worth reviewing?"

Start with one frequently used procedure. Put it through the following maintenance loop before buying another documentation tool.

1. Capture the task while someone actually performs it

Writing an SOP from memory creates two jobs: reconstructing the work and explaining it. Reconstruction is where important details disappear.

An experienced operator remembers "grant access." They may not remember to document which request establishes authorization, which account they use, or how they verify the resulting permissions. Those details feel obvious to someone who performs the task every week.

Capture an actual execution instead.

Choose a representative case with a clear starting condition. For example, document granting an approved user access to an internal application. Start with the approved request visible, using sanitized data or a test environment where appropriate.

Ask the operator to narrate decisions as they work:

What makes this request eligible to proceed?
Why are they selecting this role?
What would make them stop and ask for clarification?
How will they know the change worked?

A recording preserves what happened on screen. Narration helps explain why it happened. Neither guarantees that the process is correct.

The operator may take an unnecessary detour or demonstrate a workaround that should be fixed. Treat the capture as source material for a draft, then have someone responsible for the process review it.

Screen recording also creates a data handling problem. Decide what must stay out of the capture before recording. Avoid exposing credentials, tokens, customer records, or unrelated browser tabs. If production capture is necessary, define who can access the recording and how long it should be retained.

The original recording may contain substantially more sensitive information than the finished SOP.

2. Turn the capture into a procedure someone else can execute

A transcript is not an SOP. Neither is a sequence of screenshots.

The finished procedure needs enough context for a qualified person to know when it applies and whether it succeeded. Use a compact header:

Procedure: Grant access to the internal reporting application
Owner: Application operations lead
Applies to: Standard employees with approved access requests
Does not cover: External users or elevated administrator access
Prerequisites: Approved request; authorized operator account
Revision: 4
Last validated: YYYY-MM-DD
Validated against: Application release/build, if available

Then write steps around observable actions and results.

"Configure the appropriate permissions" leaves the decision undocumented. "Select the role named in the approved request, then verify that the saved assignment matches that role" gives the operator something to do and check.

Include a stop condition wherever continuing could create a bad outcome:

If the requested role is unavailable, stop and return the request
for clarification. Do not substitute a broader role.

Screenshots should help someone locate a control or recognize a result. Do not make them the only place where a critical value or decision appears. Interfaces change, and images are harder to search than text.

Now give the draft to someone who understands the system but did not record the task. Have them execute it on a suitable test case without coaching from the author.

Every question they ask identifies a possible documentation gap. Record those questions instead of answering them verbally and leaving the draft unchanged.

This validation costs time. For a low-impact task, a short walkthrough may be enough. For a procedure that changes production access or can disrupt service, an independent execution is easier to justify.

3. Define what makes the SOP suspect

A review date is useful, but it is a weak detector of change.

A document can become wrong the day after its scheduled review. It can also remain accurate for a year. Age tells you when someone last checked it; it does not tell you whether the underlying process changed.

Give each procedure explicit staleness signals.

Signal	Example	Response
Relevant system change	An application release changes role assignment	Check affected steps before the next use
Execution mismatch	An operator cannot find the documented control	Flag the exact step and assess whether work can continue
Repeated clarification	New hires keep asking which approval counts	Add the missing decision rule
Unrecorded workaround	Staff routinely skip a step to complete the task	Investigate the workaround and revise the procedure or process
Ownership change	The responsible team changes	Assign a new owner and confirm scope
Elapsed review interval	No validation has occurred within the chosen interval	Revalidate based on the task's risk and frequency

These are operating rules you can implement with an issue tracker and a document repository. They do not require a specialized platform.

Make reporting a mismatch cheaper than fixing the whole document. A useful report can be four fields:

SOP and revision:
Step that differed:
What I observed:
Did I stop, continue, or use a workaround?

Do not require the person doing urgent work to rewrite the SOP before they can report a problem. That requirement encourages silence.

The owner should then decide whether the mismatch is cosmetic, confusing, or unsafe. A renamed button may need a small correction. A missing authorization check may require suspending use until the procedure is fixed.

Mark unresolved problems where readers will see them before starting. A comment buried below the procedure is a poor warning system.

4. Separate learning evidence from execution evidence

"Can we prove someone followed the SOP?" sounds straightforward. It contains several different questions.

Opening a document shows access to it. Passing a quiz can provide evidence of understanding. Neither establishes that someone followed the procedure during a particular task.

Even a checked box usually establishes only that someone attested to completion.

For a specific execution, decide what evidence matters before designing the checklist. In the access example, that might mean linking the approved request to the resulting role assignment and recording who performed the change.

A minimal execution record could contain:

Work item:
SOP identifier and revision used:
Operator:
Execution date/time:
Required verification result:
Evidence reference:
Exception or deviation:

The revision matters. If the SOP changes next week, a record that links only to the latest document leaves you guessing which instructions applied.

Choose evidence that supports the claim you need to make. A screenshot may show a result at one moment. An application audit event may establish that an account made a change. Neither necessarily explains whether the operator checked authorization first.

For higher-impact work, combine evidence from the work request and the target system where practical. Preserve the sequence when sequence matters.

Avoid collecting a recording of every execution by default. Recordings take time to review and can accumulate sensitive data. A narrowly scoped system event or verification result may provide better evidence with less exposure.

No practical record proves every thought or action. Be precise about what your evidence establishes and what it leaves uncertain.

5. Make updating part of the change itself

If an application change alters a documented workflow, documentation review belongs in that change's completion criteria.

Add a question to the existing change record:

Which SOPs are affected, and what validation supports leaving
them unchanged or publishing a new revision?

"Documentation updated" is easy to check without thinking. Asking for affected procedures and validation creates a more useful review.

Keep the maintenance effort proportional to the change. A moved control may need one replacement screenshot and a revised instruction. A changed approval model needs a review of the decision logic, prerequisites, and execution evidence.

Recording the changed portion can help, but someone still needs to check that it fits the rest of the procedure. Otherwise, locally accurate edits can leave contradictory instructions elsewhere.

Assign ownership to a role with a named current assignee. "The team owns it" often means nobody has an explicit obligation to resolve reported defects.

Reserve time for that obligation. Faster drafting will not solve a queue of unreviewed changes.

Try the loop before evaluating software

Run a small pilot on one procedure that people already use.

Capture it during execution, validate the draft with another operator, and identify its staleness signals. On the next few executions, record which revision was used and whether anyone needed undocumented help.

Track the effort to produce a usable draft and the effort to correct it after a real change. Note where people abandon the prescribed workflow.

A growing library is not necessarily progress. Fewer unresolved mismatches and less dependence on verbal workarounds are more useful signs that the documentation is serving its purpose.

When evaluating tools, repeat the pilot with the same procedure. Test how easily you can correct a bad draft, replace an outdated step, and find the procedure using the words an operator would actually search for. Ask vendors to demonstrate any revision history or execution evidence capabilities you require.

Where our own product lands on this

Adaptive Cadence addresses the capture and drafting part of this problem. Screen-record a task and it drafts numbered steps with screenshots and the transcribed voiceover, turning operational knowledge into documented, searchable SOPs.

It also includes training quizzes, a manager coaching dashboard, and a department knowledge hub. You can deploy it on your own hardware or have us host it.

The practical fit is reducing the work between performing a task and producing documentation someone can review. Quizzes and coaching can support training, but should not be treated as proof that a particular execution followed an SOP.

You still need an owner, a way to detect changed behavior, and evidence appropriate to the task. Make those requirements explicit when evaluating Cadence.

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

David J. Boggs
Founder and CEO, Adaptive IP Services

Adaptive Cadence

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.