The Ops Community ⚙️: lida0407

Does Your Client Have a Right to Know You Used AI?

lida0407 — Wed, 26 Aug 2026 18:19:44 +0000

Lawyers use technology constantly without giving clients a tool-by-tool disclosure. Firms do not normally announce that a lawyer used Westlaw, spell-checking, document comparison software, e-discovery tools, or a spreadsheet.

Should generative AI be different?

The American Bar Association's Formal Opinion 512 does not create a universal rule requiring lawyers to tell clients every time generative AI is used. It says disclosure and informed consent may be required depending on how the tool is used, particularly where client information is being provided to systems that create confidentiality risks or where the client's instructions require communication. The ABA opinion also emphasizes competence, supervision, candor, and reasonable fees.

That gives firms room to use AI. It also means “we never disclose AI” is too simple a policy.

The tool itself is not always the material fact

Suppose a lawyer uses an approved enterprise AI system to summarize a long internal document, verifies the output against the original, and uses the summary only as a working aid.

The client may not need a special notification any more than the client needs to know which search interface the lawyer used.

Now change the facts.

The lawyer uploads confidential client material to a consumer AI service with uncertain retention terms. Or uses an AI system to perform a substantial part of an analysis the client expected a specialist to perform personally. Or passes a separate AI charge through to the client. Or agrees to a client guideline prohibiting specific AI tools.

In each case, AI use becomes more material.

The disclosure question should therefore follow the risk and the engagement, not the novelty of the software.

Confidentiality is the first test

Law firms should start with the information being processed.

MIRA's guide to attorney-client confidentiality emphasizes that the duty extends broadly across client-related information, including technology workflows. If a tool receives sensitive material, the firm needs to understand its security, retention, access, training, and contractual controls.

A client may reasonably care whether confidential information leaves the firm's controlled environment or becomes available to a third-party model provider.

Disclosure is particularly important when the lawyer cannot confidently conclude that the intended use is consistent with confidentiality obligations.

Billing is the second test

AI creates unusual billing questions because it can compress work.

If a client is billed hourly, the firm should not charge fictional time that the lawyer did not spend. If the firm charges separately for AI tools, the client should understand the basis for the charge. If the work is priced as a flat fee, the engagement should still comply with applicable reasonableness and communication requirements.

Accurate legal billing descriptions remain useful here. The narrative should tell the client what legal work was performed without exposing unnecessary confidential detail or using vague technology language to disguise the nature of the service.

The client is buying professional legal work. AI should not become a mechanism for making that work harder to understand.

Client instructions can settle the issue

Some clients will set explicit AI policies.

Corporate legal departments may prohibit certain consumer tools, require prior approval for processing confidential information, mandate specific security terms, or ask firms to disclose material AI use. Other clients may actively prefer AI-enabled workflows because they want lower costs and faster turnaround.

Those instructions should become part of matter governance.

A firm that can explain its AI architecture, review process, approved tools, confidentiality controls, and billing approach will be in a stronger position than one relying on an informal “everyone uses it now” assumption.

Routine AI will become less remarkable, accountability will not

Eventually, generative functions will be embedded so deeply into legal software that a binary “AI used: yes or no” disclosure may become meaningless.

The enduring questions are more practical.

Did the technology create a material confidentiality risk? Did it change the service the client reasonably believed it was buying? Did it affect fees? Did client instructions require disclosure? Was a lawyer still responsible for checking the work?

When the answer to one of those questions is yes, the client may have a legitimate right to know.

AI can become routine without becoming invisible where it matters.

Originally published on the MIRA blog.

When Does AI Timekeeping Become Lawyer Surveillance?

lida0407 — Wed, 26 Aug 2026 14:21:24 +0000

Law firms have a legitimate timekeeping problem. Lawyers move rapidly between email, calls, documents, meetings, research, messaging, and matter systems. Work gets fragmented, timers are forgotten, and reconstructing a day at 8 p.m. is unreliable.

Passive capture promises a better approach: use activity from approved business systems to help lawyers remember work and prepare time entries for review.

But there is a nearby technology category that looks much less benign: employee surveillance.

The distinction matters because workplace monitoring is expanding. An August 2026 Associated Press report described employers using digital and AI-driven systems to track communications, activity, productivity, and behavior, sometimes with limited transparency. The AP report illustrates why employees increasingly treat monitoring technology as a trust issue.

Legal timekeeping software should not assume it is exempt from that concern simply because its stated purpose is billing.

Capture and surveillance answer different questions

A useful passive time system asks, “What client work might this lawyer have forgotten to record?”

A surveillance system asks, “What was this employee doing, and were they productive enough?”

Those questions may use some of the same raw signals, but they create very different products.

A privacy-conscious passive time capture workflow should identify matter-related activity, organize it into useful suggestions, and place the lawyer in control of review. It does not need to score keystrokes, judge idle time, record screens continuously, or turn every digital trace into a management metric.

The closer a system moves toward behavioral scoring, the harder it becomes to describe it as merely a better timekeeping tool.

Law firms have additional reasons to be cautious

Ordinary workplace monitoring already raises privacy and trust concerns. Law firms also handle client confidential information.

A system that observes documents, emails, calendar events, calls, or browser activity may encounter sensitive matter details. That means architecture, retention, access controls, data minimization, and vendor practices become professional-risk questions, not just IT preferences.

The firm should know what data is captured, where it is processed, how long it is kept, who can see it, whether it is used to train models, and what happens to excluded or personal activity.

Lawyers should understand those boundaries too.

Invisible monitoring is a poor foundation for technology that depends on adoption.

Review control is the critical boundary

Passive capture works best when it behaves like memory assistance.

The software can suggest that a lawyer spent time drafting a document, participating in a client call, or corresponding about a matter. The lawyer then decides whether the activity was billable, confirms the matter, edits the description, adjusts the duration if appropriate, and approves the entry.

That workflow is consistent with good legal timekeeping practices because technology helps collect activity without eliminating professional judgment.

Automatic billing is much riskier. Context matters. A calendar event does not prove the entire meeting was billable. An open document does not prove continuous work. An email thread may span several matters or include administrative activity.

Capture can be automated more safely than judgment.

Firms should create a surveillance boundary before deployment

A useful policy should state what the system is for and what it will not be used for.

For example, the firm may use passive activity to help create time-entry suggestions but prohibit employee productivity scoring based on mouse movement, keyboard activity, or time spent in applications. Access to underlying activity can be limited, and personal or excluded systems can remain outside capture.

The purpose limitation matters because tools tend to expand once data exists.

A system introduced to recover missed billable time can gradually become a performance dashboard if governance is weak.

Better timekeeping should reduce friction, not create fear

The strongest argument for passive capture is that lawyers should spend less cognitive energy remembering timers and reconstructing their day.

If implementation makes people feel watched continuously, the firm has solved one workflow problem by creating another cultural one.

AI timekeeping becomes surveillance when the technology stops helping professionals document work and starts evaluating people through behavioral traces they cannot meaningfully control.

That boundary should be designed before rollout, not debated after trust has already been lost.

Originally published on the MIRA blog.

Starcloud Raises $250 Million as Orbital Data Centers Move From Concept Toward Infrastructure

lida0407 — Mon, 24 Aug 2026 18:57:13 +0000

Starcloud has raised another $250 million to pursue one of the most ambitious ideas in AI infrastructure: putting substantial compute capacity in orbit. TechCrunch reported on August 21, 2026 that the new capital extends the company’s March Series A and values Starcloud at $2.3 billion. The company says the funding will support manufacturing expansion and development of its larger Starcloud 3 spacecraft, which is intended to fly on SpaceX’s Starship.

The idea is attractive because data centers on Earth face increasingly visible limits around power, land, permitting and cooling. Space offers continuous solar energy in some orbital designs and removes the need to reject heat into a local community. But orbital computing creates a different set of physical constraints. Sensaka’s AI data center operations guide is written for terrestrial facilities, yet its core lesson still applies: compute is useful only when power, thermal control, networking, hardware health and recovery operate as one system.

Space changes the cooling problem but does not remove it

A terrestrial data center transfers heat through air, water, refrigerant or liquid cooling loops and then rejects that heat into the surrounding environment. In orbit there is no atmosphere to carry heat away through convection. A spacecraft must ultimately radiate heat into space.

That makes thermal engineering central to the economics of orbital compute. High performance accelerators create large amounts of heat in a compact area. Radiators need surface area, mass and reliable orientation. Pumps and coolant loops become difficult to service after launch. A failed component cannot be replaced by a technician walking into the data hall.

Sensaka’s guide to liquid cooling in data centers shows how flow, pressure, temperature, pumps and leak detection already expand the monitoring burden for dense AI racks on Earth. An orbital system inherits many of those concerns while adding radiation, launch vibration, vacuum and remote maintenance constraints.

Launch capacity becomes part of data center capacity

TechCrunch reported that one reason Starcloud is raising capital now is to secure future launch access. That detail is important because launch is effectively the construction logistics layer of an orbital data center. A terrestrial operator can deliver servers by road and replace them repeatedly. An orbital operator must reserve rocket capacity, survive launch and accept much longer replacement cycles.

This changes the meaning of capacity planning. On Earth, teams consider racks, power, cooling and network availability. In orbit, the planning model also needs spacecraft mass, launch cadence, orbital position, communication bandwidth and replacement strategy.

The broader principle is familiar. Sensaka’s data center capacity planning guide argues that physical space alone does not equal usable capacity. Orbital computing makes that point even stronger. A satellite can carry processors yet still be constrained by power generation, radiator area, communications or launch availability.

Network economics may decide which workloads belong in orbit

Not every AI workload needs to move large amounts of data continuously. Some inference jobs could be performed close to data already collected in space, such as Earth observation imagery. Other workloads may be less attractive if they require constant transfer of large datasets between terrestrial storage and orbital compute.

Latency, bandwidth and ground station availability therefore become part of workload selection. The strongest early use cases may be workloads where the data source is already in orbit or where the value of processing near the source outweighs the cost of moving information back to Earth.

This suggests that the phrase data center in space can be misleading if it encourages a direct comparison with a conventional hyperscale campus. The first successful systems may behave more like highly specialized remote compute platforms than like replacements for terrestrial cloud regions.

The funding is meaningful because it finances physical proof

Starcloud has already demonstrated an Nvidia H100 in orbit through its earlier spacecraft. The new funding gives the company more resources to move from a demonstration toward larger operational systems. That is the stage where infrastructure claims become measurable.

The most useful evidence will include compute performance, power availability, thermal stability, radiation effects, network throughput, hardware failure rates and the cost of deploying and replacing capacity. Those metrics will determine whether orbital compute can compete economically with terrestrial infrastructure for specific workloads.

The $250 million extension does not prove that space based data centers will become mainstream. It proves that investors are willing to fund the engineering required to find out. As AI infrastructure runs into tighter physical constraints on Earth, even unconventional locations are becoming part of the capacity conversation.

Originally published on the Sensaka blog.

Texas Data Center Interconnection Pause Extends Toward December as ERCOT Audits the AI Boom

lida0407 — Mon, 24 Aug 2026 18:41:04 +0000

Texas is moving deeper into its review of large data center projects connected to the state power system. Utility Dive reported on August 21, 2026 that the Electric Reliability Council of Texas intends to complete a broad audit by December 10. The review follows Governor Greg Abbott’s August 3 call for a moratorium on new data center interconnections until questions about electricity, water and public financial support can be answered.

The headline number is extraordinary. ERCOT’s interconnection queue contains about 474 gigawatts of requests, and Abbott said roughly 90 percent of new power requests are associated with data centers. That does not mean 474 gigawatts of projects will be built. It shows how difficult it has become for utilities to separate serious demand from speculative or duplicated requests. Sensaka’s guide to data center capacity planning describes the facility level version of the same problem: nominal capacity is less useful than capacity that can actually be powered, cooled and operated.

The audit is about project credibility as much as electricity

ERCOT is reviewing hundreds of large proposed facilities and asking developers for more information. Utility Dive reported that around 300 data centers of 75 MW or larger are navigating the Batch Zero process. Community impact reviews will also apply to data centers and crypto facilities of 25 MW and above.

The state wants to know how much electricity projects expect to use, whether they plan to provide their own generation, how much water they need and whether they depend on public incentives. Those questions turn a data center proposal into a broader infrastructure commitment. A campus is no longer evaluated only on land, financing and customer demand. It must also explain its relationship with the grid and the surrounding community.

This makes power modeling central to development. Sensaka’s data center power calculator illustrates the basic relationship between device load, current and continuous operating limits. At utility scale the same discipline applies, although the numbers involve substations, transmission and generation rather than rack circuits.

The queue shows the difference between requested and usable capacity

Large interconnection queues can exaggerate future demand because developers may submit requests for several possible sites or reserve capacity before financing and customers are fully committed. Utilities still have to plan for the possibility that some projects are real, because transmission and generation can take years to build.

Texas is therefore trying to establish which loads are credible enough to shape long term planning. The delay matters because a data center can complete other parts of its development while waiting for certainty about energization. That creates financial risk for developers and their suppliers.

Inside a facility, a similar mismatch produces stranded capacity. A hall may have open rack positions but no remaining power or cooling headroom. Sensaka’s overview of data center management connects power, cooling, assets and operational capacity because each limit changes what the building can actually support.

Water and community impact are moving onto the critical path

Texas is also asking data centers to explain water consumption and whether they will rely on supplies needed by local communities. This matters because cooling design can shift the balance between water and electricity use, especially in large AI deployments.

Community impact is becoming harder to separate from technical design. A project may need new transmission infrastructure, backup generation, water systems and road access. Residents may care about noise, land use and utility prices as much as the developer cares about latency and fiber routes.

For data center companies, those concerns should be treated as project dependencies. Cooling architecture, site design and power strategy can influence approval timelines. Transparent operating data can also become useful evidence when regulators want to understand whether promised efficiency or demand management measures are actually working.

December will not necessarily end the planning problem

ERCOT’s target is to deliver a comprehensive report around December 10, but Utility Dive reported that the original Batch Zero study timeline is already unlikely to hold. Grid officials said they do not yet know how much the audit will shift the next stages of interconnection review.

That uncertainty is the larger lesson. AI investment can move faster than transmission planning, power plant construction and public approval. Developers may have capital and customers while the physical infrastructure underneath the project remains unresolved.

Texas is still likely to remain one of the most important United States data center markets. The current pause shows the condition attached to that growth: projects will increasingly need to prove that their requested capacity is credible, supportable and compatible with regional infrastructure. In the AI era, the ability to demonstrate usable capacity may become as important as the ability to announce it.

Originally published on the Sensaka blog.

Claude Opus 5 Deleted a User Profile During a Backup Task: The Real Lesson Is Recovery Design

lida0407 — Mon, 24 Aug 2026 18:33:51 +0000

A developer asked Claude Opus 5 to create a system backup. According to an August 7, 2026 Tom’s Hardware report, the AI agent confused a Unix-style Windows path with a temporary backup location and then executed a destructive rm -rf command against the user’s profile directory. The story is memorable because the error was dramatic. The more useful lesson is architectural. When an AI agent can create backups, move files and run shell commands, it is operating with the same kind of privileges that can destroy the data it is supposed to protect. That means backup strategy cannot depend on the assumption that the automation layer will always make the correct decision. Mr.PlanB’s guide to the 3-2-1-1-0 backup rule is relevant here because it adds an offline or immutable copy and requires zero unverified backup errors. Those controls are valuable precisely when the active system or the automation touching it behaves unexpectedly.

The failure was a permissions problem as much as an AI problem

The reported mistake involved path interpretation. The agent was operating in a Unix-style shell on Windows and treated /c/Users/ differently from the conventional C:\Users\ path it expected. It then attempted to clean up what it believed was an incorrectly placed temporary backup. A human can make a similar mistake. Scripts can make similar mistakes. The difference with an agent is that it can generate and execute commands dynamically, sometimes moving from diagnosis to remediation without a separate approval step. That makes permissions one of the most important design controls. An agent performing a backup does not automatically need unrestricted deletion rights across the source filesystem. It may need read access to production data and write access to a defined backup target, while destructive operations should require a separate workflow. The principle is familiar from infrastructure automation: give a process the minimum authority required for the task. AI does not remove that principle. It makes the principle more important because the command sequence is less deterministic than a reviewed script.

A backup workflow should survive the tool performing the backup

The incident also exposes a common weakness in backup design. Teams sometimes treat the backup application as part of the same trust domain as production. If the backup software, automation account or administrative shell can delete both the source and all recovery copies, then a single credential or mistake can collapse the entire protection model. Mr.PlanB’s guide to offsite backup explains why a recovery copy should live in a separate failure domain. The separation can be geographic, administrative, technical or all three. The important part is that damage to the production environment should not automatically extend to every copy needed for recovery. Immutable object storage, hardened repositories, offline media and independently controlled backup accounts are different ways of creating that separation. None is perfect, but each reduces the chance that one destructive command can erase the production data and its last usable recovery point. For AI-assisted operations, the same logic suggests that agents should not hold standing credentials to every backup tier. They can help prepare jobs, review logs, explain failures and even trigger approved workflows without being able to destroy protected copies.

Successful backup jobs are not evidence of recoverability

The user in the reported incident was trying to create a backup, but the task itself became destructive. That is a reminder that backup status and recovery readiness are different measurements. A green job can still contain incomplete files, inconsistent application state, inaccessible encryption keys or a recovery process that takes far longer than the business can tolerate. Conversely, a failed production system can still be recoverable if protected copies are isolated and regularly tested. Mr.PlanB’s guide to backup testing recommends validating recovery through file restores, application recovery, isolated environments and full system scenarios. The objective is to prove that the organization can recover, not simply that data was copied somewhere. AI agents can assist with this work. They can summarize job logs, compare retention policies, generate runbooks and help identify failed verification tasks. The safer use case is to augment a controlled recovery process rather than let an agent improvise destructive changes directly against irreplaceable data.

Destructive commands need a different control path

One practical response to agentic operations is to distinguish reversible actions from irreversible ones. Reading a directory, creating a new backup folder and generating a report have very different risk profiles from recursive deletion, disk formatting or deleting a snapshot chain. A production workflow can treat those categories differently. Low-risk actions may run automatically. High-risk actions can require an explicit user confirmation, a second credential, a policy engine or a pre-execution check that confirms the target path and available recovery points. This is not unique to Claude. Any coding agent or operations agent with shell access can create the same category of risk. The model may improve, but organizations should not build safety around the expectation that path interpretation, intent recognition and generated commands will be perfect. The stronger architecture assumes that eventually something will issue a bad command and limits the blast radius before it happens.

Backup is only one part of disaster recovery

Even a clean restore is not the end of recovery. Systems depend on identities, network configuration, application order, storage, DNS, secrets, dependencies and people who know what to do next. Mr.PlanB’s guide to building a disaster recovery plan connects backup copies with service priorities, roles, contact paths, recovery objectives and runbooks. That broader structure matters when an automated action damages more than one directory or when the production environment itself is no longer trustworthy. The Claude Opus 5 incident should therefore be read as an operations warning, not a reason to avoid AI tools completely. Agents can automate repetitive administration and make technical workflows easier to operate. They should still be placed inside the same control framework used for any powerful administrative system. Give the agent a defined workspace. Separate source data from protected recovery copies. Restrict destructive privileges. Require additional controls for irreversible commands. Test restores independently. The safest backup system is one that can recover even after the tool performing the backup makes the worst reasonable mistake.

Originally published on the Mr.PlanB blog.

75% of Americans Oppose a Data Center Near Home. The Industry Has a Trust Problem

lida0407 — Sat, 22 Aug 2026 11:36:22 +0000

A new poll has turned the social side of the data center boom into a number that infrastructure developers cannot easily ignore. Heatmap reported on August 20, 2026 that 75% of registered voters surveyed would oppose a new data center near where they live, with more than six in ten saying they would strongly oppose it. The survey covered 2,045 registered voters across all 50 states and Washington, D.C. and was conducted by Embold Research from August 8 to August 13.

The direction of travel may matter more than the exact percentage. Heatmap has asked the same question several times over the past year and reported a sharp deterioration in local support. Other surveys use different samples and wording, so they produce different numbers. An Annenberg Public Policy Center survey published in August found 61% opposition to local data center construction, up from 49% earlier in the year. The figures are not identical, but the message is consistent: a growing share of Americans are uncomfortable with large data center projects close to home.

For infrastructure teams, this adds a new constraint to the familiar list of land, power, cooling, network access and construction. Sensaka's guide to data center capacity planning focuses on usable capacity across space, power and cooling. The latest polling suggests that community acceptance increasingly belongs in the same planning conversation because a technically viable site can still face political or permitting resistance.

The objection is increasingly about local resource tradeoffs

Public resistance cannot be reduced to a simple dislike of technology. Recent polling and reporting repeatedly point to electricity demand, water use, utility bills, noise, land use and the perceived distribution of economic benefits. A resident may support artificial intelligence in general while still questioning whether a nearby facility will increase pressure on the local grid or consume resources that are already scarce.

That distinction matters because many arguments used to defend data centers operate at the national level. Developers can point to economic growth, AI leadership, cloud capacity, digital sovereignty and construction investment. Local residents experience a different set of questions. They want to know who pays for grid upgrades, whether power prices could rise, what happens to water demand, how much permanent employment remains after construction and whether tax benefits justify the physical footprint.

The gap between national benefit and local cost is becoming a central problem for the industry. If the project narrative focuses only on compute capacity or investment value, it can sound disconnected from the concerns that determine whether a project earns local support.

Community acceptance is becoming part of site selection

Data center site selection has traditionally emphasized measurable engineering and commercial factors. Power availability, fiber routes, land cost, latency, tax incentives and climate conditions can all be scored. Community resistance is harder to model, but developers may increasingly need to treat it as a project risk rather than a communications issue that begins after a site has already been chosen.

That means due diligence should include local electricity conditions, water stress, housing and land pressures, existing industrial development, political sentiment and the credibility of promised community benefits. A county that looks attractive because it has inexpensive land and a nearby transmission corridor may become less attractive if residents believe the project threatens their energy costs or quality of life.

The industry also needs to distinguish between concerns it can address and objections it cannot simply message away. Better explanations may help when people lack information about how a facility operates. They will not solve a real grid constraint, an unfavorable utility cost allocation or a water problem. Trust improves when project design changes in response to valid concerns, not only when the public relations campaign becomes more polished.

Operators will need to show measurable local value

The next generation of successful projects may need a clearer local compact. That could include transparent power procurement, credible water strategies, noise limits, infrastructure investment, tax commitments, workforce development and public reporting after the facility opens. The exact package will differ by region, but the principle is straightforward: communities increasingly expect to understand the exchange they are being asked to make.

This will also put more pressure on operational data. Claims about efficiency are more persuasive when developers can show measured energy use, cooling performance and progress against stated targets. A promise made during planning has limited value if the operator cannot later demonstrate what happened in practice.

The 75% figure should not be treated as a universal measure of American opinion. It is one poll, and other surveys report different levels of opposition. It should, however, be treated as a warning. Data center growth now depends on more than finding power and land. The industry also has to earn permission to build.

Originally published on the Sensaka blog.

AI Adoption Is Becoming a Governance Question

lida0407 — Wed, 19 Aug 2026 19:57:19 +0000

AI Adoption Is Becoming a Governance Question

Colorado’s newly published draft rules on automated decision making technology and conversational AI highlight a larger shift in the AI market.

The discussion around enterprise AI is moving beyond capability.

Organizations increasingly need to think about how AI systems make decisions, what data they use, how outcomes are reviewed, and what controls exist when something goes wrong.

For law firms, this matters because AI adoption is expanding into workflows that touch confidential information, client service, internal operations, and professional accountability.

The more deeply AI becomes embedded in everyday work, the less useful it is to evaluate these systems only by asking whether they save time.

Firms also need to ask who can access the data, how recommendations are generated, whether outputs can be reviewed, how errors are corrected, and what happens when the technology becomes part of a critical workflow.

That applies to many categories of legal technology, including platforms such as MIRA that support operational processes around lawyers’ work.

The legal AI market is therefore entering a more mature stage.

The winners may not simply be the tools with the most impressive AI capabilities. They may be the tools that combine useful automation with clear controls, transparency, and confidence for the organizations deploying them.

"Contracts Are Becoming Connected to Live Data: The Next Step for Legal Operations"

lida0407 — Wed, 19 Aug 2026 19:08:54 +0000

A contract is accurate when it is signed, but the business environment around it keeps changing. Vendors add subprocessors, products introduce AI features, data flows move and teams adopt new applications. An August 17 SpotDraft announcement describes a planned integration with Mine that is intended to connect contract information with live privacy, vendor and technology governance data. The SpotDraft and Mine partnership is designed to move information in both directions.

SpotDraft says relevant contract terms can provide context for assessments inside Mine, while Mine’s inventory of systems, vendors and AI enabled tools can help legal teams identify relationships that may not match an existing contract record. The idea is to connect what the organization agreed to with what is actually operating across the business.

That same context problem appears throughout legal operations. MIRA’s guide to attorney client confidentiality explains why legal obligations extend across communications, systems, billing records and technology workflows. A policy or agreement has limited operational value if the people making day to day decisions cannot see the relevant obligation when they need it.

Contracts are becoming operating data

Traditional contract management often focuses on drafting, negotiation, signature, storage and renewal. Those stages remain important, but many obligations matter long after signature. Data retention terms, security commitments, geographic restrictions and AI use provisions can affect operational decisions months or years later.

The problem is that the contract and the system it governs may live in different places. Legal sees the agreement. Security sees the application. Privacy sees the assessment. Procurement sees the vendor relationship. Each function has only part of the context.

Connecting these records turns a contract from a static document into a source of structured operating information. Teams can ask whether the live environment still matches the negotiated terms rather than waiting for a renewal or incident to expose the gap.

Integration can reduce repeated legal administration

The SpotDraft announcement also highlights a common source of legal operations waste: repeatedly gathering information that already exists. A privacy assessment may ask questions that were answered during contract negotiation. Legal may search for an agreement that procurement already knows about. Security may discover a new AI feature without immediate visibility into the contractual restrictions that apply.

Connected systems can reduce that repeated work by presenting existing context at the right point in the process. The same principle is important in timekeeping. MIRA’s guide to missed billable hours explains how fragmented systems and delayed reconstruction create operational and financial leakage. The solution is often less about asking people to remember more and more about making existing information available when the task occurs.

Live context also increases the need for controlled access

More integration creates more useful context, but it also creates a larger information surface. Firms and legal departments need to understand which systems can read contract terms, vendor information and matter data, and which users can act on that information.

Automation should also preserve the distinction between evidence and decision. A system may identify that a vendor has no matching agreement or that a new tool appears inconsistent with an existing record. A responsible person still needs to determine what that means and what action should follow.

MIRA’s legal timekeeping software checklist provides a useful evaluation pattern because it combines integrations, security, confidentiality, administration and workflow fit. The same questions apply to connected contract and governance systems.

The larger direction is clear. Legal operations is moving toward systems that maintain context across the life of a relationship rather than treating every task as a separate transaction. Contracts can become one layer of that operating context, connected to the real systems, vendors and actions they are supposed to govern.

Originally published on the MIRA News and Blog.

"Proxmox Hosting Automation Gets More Serious: What WHMCS Integration Means for Service Providers"

lida0407 — Tue, 11 Aug 2026 08:15:10 +0000

ModulesGarden is now listed by Proxmox as a Solution Provider, bringing fresh attention to something hosting companies have been building around Proxmox for years: the business layer above the hypervisor.

The company's current Proxmox and WHMCS portfolio covers automated VPS provisioning, cloud management, reseller workflows, usage based billing, IP management, monitoring, backup scheduling, and other hosting operations. The significance is larger than one vendor integration. It shows that Proxmox adoption is creating demand for the surrounding systems required to turn virtualization capacity into a repeatable service.

For infrastructure teams, this is where Proxmox automation becomes commercially important. An API can create a VM. A service provider needs a complete process that can take an order, apply policy, allocate resources, configure networking, protect the workload, expose approved controls to the customer, meter usage, and eventually retire the service cleanly.

Hosting automation is more than VM creation

Provisioning is the most visible step because it is easy to demonstrate. A customer purchases a VPS and a virtual machine appears. The difficult work sits around that moment.

A hosting platform needs to decide where the VM should run, which template is permitted, how much CPU and memory it receives, which storage class it uses, how IP addresses are allocated, what firewall defaults apply, how backups are scheduled, and what actions the customer can perform. The platform must also handle upgrades, suspensions, cancellations, failed provisioning tasks, and infrastructure maintenance without losing track of state.

This is why a billing system integration can become an operational control plane. It connects customer intent to infrastructure actions. That connection is useful, but it also creates a risk boundary. A mistake in automation can affect many customers faster than a manual mistake.

Service providers therefore need the same disciplines used in infrastructure as code: controlled credentials, validation, idempotent operations, logs, rollback procedures, test environments, and change management.

The Proxmox API is becoming part of the product surface

Proxmox provides a REST API, command line tooling, API tokens, and support for automation approaches including Ansible, Terraform, OpenTofu, templates, and cloud init workflows. For an internal IT team, these capabilities improve consistency. For a hosting company, they can become part of the customer product.

That changes the design requirements. Internal automation can sometimes tolerate a manual repair after an unusual failure. Customer facing provisioning needs clearer state handling and better observability. A user who pays for a VM expects the service to appear correctly, with the right network, storage, credentials, and controls, without understanding the cluster behind it.

The Proxmox enterprise guide is relevant here because production use requires more than software installation. Subscriptions, support, validated repositories, clustering, storage, backup, security, monitoring, automation, documentation, skills, and governance all become part of the service promise.

Billing and resource policy need to agree

One of the harder problems in infrastructure services is keeping the commercial model aligned with the technical model. A plan may promise four virtual CPUs, a memory limit, a storage quota, backup retention, bandwidth, snapshots, or additional IP addresses. The automation layer must translate those promises into actual infrastructure policy.

Usage based billing adds another layer. The system needs trustworthy measurements and clear definitions of what is being charged. If storage grows dynamically, the billing system and cluster need to agree on the change. If customers can resize services, limits must remain consistent. If a resource is suspended for billing reasons, the action must not corrupt data or break recovery.

This is where hosting automation stops being a collection of scripts. It becomes a state management problem across customer records, billing, Proxmox, networking, storage, backup, and monitoring.

Backup must be part of the service definition

A VPS service that includes backup needs to define more than whether a scheduled job exists. Retention, destination, encryption, verification, restore scope, customer access, and recovery expectations all affect what the service actually provides.

The Proxmox backup guide covers backup jobs, snapshots, storage targets, retention, compression, encryption, Proxmox Backup Server, offsite copies, verification, and restore testing. A hosting provider can use those building blocks, but automation should not hide the operational questions.

If a customer deletes a file, can they restore it themselves? If a node fails, how quickly can the provider recover the full VM? If ransomware affects the guest, are older recovery points still protected? If the backup repository is unavailable, is there an offsite copy? If a restore fails, who owns the incident?

Clear answers should exist before backup becomes a checkbox in a product page.

Multi tenant automation raises the security stakes

Customer facing infrastructure means untrusted users are interacting indirectly with the virtualization platform. That makes permission boundaries essential.

The customer portal should expose only the operations needed for the purchased service. Administrative APIs should use narrowly scoped credentials. Network controls should prevent one tenant from reaching another. Console access, backups, snapshots, ISO images, templates, and IP allocation all need tenant aware rules.

Automation also needs auditability. When a VM is created, resized, rebooted, suspended, restored, or deleted, the provider should be able to trace the action back to a customer request, an administrator, or a system process. This becomes especially important when several systems can initiate changes.

The strongest architecture keeps the public business interface separate from privileged cluster management and uses controlled integration points between them.

The ecosystem is a sign of Proxmox maturity

The emergence of deeper commercial integrations around Proxmox is strategically important because enterprise and hosting adoption depend on ecosystems. Hypervisors rarely operate alone. Organizations need backup, monitoring, billing, networking, automation, migration, hardware support, security, and operational skills around them.

An official Solution Provider focused on WHMCS and hosting workflows is one more indication that the Proxmox market is expanding beyond administrators manually creating VMs in a web interface. The surrounding software is becoming part of the platform decision.

For hosting businesses considering Proxmox, that is useful news, but it should not remove the need for architecture work. Automation can make a well designed service scalable. It can also make a poorly designed service fail at scale.

The right question is therefore not simply whether Proxmox can connect to a billing portal. It can. The more important question is whether the organization has designed provisioning, networking, storage, backup, security, monitoring, and lifecycle operations as one dependable service.

Originally published on the Mr.PlanB blog.

"DeadLock Ransomware Uses Decentralized Recovery Infrastructure: What Backup Teams Should Learn"

lida0407 — Tue, 11 Aug 2026 08:10:04 +0000

Microsoft's August 10, 2026 analysis of DeadLock describes an emerging financially motivated ransomware operation built around a Rust encryptor and decentralized infrastructure for victim communication, negotiation, and data leak activity. The technical details are new, but the infrastructure lesson is familiar: defenders cannot design recovery around assumptions about how an attacker will communicate, where an extortion site will be hosted, or whether a conventional command channel will remain available.

For backup teams, the useful question is not whether DeadLock is more decentralized than earlier ransomware families. The useful question is whether a recovery design still works when production systems, identity services, management interfaces, and online backup paths are under pressure at the same time. A good starting point is the 3 2 1 1 0 backup rule, which adds an offline or immutable copy and zero unverified backup errors to the familiar idea of maintaining multiple independent copies.

Decentralized extortion does not change the recovery objective

DeadLock is noteworthy because Microsoft describes decentralized recovery and communication infrastructure alongside encryption and double extortion. That can complicate disruption and takedown efforts, but it does not change the basic goal for an infrastructure team after encryption begins. The organization still needs trustworthy copies of data, credentials to reach them, clean infrastructure on which to restore, and a tested sequence for bringing services back.

That distinction matters because ransomware discussions often focus on malware behavior while recovery remains treated as a storage feature. Backup software can report successful jobs every night and still leave the organization exposed. A backup is only useful if the data is readable, the repository is reachable during an incident, the necessary encryption keys and credentials are available, and the restore can meet the required recovery point and recovery time objectives.

This is why backup testing deserves the same attention as backup creation. A restore test exposes problems that routine job monitoring can miss, including incomplete application data, broken dependencies, missing credentials, slow transfer paths, insufficient replacement capacity, and procedures that exist only in one administrator's memory.

Separate the backup failure domain from production

Ransomware recovery becomes much harder when production and backup systems share the same administrative boundary. If the same identity account can manage hypervisors, storage, backup repositories, and remote copies, one compromised credential can collapse several layers of protection at once.

The practical goal is failure independence. Backup infrastructure should have its own access controls, restricted management paths, and protected credentials. At least one recovery copy should be resistant to ordinary deletion or modification from the production environment. For Proxmox environments, Proxmox Backup Server can support incremental deduplicated backups, verification, remote synchronization, encryption, pruning, and tape workflows. Those capabilities become valuable when they are designed as a separate recovery system rather than simply another service on the same host.

Physical separation also matters. Running the backup repository on the same server that hosts production workloads may be convenient in a small lab, but it creates an obvious shared failure domain. A hardware failure, administrative mistake, destructive script, or attacker reaching the host can affect both sides. Even a small environment benefits from a second machine, a remote repository, or another location that can survive the loss of the primary platform.

Immutability still needs operational discipline

Immutable or offline storage is one of the strongest defenses against destructive attacks, but it is not a substitute for operational design. Teams still need retention policies, capacity planning, monitoring, key management, and a method to recover data without reconnecting a compromised environment to the protected repository too early.

The same applies to tape. Offline media can create a strong separation from production, but only when teams know what is on each cartridge, how to retrieve it, how long a restore will take, and whether replacement hardware is available. Immutability protects a copy from change. It does not automatically prove that the copy contains everything the business needs.

A mature ransomware recovery plan therefore connects backup storage with a disaster recovery plan. The plan should establish service priorities, dependencies, roles, communications, recovery objectives, clean room requirements, and the order in which infrastructure and applications return. During a real incident, those decisions become much harder if they have not already been made.

Verification should be treated as evidence

A successful backup job proves that a process wrote data somewhere. It does not prove that the resulting backup can restore a complete service.

Verification narrows that gap. Integrity checks can detect damaged backup content before the day it is needed. Periodic file restores prove basic access. Application restores show whether databases, configuration, identity, network dependencies, and attached storage come back together. Full recovery exercises reveal whether the organization has enough compute, storage, network capacity, time, and people to rebuild after a destructive event.

For virtual environments, this is especially important because a workload may depend on more than the main virtual disk. Boot configuration, virtual TPM state, network settings, attached storage, application secrets, external databases, DNS, and authentication can all determine whether a restored VM is actually usable. The recovery test should validate the service, not simply whether a virtual machine reaches a powered on state.

Ransomware resilience is an architecture problem

DeadLock is another reminder that attackers continue to change the infrastructure around ransomware operations. Defenders should expect the tooling, encryption methods, negotiation channels, and extortion techniques to evolve.

Recovery architecture can be more stable. Multiple independent copies, restricted backup credentials, an offline or immutable layer, offsite protection, integrity verification, restore testing, and documented recovery sequencing remain useful even when the ransomware family changes.

For Proxmox operators, the Proxmox backup guide is a practical place to review backup jobs, storage targets, retention, Proxmox Backup Server, offsite copies, verification, and restore testing as one system. The strongest design is the one that assumes production may be unavailable and still gives the team a known path back.

The useful lesson from DeadLock is therefore broader than one malware family. Do not design recovery around how yesterday's ransomware worked. Design it around what the business must still be able to restore when tomorrow's attack behaves differently.

Originally published on the Mr.PlanB blog.

Grafana MCP Server and gcx Reach General Availability: AI Driven Observability Gets More Serious

lida0407 — Mon, 10 Aug 2026 21:44:54 +0000

Grafana MCP Server and gcx Reach General Availability: AI Driven Observability Gets More Serious

Grafana has moved two different interfaces for AI assisted observability into general availability: the Grafana MCP server and gcx, the Grafana Cloud CLI.

The interesting part is that the announcement does not treat them as competing products where one should eventually replace the other. They overlap heavily, but they represent different ways for agents and automation systems to interact with Grafana.

That distinction matters because AI infrastructure is moving past the phase where simply connecting a model to a tool is impressive.

The next question is operational: which interface is cheaper, easier to compose, easier to secure, and more predictable inside real workflows?

MCP gives agents structured, opinionated tools

The Grafana MCP server is aimed at environments where an AI agent already knows how to work with Model Context Protocol tools.

That makes it a natural fit for interactive systems such as coding assistants and desktop agents. The server can expose purpose built Grafana actions instead of forcing the model to understand command line syntax and parse arbitrary terminal output.

There is a real usability advantage in that structure.

A tool can define exactly what arguments it accepts. The agent can see a machine readable description. The response can come back in a predictable format. For common operations, that reduces ambiguity and makes the model less dependent on shell expertise.

Grafana described the MCP server as the more opinionated option.

That wording is important.

Opinionated tools reduce the number of choices the agent must make. If a common task has a dedicated action, the agent can call it directly instead of building the workflow from lower level commands.

The tradeoff is that structured tool definitions occupy context.

Some agent environments load large MCP schemas into the model context. When a server exposes many tools, a portion of the context window can be spent simply describing what those tools do.

Some modern agents support lazy tool loading, which reduces that problem, but the underlying design question remains.

gcx trades structure for shell composability

gcx comes from the opposite direction.

A command line interface fits naturally into CI systems, shell workflows, existing scripts, and environments where operators already compose tools through standard input, output, files, and pipes.

Grafana pointed out that agents using gcx can begin with lightweight skill metadata and then read command help only when they need it.

That changes when tokens are spent.

The agent does not necessarily carry a huge collection of tool definitions throughout the entire conversation. It can discover the relevant command later.

There is still a cost. Reading help output takes time and context too.

The bigger advantage is composability.

Shell commands are designed to be chained. An agent can call gcx, filter output, transform it, compare files, or pass data into another command without returning every intermediate result to the language model.

That can make repetitive automation more deterministic and potentially less token hungry.

For CI environments this matters even more. A pipeline already understands executable commands, exit codes, credentials, files, and environment variables. A CLI can fit into that model without adding a separate MCP server lifecycle.

General availability changes the trust conversation

Moving both projects to general availability means Grafana is signaling continued investment and feature stability.

That raises the stakes.

Experimental AI integrations can be treated like demos. Stable tools eventually receive service accounts, automation privileges, access to production dashboards, and permission to make changes at scale.

Once that happens, the important questions become familiar infrastructure questions.

What can the agent read?

What can it modify?

Which identity does it use?

How are credentials stored?

Can actions be audited?

Can a bad prompt alter hundreds of resources?

Can permissions be scoped differently between exploratory use and production automation?

The discussion also included questions about self hosted environments. Grafana engineers said gcx can work with on premises Grafana OSS and Enterprise instances for supported functionality, using service account tokens or user credentials. The MCP server can also be self hosted.

That makes the tooling more relevant to organizations that do not want their observability control path restricted to one hosted environment.

It also means teams cannot outsource the security model to the vendor. They need to decide what an agent should actually be allowed to do.

MCP and CLI may become two stages of the same workflow

The most useful outcome may be that teams do not choose one interface permanently.

An interactive agent can use MCP to explore a problem because the tools are explicit and easy to reason about.

Once the team understands the task, the stable workflow can become a gcx command sequence that runs in CI or a scheduled job.

That creates a natural progression from reasoning to automation.

Use the agent where ambiguity exists.

Use the script where repetition begins.

The same pattern appears across infrastructure tooling. Humans often start with an interactive interface, discover the correct operational sequence, and later turn that sequence into something deterministic.

AI agents do not remove that progression. They may accelerate it.

AI observability is becoming an interface design problem

The general availability announcement is important because it makes the conversation more mature.

A year ago, the headline might have been that an AI agent could query Grafana at all.

Now the interesting argument is whether the agent should receive a structured MCP tool, invoke a CLI command, compose shell operations, lazily load documentation, or carry tool schemas in context.

Those are engineering tradeoffs.

They are also signs that AI assisted operations is starting to look like normal infrastructure instead of a novelty.

MCP is compelling when the agent platform already speaks MCP well and the workflow benefits from structured, opinionated actions.

gcx is compelling when the environment is CI heavy, scriptable, and sensitive to composability or token overhead.

Many teams will probably use both.

The real milestone is that the choice is no longer about whether AI can access the observability system.

It is about how much structure, context, permission, and determinism should sit between the model and the production system it is being trusted to inspect.

Kubernetes 1.37 Is Coming: The New Alpha Features Infrastructure Teams Should Watch

lida0407 — Sun, 09 Aug 2026 11:43:32 +0000

Kubernetes 1.37 Is Coming: The New Alpha Features Infrastructure Teams Should Watch

Kubernetes 1.37 is scheduled for August 26, and the early feature discussion already shows where the project is pushing next. A detailed preview highlighted 22 features expected to arrive as net new alpha capabilities, with a noticeable concentration around Dynamic Resource Allocation, plus changes touching scheduling, pod resize, kubelet defaults, storage health, and kube proxy networking.

Alpha does not mean production ready. It means the ideas are entering the stage where operators, vendors, and contributors can begin testing them in real environments and discovering where the designs still hurt.

That makes the release interesting for infrastructure teams even if most of these features will remain disabled in production for some time.

Dynamic Resource Allocation keeps becoming more important

The strongest theme in the preview is Dynamic Resource Allocation, or DRA.

That matters because Kubernetes was originally built around a relatively simple resource model. CPU and memory fit neatly into scheduler calculations. Devices are harder. GPUs, accelerators, specialized network hardware, and other devices carry properties, topology constraints, sharing rules, and allocation behavior that do not fit cleanly into the old model.

The fact that many of the new alpha items are related to DRA is a signal about the workloads Kubernetes is increasingly expected to run.

AI infrastructure is an obvious driver. GPU scheduling has moved from a specialized edge case into a mainstream platform concern. Teams want better control over which devices workloads receive, how those devices are described, how claims are expressed, and how the scheduler reasons about them.

The important point for operators is not to rush into every alpha gate. It is to watch the resource model evolve.

A platform built today around fixed assumptions about accelerators may feel awkward later if DRA becomes the standard way Kubernetes represents complex hardware. Teams running GPU clusters should therefore treat 1.37 as a useful preview of where future APIs may settle.

Hierarchical scheduling is getting a new building block

Another feature called out in the preview is the CompositePodGroup API for hierarchical scheduling needs.

That phrase sounds niche until you think about modern distributed workloads.

Many jobs are not a collection of independent pods. A training job, batch pipeline, tightly coupled compute workload, or distributed service may need several pods to be considered together. Scheduling one piece without the others can waste capacity or leave the workload stuck in a half useful state.

Hierarchical scheduling adds another dimension because groups may themselves have relationships or priority structures.

This is exactly the kind of problem that appears as Kubernetes expands beyond stateless web services.

The default scheduler has spent years becoming more capable, but increasingly complex workloads keep asking it to understand more than individual pods. The presence of a CompositePodGroup API in the alpha discussion suggests the project is continuing to build primitives for coordinated scheduling rather than forcing every higher level system to invent the whole model itself.

For platform teams, the practical question is whether existing batch, AI, or workflow systems are already solving these problems with custom controllers. If they are, a future standard API could reduce integration complexity.

That future is not here yet. Alpha is the beginning of that conversation.

In place resize is forcing the scheduler to think differently

The preview also mentions scheduler preemption for in place pod resize.

In place resize changes a long standing operational assumption. Traditionally, changing important pod resource settings often meant replacing the pod. If Kubernetes can adjust CPU or memory allocations while a pod keeps running, capacity management becomes more dynamic.

But flexibility creates harder scheduling questions.

What happens when a running pod asks for more resources and the node cannot satisfy the request? Which workloads should move or be preempted? How should the scheduler balance the desire to keep a pod alive with the need to honor priority and capacity constraints?

Preemption support for resize is one piece of that puzzle.

This matters because resource rightsizing is one of the most persistent Kubernetes operational problems. Teams often over request capacity because they fear disruption. If resource adjustment becomes safer and more flexible, platform teams may eventually gain better ways to react to real demand without recreating workloads unnecessarily.

Again, this is alpha territory.

The feature is worth watching because it connects scheduling, availability, and cost. Those three concerns are usually treated separately in platform tooling, but in place resize forces Kubernetes to reason about them together.

Kube proxy, sysctls, and storage health may affect ordinary clusters sooner

Not every notable 1.37 alpha is aimed at exotic workloads.

The preview includes nftables as the default kube proxy backend, default pod sysctls in kubelet, and a volume health monitor.

These areas touch the daily concerns of ordinary infrastructure teams.

Networking backends matter because service routing sits in the path of almost every workload. Moving toward nftables as the default indicates continued evolution away from older packet filtering assumptions. Operators should pay attention to compatibility, observability, troubleshooting tools, and how network behavior differs across distributions and managed services.

Default pod sysctls in kubelet could affect how platform teams standardize low level kernel behavior for workloads. Anything that makes node level defaults easier to express can reduce repetitive configuration, but it also raises obvious security and consistency questions.

Volume health monitoring is another feature with practical appeal. Storage failures are painful precisely because Kubernetes can make infrastructure look healthy at one layer while the underlying device or volume is degrading somewhere else.

Better health signals could give controllers and operators more useful evidence before storage trouble becomes an application outage.

The right way to treat 1.37 is as a map of future problems

Infrastructure teams do not need to enable every Kubernetes 1.37 alpha feature.

They should read the list as a map.

DRA says Kubernetes expects more specialized hardware. Composite pod groups say workloads are becoming more coordinated. Resize preemption says resource management is becoming more dynamic. nftables changes show the networking foundation is still moving. Volume health work shows storage visibility is still an active problem.

That is the useful part of a release preview.

Stable features tell you what Kubernetes can safely do now.

Alpha features tell you what maintainers believe Kubernetes will need to do next.

For teams designing GPU platforms, large scheduling systems, storage intensive clusters, or long lived Kubernetes architectures, that direction is worth understanding before the APIs become boring and everybody starts treating them as inevitable.