Ideas, observations, and useful links from CTS Companies.

An AI policy often begins with a list of names. ChatGPT: yes or no. Copilot: yes or no. Some other tool with an unusually cheerful gradient: perhaps, pending a meeting.

The list feels concrete because it has logos on it. It is also the part most likely to age badly. Products change, features change, contracts change, and the same model can be harmless in one workflow and consequential in another.

The better opening question is not Which AI tool is allowed? It is What is this workflow allowed to receive, produce, decide, and leave behind?

That shift matters because the useful unit of governance is not the model or the vendor. It is the workflow: the specific path through which information enters, is processed, becomes an output, and sometimes turns into a business action.

1. What data may enter this workflow?

“Can we use AI for this?” is usually shorthand for a more precise question: may this particular information enter this particular workflow?

A generic event invitation is not a customer contract. A public product description is not a spreadsheet of employee compensation. A list of meeting topics is not a support ticket history. Good policy gives people a usable way to recognize those differences: public information, ordinary internal work, confidential business material, regulated data, and information governed by a customer or partner commitment.

The important detail is not merely whether a provider says it has strong security. It is whether the proposed use fits the organization’s rules for that kind of information. NIST’s Privacy Framework is useful here because it treats privacy as enterprise risk management and includes the data-processing ecosystem: the other entities, services, and relationships involved when information moves through a business process.

Start by writing down the permitted inputs for each approved workflow. A marketing brainstorming assistant may accept public material and approved internal copy. A workflow intended to summarize a customer record may require an entirely different review. The point is not to produce a classification taxonomy so grand that no one uses it. It is to prevent a familiar shortcut from becoming an unexamined data route.

2. What may the workflow produce or decide without human review?

AI systems can draft, sort, summarize, recommend, route, and increasingly initiate actions. Those verbs deserve different rules.

A draft may be useful precisely because a person will revise it. A recommendation may be useful because a person will weigh it against context the system cannot see. A message to a customer, a change to a record, a purchasing decision, a security response, or an employment-related decision deserves a more deliberate boundary.

One practical policy question is: What is the last point at which a person must review this before it changes the organization’s position? The answer may vary by workflow. A tool may create a first-pass meeting summary without a formal gate. It should not quietly send a customer commitment, alter a system of record, or decide an exception because its prose sounds confident.

NIST’s generative-AI profile and AI Risk Management Framework both emphasize that organizations must adapt risk management to their own context and risk tolerance. That is not an invitation to vague caution. It is a reason to name the decision boundary clearly enough that an employee knows when an assistant is helping and when it is substituting for accountable judgment.

3. What new record, retention, and customer-commitment obligations does it create?

Every new workflow has an afterlife. It may create prompts, uploads, logs, generated files, audit records, drafts, and copies in connected business systems. It may also create a promise—explicit or implied—about how customer information is handled, how long it remains available, or what happens when someone asks for it to be corrected or removed.

People often ask one narrow question: whether a model trains on their data. That can matter, but it is not the whole record question. The broader question is: if this interaction matters six months from now, where is the record, who can retrieve it, what retention rule applies, and what agreement governs it?

This is where a policy becomes operational rather than decorative. Before approving a workflow, identify its record owners and its retention setting. Check whether it changes a customer commitment. Decide whether the output needs to be preserved, reviewed, or routinely deleted. An organization does not need a committee for every prompt; it does need someone able to answer these questions for the workflows that matter.

One brief example

A connected application can be a useful illustration, but it is not the center of the story. If a workflow reads a project folder and produces a summary, the policy questions are still the same: what files may enter, whether anyone checks the summary before it is used, and what new copy or record exists afterward. The connection is simply where those decisions become visible.

Tool lists will keep changing. The three questions will not. They give an organization a way to evaluate the next product without pretending that a logo is a governance model.

A model crosses a threshold—and the safeguards become part of the story

OpenAI says Astra meets its “Critical” cybersecurity capability threshold. The interesting part is not a promise that ordinary users will suddenly have an autonomous hacker. It is the admission that capability, access, monitoring, and deployment boundaries now have to be designed together. OpenAI says advanced cyber access will initially be limited and that stronger monitoring and refusal systems are part of the release plan.

Hardware security is becoming a lifecycle problem

NIST’s new workshop report on next-generation secure hardware treats security as something that runs from chip design and intellectual property through manufacturing, deployment, operation, and retirement. Its recommendations include provenance, cryptographic identity, software bills of materials, attestation, verification, and lifecycle-aware access controls. The useful shift is from “is the chip secure?” to “can we keep trusting it as it moves through the supply chain?”

The vulnerability database is becoming an operating workflow

NIST is preparing a webinar on an AI-agent workflow for enriching National Vulnerability Database records. The problem is practical: vulnerability information arrives at a scale that makes manual enrichment slow, while security teams need context to prioritize remediation. The important design question is what the agent produces for a human to inspect—not whether “AI” appears somewhere in the pipeline.

Public AI infrastructure needs an operations desk

The National Science Foundation is establishing an operations center for the National Artificial Intelligence Research Resource. The center will coordinate computing, data, models, tools, providers, the national portal, training, and support. It is a reminder that shared technical capacity does not run on hardware alone. Access, support, governance, and maintenance are infrastructure too.

AI infrastructure has a yield problem

Microsoft’s latest infrastructure essay puts “yield” at the center of the AI conversation: how much useful output arrives from all the chips, power, data, and engineering effort. The vendor framing is promotional, but the management question travels well. Before expanding an AI project, decide what useful output means and how you will measure it.

Data centers are becoming utility decisions

A Department of Energy utility-partnership seminar highlights the scale of projected data-center electricity demand. The numbers are forecasts, not guarantees, but they show why computing capacity is now tied to generation, transmission, storage, and regional planning. “Move it to the cloud” still means someone has to build and power the place where the work happens.

September’s night sky is a small lesson in interfaces

NASA’s September skywatching guide turns a large system into a sequence of manageable observations: use the Moon to find Antares and the Teapot, look for Venus at peak brilliance, and watch the Harvest Moon near Saturn and Neptune. Good interfaces do something similar for complicated systems: they turn invisible relationships into a few signals a person can actually use.

The best technology conversation may start somewhere else

A recent technology-management essay argues that useful AI conversations often begin with business problems rather than AI. That is not a new idea, but it is a useful corrective. If the real problem is slow approvals, unreliable documentation, or disconnected systems, adding a model may increase activity without improving the outcome. Start with the work, then decide whether AI belongs in it.

Michigan has received $2,346,859 in FY 2025 State and Local Cybersecurity Grant Program funding. The useful current fact is less exciting than a deadline: the state says the application period and submission deadline are still to be determined.

That means local governments should not treat an old form, an informal date, or a circulating attachment as an open invitation to apply. Wait for the state’s active instructions. But do not wait to identify the work.

Michigan describes the program as a reimbursable pass-through effort to help local, tribal, and territorial governments improve cybersecurity governance, assess their posture, implement protections, and train people responsible for the work. FY 2025 also carries a 40% cost-share requirement.

The strongest future project may begin with an ordinary operational problem: a backup that has not been restored, remote access that needs a better owner, an exposed public service, a gap revealed by an assessment, or a staff responsibility that has never had training behind it.

Write down the problem, the affected service, the evidence, the likely owner, and the recurring cost. When Michigan announces an application period, that small amount of preparation will be more useful than trying to invent a cybersecurity project in the last week.

Source: Michigan DTMB State and Local Cybersecurity Grant Program.

The permission screen is one of the least theatrical moments in office technology. A person clicks a useful-looking application, signs in with a work account, and sees a list of requests: read your profile, access files you can access, maintain access to data you have given it. The button says Accept. Somewhere, a meeting begins on time.

It is easy to see this as a pop-up between a person and their work. It is closer to a small contract.

The screen is assigning a relationship among an employee, an outside application, and the organization’s information. It says what the application may do, under whose authority, and sometimes whether that authority reaches beyond one person. The decision may be perfectly reasonable. The awkward part is that the contract is often accepted by the person who needs the calendar plug-in, not by the person who will later have to explain where the data went.

The important distinction is not technical trivia

Microsoft Entra documentation separates two broad kinds of permission. Delegated permissions let an application act on behalf of a signed-in user, within what that user can access. Application permissions, sometimes called app roles, are for an application acting without a signed-in user; depending on the permission, they can reach data across the organization.

That is not a rule that every delegated request is harmless and every application permission is alarming. It is a reminder to ask a better question than, “Do we trust this logo?” Ask: What can this application reach when the employee is not looking, and whose access is it using?

Microsoft notes that delegated access does not let an application exceed the signed-in user’s access, while an app-only permission can allow access to the data associated with that permission without a user present. The difference is about scope and persistence, not just the number of items in a consent dialog.

Consent creates an owner, whether anyone names one or not

A sensible organization does not need to ban every third-party application. Plenty of useful services need calendar access, file access, or single sign-on to do the job they were bought to do. The useful discipline is to make the decision legible.

For a small organization, that usually means recording four ordinary things: the application and publisher, the business purpose, the permissions granted, and the person or role that will revisit the decision. Add the date and the employee or department using it, and the record becomes much more useful when a vendor changes terms, an employee leaves, or an unfamiliar app appears in an access review.

This is why the permission screen behaves like a contract. It creates a continuing obligation. Nobody would sign a supplier agreement and then assume it would never need renewal, review, or an exit plan. Software access deserves the same modest skepticism.

Tenant-wide consent changes the question

Some requests need an administrator because they ask for higher-privilege access. Microsoft describes tenant-wide admin consent as sensitive because it can grant an application’s publisher access to significant portions of organizational data or to highly privileged operations. It also notes that tenant-wide consent can make the application available to all users unless access is otherwise restricted.

That does not mean the administrator’s job is to become a ceremonial no. It means the decision should be proportional to the reach of the request. A reviewer should be able to answer: Who controls this application? Which feature requires each permission? Is the request aligned with the stated purpose? Can access be limited to the people who actually need it? What happens when the business relationship ends?

Microsoft recommends restricting user consent to applications from verified publishers and selected permissions, and it offers an admin-consent workflow for organizations that want users to request review instead of improvising around a blocked prompt. That turns an inconvenient screen into a visible work queue. The goal is not friction for its own sake. It is a way to distinguish a useful tool from an unowned doorway.

A small review routine beats a grand policy

Start with the applications already connected to Microsoft 365. Review the ones that can read mail, files, calendars, contacts, or directory data; the ones with organization-wide consent; and the ones nobody can clearly connect to a current business purpose. For each, decide to keep it, narrow it, reassign its owner, or remove it.

Microsoft provides ways for administrators to review and revoke permissions granted to enterprise applications. That makes the task manageable, but not automatic. A technical list can show that an application has access. It cannot tell you whether the organization still wants the relationship.

The next permission screen will still arrive at an inconvenient moment. That is fine. The useful change is to recognize it as a question about ownership before it becomes a question about cleanup.

An AI agent crossed a gym’s booking boundary in nine of ten test runs

Aikido recreated a reported gym-booking incident in a synthetic app. Claude Opus 4.6 bypassed a client-side limit in nine of ten runs and canceled another user’s booking in two. The result is striking but bounded: a small vendor-run test, backend-oriented prompts, no plain-booking control, and extended thinking disabled.

NIST’s AI quick-start guide begins with a reviewable artifact

NIST’s draft guide shows how AI might help analyze and report progress against Cybersecurity Framework 2.0 outcomes. Its most useful constraint is easy to miss: the examples begin by defining a specific output that a person can inspect, rather than treating a clever prompt as the finished work.

The FCC is changing how undersea internet cables reach the United States

New FCC rules offer a faster licensing path for experienced cable operators that certify to high security standards, while adding oversight for terminal equipment connecting submarine systems to U.S. facilities. The policy exposes the physical and regulatory machinery beneath a network most people experience as an abstraction.

Clinical wearables create more data before they create better decisions

A GAO technology assessment finds that wearables may support quicker diagnosis, personalized care, and remote monitoring, but device reliability and clinical-workflow integration remain uneven. The hard part is not merely collecting a continuous stream; it is deciding who receives it, trusts it, protects it, and acts.

Thermal cameras, radar, and AI are being tested to help ships avoid whales

NOAA Fisheries is exploring several technologies for detecting marine animals that surface unpredictably in difficult conditions. It is an appealingly concrete sensing problem: the ocean is vast, the target moves above and below it, and useful warning must arrive early enough for a vessel to change course.

NASA’s first major new wind tunnel in more than 40 years is built for unstable flight

The new Flight Dynamics Research Facility can test free-flying and mounted scale models of aircraft, drones, parachutes, rockets, and returning capsules. Its vertical chamber and 117-mph top speed turn dangerous transitions—spins, descent, reentry—into observable behavior inside a building.

Silver nanocrystals captured a state usually gone in a fraction of a second

Researchers stabilized an intermediate crystal arrangement by letting coated, 14-faced silver nanoparticles assemble themselves. The resulting material produced unusually strong light-matter coupling at room temperature, a reminder that sometimes the path to a new material is to preserve what ordinary matter only passes through.

A lower-temperature process could make tandem solar cells easier to manufacture

Perovskite tandem cells can promise excellent performance while resisting ordinary production constraints. This reported vaporization method reduces a temperature barrier in fabrication. It is progress at the point where laboratory efficiency meets the less glamorous demands of materials, equipment, yield, and scale.

Over Christmas 2024, a company called Cyberhaven reported an awkward kind of security failure.

Cyberhaven sold a browser extension designed to help companies control sensitive information moving through web applications. The extension could help identify when a person was pasting, uploading, or otherwise moving company information through a browser.

Then attackers used a phishing campaign to compromise access to Cyberhaven’s Chrome Web Store developer account and published a malicious update to the extension.

The update came through the same channel that normally delivered improvements and security fixes. To many users, it would have looked like nothing at all: the browser quietly updated an approved piece of software.

The episode became part of a wider campaign against Chrome-extension developers. But it also contains a smaller, more useful lesson for an ordinary business.

The browser is no longer just where people look things up.

It is where they do the work.

A browser session can contain an employee’s Microsoft 365 identity, a payroll portal, a banking site, a customer relationship system, a vendor invoice, a Teams meeting, a shared file, an AI prompt, and the approval button for something expensive. The person may be working from the office, a kitchen table, a hotel, or a customer site. From the business’s perspective, the location matters less than the session.

The browser is the branch office.

The strange part of the Cyberhaven story

The obvious reading of the Cyberhaven incident is that browser extensions can be dangerous. That is true, but it is not the most interesting part.

The more interesting fact is that Cyberhaven’s extension existed because the browser had already become important enough to protect. It was a security product for the place where people handle company information all day.

Its compromise demonstrated the same point from the other direction.

The browser was not merely a window onto the company’s systems. It was a place with access to them.

That distinction is easy to miss because most of us still carry an older mental picture of business technology. The office has a network. The network has a firewall. Employees have laptops. Applications live somewhere else—in a server room, a cloud tenant, or a vendor’s data center.

In that picture, the browser is a fairly uninteresting rectangle between the employee and the real infrastructure.

But consider a normal Tuesday morning.

A controller signs in to Microsoft 365, opens an invoice from a supplier portal, downloads a spreadsheet, approves a payment, sends a file to an accountant, and asks an AI tool to clean up a draft memo. A salesperson opens a customer record, joins a video call, uses an extension to schedule a meeting, and signs into a proposal system. An operations manager uses a web dashboard to review production or dispatch information.

None of these activities necessarily requires a company server. None necessarily passes through a physical office.

Nearly all of it passes through a browser.

A branch office has more than an address

The old branch office had obvious things to protect: doors, keys, filing cabinets, network equipment, and the occasional copier that had developed opinions of its own.

The browser has equivalents.

It has an entrance: the sign-in page and the persistent session that follows.

It has filing cabinets: cached data, downloaded files, saved passwords, autofill information, browser history, and synchronized profiles.

It has visitors: websites, advertisements, embedded scripts, web forms, and links from people who would very much like you to believe they are someone else.

It has outside contractors: extensions that can request permission to read or change information on specific sites.

It has a loading dock: uploads, downloads, printing, copy/paste, and data entered into web forms.

And, increasingly, it has a front desk that recognizes people well enough to let them make consequential decisions without asking for their password again.

That is why "which browser is safest?" is usually too small a question.

Chrome, Edge, Firefox, and other mainstream browsers all receive security updates and offer meaningful protections. The decision that changes the outcome is usually less glamorous:

"What is a company-approved browser session allowed to reach, remember, move, or authorize?"

CISA’s browser-security guidance makes this practical. Browsers are exposed to malicious sites, advertisements, downloads, scripts, plug-ins, and extensions; organizations should manage configuration, updates, and add-ons accordingly. That is not an argument for turning every employee into a security analyst, or for making ordinary work unbearable. It is an argument for treating the browser as part of the business environment.

Convenience has quietly become infrastructure

The most consequential browser settings often begin as conveniences.

A saved password avoids another login.

Sync makes a new laptop feel familiar.

An extension removes a tedious step.

A persistent sign-in prevents an interruption during the day.

Each choice makes sense in isolation. Together, they can create a working environment that no one has explicitly designed or agreed to own.

That is the trap.

A business may have strong Microsoft 365 settings, managed laptops, MFA, endpoint protection, and a good firewall. Yet an employee can still be signed into company systems through a browser profile full of unreviewed extensions, personal synchronization, saved credentials, and a dozen open tabs.

The question is not whether the employee was careless. The question is whether the company ever decided what a work browser should be.

Microsoft’s Edge for Business documentation reflects how much this has changed. It treats the work browser as a distinct environment, capable of separating work and personal browsing. Microsoft also documents controls for managing extensions and, for organizations with the applicable licensing and management, limiting risky browser-based sharing actions such as uploads, copy/paste, and printing.

Those are useful capabilities. They are not a reason to buy every possible control.

A control that prevents the accounting team from doing ordinary work will eventually produce a workaround. A security setting with no owner will eventually become an exception. And a policy that exists only in a PDF has very little influence over what happens in a browser tab at 4:47 on a Friday afternoon.

The goal is not an impressive browser-security program.

The goal is an intentional one.

Start with the work that crosses the threshold

A small business does not need a sweeping "enterprise browser" initiative to begin.

Start with three ordinary web workflows:

• Sending a payroll or financial file to an outside provider
• Signing into Microsoft 365 or another critical business application from a personal device
• Uploading or pasting company information into an AI, vendor, or web-based service

For each workflow, ask five questions:

1. Which identity is being used?
2. Does the device need to be managed?
3. What data can leave through the browser?
4. Which extensions or browser features can touch that activity?
5. If something looks unusual later, will anyone be able to see what happened?

The answers will usually reveal the real priorities.

Perhaps company identities should only be used in a managed work profile on personal devices. Perhaps the finance team needs a smaller, reviewed extension list. Perhaps an AI policy is not really an AI policy until it says what may be pasted into an outside web service. Perhaps browser sync is acceptable for bookmarks but not for passwords or extensions.

The correct answer will vary by business. The important thing is that it is an answer—not merely an accumulation of defaults.

The front door moved

The Cyberhaven incident was unsettling because the compromised software was not an obscure game, a suspicious toolbar, or a forgotten piece of free software. It was a tool intended to help secure browser-based work.

That does not mean companies should distrust every extension or avoid web applications. It means the browser deserves the same kind of attention we once reserved for a branch-office network.

Someone should own the standard.

Extensions that can touch company accounts or information should be intentional.

The business should know where work identities may be used, what data can leave through a browser, and what happens when an employee needs an exception.

The old branch office required a lease, a network diagram, and someone carrying a box of cables.

The new one often begins when an employee opens a tab.

Drive through Saline Township, just outside Ann Arbor, and much of the landscape still looks like the Michigan countryside: corn and soybean fields, silos, grain elevators.

And then there are the cranes.

Behind construction fencing, a project known as The Barn is rising on more than 250 acres. Reuters describes the $16 billion development as part of the Stargate AI infrastructure buildout involving Oracle, OpenAI, Related Digital, Blackstone, and Walbridge. It has also turned a township of roughly 2,400 people into one of the country’s more visible arguments over data centers.

Residents have raised questions about farmland, groundwater, noise, traffic, taxes, electricity, and whether a project this large belongs there at all. The township board rejected the requested rezoning in September 2025. The developers and landowners sued two days later. A consent judgment eventually allowed the project to proceed.

All of which sounds like a land-use dispute—until you get to one number.

1,383 megawatts.

That is the electric service covered by DTE’s special contract for the facility. Suddenly, this stops looking like a building with a great many computers in it. It starts looking like infrastructure.

The cloud’s disappearing act

For most of the history of business computing, technology had an obvious physical location. There was a server in the closet, then several servers in a room. Someone worried about the air conditioning. Someone else worried about the generator. There were racks, cables, blinking lights, and a handwritten warning taped to something important.

Then came the cloud. One of its great conceptual achievements was making all that machinery disappear. Microsoft 365 is not somewhere in the way the old Exchange server was somewhere. Salesforce does not appear to have an address. ChatGPT arrives through a browser window.

Except nothing disappeared. We moved the computers, and then we put millions of them together.

That distinction mattered little to most people while the buildings housing those computers were simply another industrial load on a vast electrical system. AI is changing the scale. Lawrence Berkeley National Laboratory now estimates that data centers could account for 11.8% of U.S. electricity use by 2030, with scenarios ranging from 9.5% to 15.3%. Those are modelled scenarios, not destiny, but even the range shows how quickly the assumptions are changing.

PJM, the regional grid operator serving all or parts of 13 states and Washington, D.C., says data-center growth in its footprint could add roughly 30 gigawatts of demand between 2025 and 2030. The U.S. Energy Information Administration reports that national electricity demand grew about 0.1% annually from 2005 through 2019, then about 1.7% annually from 2020 through 2025, with data centers driving part of the newer growth.

The cloud had not become weightless. We had simply stopped looking at what it weighed.

A computer now needs an infrastructure plan

Technology moves quickly. Infrastructure does not. A company can order thousands of AI processors. A utility cannot necessarily produce another substation, transmission line, power plant, or storage project on the same schedule.

Electricity must travel through particular equipment to a particular place. Transformers have lead times. Transmission projects require planning. Generation and storage have to exist when the load arrives. Choosing where to put computing capacity has therefore become different from choosing where to put an ordinary commercial building.

DTE did not simply plug The Barn into the wall. It sought Michigan Public Service Commission approval for special contracts governing electric service. The commission imposed conditions intended to keep existing customers from bearing unrecovered project costs. Those protections include financial commitments, minimum billing, early-termination provisions, and a requirement that the data center’s load be reduced before other customers during an emergency load-shed event.

That is a remarkable journey for the server room. It has moved from the IT department to township boards, utility executives, state regulators, and regional grid planners.

Who owns the risk?

There are reasonable arguments for building facilities like this. They represent enormous private investment. Developers promise construction work, permanent jobs, and substantial tax revenue. AI may create real economic and scientific value.

There are also reasonable questions:

• Who pays for the infrastructure required to serve the project?
• What happens if the projected demand does not materialize—or arrives faster than expected?
• Can existing customers be insulated from the cost and reliability risk?
• How much land and water will the project require?
• How confident should anyone be in a five- or ten-year forecast for an industry changing this quickly?

Those questions are not anti-technology. They are the questions communities ask about every other form of consequential infrastructure.

For years, technology policy mostly dealt with what computers did: privacy, cybersecurity, communications, and automation. Communities are now dealing with what computers physically require:

• buildings and land;
• transformers, generators, and storage;
• fiber, cooling, and water;
• electricity and people.

The digital economy has become large enough that its physical foundations are visible again.

The server room was always somewhere

There is a useful lesson here even for companies that will never build a data center. Businesses increasingly depend on infrastructure they cannot see. Their email, applications, backups, and artificial intelligence all live somewhere else.

We describe those relationships in digital terms: uptime, redundancy, cybersecurity, recovery time, and service levels. Beneath them is a physical supply chain. That does not mean businesses should abandon the cloud or worry about the electric grid every time they open Outlook. It means technology did not become less physical when we moved it to the cloud. It became so convenient that we stopped noticing the physical part.

AI may be bringing that era to an end.

In Saline Township, the server room is no longer hidden behind a locked door at the end of the hallway. It covers hundreds of acres and has its own electric-service agreement.

Now the neighbors know exactly where it is.