An escort who cannot read the command is not a security control

The week

On July 15, 2025, ProPublica reported that Microsoft had used China-based engineers to help maintain Defense Department cloud systems. Cloud systems, in this sense, are computing services that Microsoft runs in its own data centers and rents to customers, so the customer does not have to own and operate the machines itself. Keeping such services running takes constant care: updates, fixes and troubleshooting by engineers.

Under the arrangement, U.S. personnel with security clearances, called digital escorts, typed in commands on the engineers’ behalf. A security clearance is the government’s formal approval, after a background investigation, for a person to handle sensitive information. The idea was that the foreign engineer would not touch the government system directly; a cleared American would do the typing.

The problem was in the detail. The report said many escorts lacked the technical expertise to judge whether those commands were safe. They could carry out instructions, but could not reliably tell a routine fix from a harmful one. It was rather like hiring a security guard to watch a locksmith work on your front door, when the guard has never seen the inside of a lock: present, badged and well-meaning, and with no way to know what is really being done. The systems involved handled sensitive but unclassified government data: information that is not secret in the formal sense but is still protected because its exposure could cause harm.

The reaction was swift. Members of Congress demanded answers. Within days, Defense Secretary Pete Hegseth said foreign engineers should never be allowed to maintain or access Defense Department systems, and the department opened an investigation. Microsoft said it had stopped using China-based engineering teams to support Defense Department cloud services.

Anyone who buys technology services was left with an uncomfortable question: what a provider’s claim that its systems are approved and compliant actually says about the people working on them.

When a government agency buys a cloud service, it does not take the vendor’s word that the service is secure. It relies on a formal approval process. For federal civilian agencies, that process is FedRAMP, the Federal Risk and Authorization Management Program. The Defense Department adds its own cloud security requirements on top. Together they set out, in great detail, the security controls a cloud service must have before an agency may put its data there. An approved service receives an authorization: a formal finding that it meets those requirements.

FedRAMP and the Defense Department’s cloud security requirements describe in detail how a service must be built, configured and monitored. They say much less, at least in terms an agency program office reads, about which individuals can change a running service, from where, and under whose eye. The escort arrangement sat in that gap. It met the requirement that a cleared U.S. person performed the action. The knowledge behind the action sat with someone the agency had never screened.

Closing the gap means answering three questions in order: who can touch the system, how their work is checked, and what the agency can prove. Each has a different owner. The first belongs to the contracting officer, the second to the provider’s operations leadership, and the third to the agency’s own security team. The contracting officer is the official with legal authority to sign and change a government contract, which makes them the person best placed to write requirements the provider must meet.

How a cloud service is actually run

Most executives never see what “maintaining” a cloud service involves. A large cloud service is a vast set of interlocking software components running on thousands of machines. Much of the day-to-day work is automated: software watches for problems, restarts failed pieces and rolls out updates. When something goes wrong that automation cannot fix, a support engineer steps in. If that engineer cannot solve it, the problem escalates to someone more specialized, and sometimes to the small group of people who built that particular component and understand it best.

Engineers do their work by issuing commands: precise written instructions to the system, such as “restart this service” or “change this setting.” Many commands are harmless. Some are powerful enough to change security settings, expose data or open a path for later access. To a non-expert, the harmless and the harmful can look almost identical on screen.

Two other terms matter. Privileged access is the elevated level of permission that lets someone change how a system works, rather than just use it. Runbooks are pre-written, step-by-step procedures for common operational tasks, often packaged as scripts: small programs that carry out a sequence of commands automatically. Runbooks are valuable because they turn expert knowledge into a tested routine. They are also a channel of influence, because whoever writes them shapes what happens every time they run.

Who can touch the system

Large cloud providers run on global engineering teams. Routine operations are often automated. Hard problems escalate to specialists who know a particular component deeply, and those specialists sit wherever the provider built that expertise. A customer that assumes its support comes only from cleared U.S. staff is usually describing the first tier, not the last.

Three kinds of access, not two

Personnel rules tend to count people who hold credentials. The escort model shows a third category that matters as much. There are people with standing access, people granted temporary access for a task, and people with influence but no access: the engineer who dictates the command that someone else types. A screening requirement that covers only the first two categories leaves the third untouched.

Ask for a personnel access matrix

Agencies can ask for this in a form they can use. A personnel access matrix lists each support role, its location, the screening it requires, and whether it acts directly, through temporary elevation, or through another person. It is, in effect, a table showing who can affect the system, and by what route.

The matrix should cover escalated support and incident response as well as steady-state operations. Incident response is what happens during an outage or a security event, when the most expert people are pulled in and normal procedures are under the most pressure. It should also say who writes the operational scripts and runbooks used in the government environment, since those are another path for influence.

Suppose a state revenue department is moving its tax processing system to a cloud provider, and its contracting officer asks for a personnel access matrix as a condition of award. The first draft lists only the provider’s U.S.-based first-tier support team. The agency asks the obvious follow-up: who those people call at 2 a.m. when they are stuck. The second draft adds two escalation tiers and a component team in another country that writes the runbooks used to patch the database. Now the agency knows what it is actually buying, and can decide what to restrict.

Code is a separate question

Code is a related but separate question. Engineers around the world write software that later deploys into government regions, and that path is governed by secure development and code review practices rather than personnel access rules. A government region is a separate, isolated copy of a cloud service built to serve government customers under stricter rules. Agencies should keep the two apart, so that a promise about support locations is not mistaken for a promise about who wrote the code.

How their work is checked

Supervision works only if the supervisor can evaluate the work. ProPublica described escorts with limited engineering experience reviewing commands written by more experienced engineers. That arrangement satisfies the letter of a rule while placing the substance of every decision with the person the rule was meant to restrict.

This principle applies far beyond cloud computing. Any control that depends on a human checker is only as strong as that checker’s ability to understand what they are checking. A bank teller cannot verify a signature they have never seen; a junior auditor cannot challenge a valuation model they do not understand.

What stronger designs look like

Stronger designs rely less on any one person’s judgment. They include:

• Ticket-bound, expiring access. Temporary access is approved against a specific ticket and expires. A ticket is the formal record of a support request; tying access to it means every elevated session has a documented reason and an end time.
• Runbooks, not free text. High-risk commands run only from pre-approved runbooks, never as free text. That removes the chance to slip an unusual instruction into an urgent fix.
• Recorded sessions. Sessions are recorded, so there is a replayable record of what was done.
• Peer approval. Changes that touch security settings, keys or data stores require a second engineer of comparable skill to approve them. Keys here are the digital secrets used to lock and unlock data; data stores are where the data itself lives.
• Automated guardrails. Automated policy checks block known dangerous operations regardless of who requests them.

The trade-off is speed

These controls have costs. Each one adds minutes to an outage, and during a serious incident minutes matter. An agency that demands two-person review for every privileged action on a high-impact system is accepting slower recovery in exchange for assurance. Often the trade is right, but it should be made knowingly and written into service levels. Service levels are the contractual targets for availability and response time; if the agency asks for stricter checks, it should not then penalize the provider for the slower recovery those checks produce.

The people behind the control

The workforce side deserves equal attention. Escort-style roles are often staffed for clearance first and engineering depth second, which places the least experienced person at the most sensitive point. Agencies can ask how supervisory roles are trained and paid, how many sessions each supervisor oversees, and whether supervisors have clear authority to stop a command they do not understand. Those answers predict how the control behaves at three in the morning.

Pay and workload matter. A supervisor stretched across many sessions, paid less than the engineers they oversee and without clear authority to say no will, under pressure, approve what they are shown. A supervisor with real expertise, a manageable load and explicit permission to halt work is a genuine control.

What the agency can prove

Agencies see a provider through its authorization package, its continuous monitoring reports and its incident notices. The authorization package is the large body of documentation reviewed for approval; continuous monitoring reports are the regular updates a provider sends afterward. Those documents describe controls at a level where escalation staffing rarely appears. Monthly monitoring focuses on vulnerabilities and remediation plans, not on who held a privileged session last Tuesday.

Contracts are the main tool

Contracts are the main tool for changing that. Useful clauses require disclosure of the personnel access matrix, advance notice of material changes to support locations or supervision models, and periodic independent assessment of the specific privileged access controls the agency relies on.

Some providers offer workflows that require customer approval before engineers can view customer content. Agencies should confirm which support paths those workflows cover, because content access and changes to the underlying service are often governed differently. An approval gate on reading your files does not necessarily cover changes to the machinery that stores them.

State and local obligations

State and local agencies carry their own obligations. The FBI’s CJIS Security Policy sets screening requirements for personnel with access to criminal justice information, such as arrest records and fingerprints. IRS Publication 1075 sets conditions on contractor access to federal tax information, including restrictions on offshore access. Agencies subject to those rules should confirm, with counsel and their oversight bodies, that a provider’s escalation model complies, and its steady-state operations too.

A gap that reaches every outsourced service

This is a story about more than one company, one department and one country. The gap the escort arrangement exposed exists wherever an organization relies on a provider’s people to run something important on its behalf, which today means almost every agency, hospital and bank.

Risk. The most serious risks in outsourced technology rarely sit in the controls that get audited every month. They sit in the moments of exception: the outage at 3 a.m., the specialist pulled in from another team, the urgent fix that skips the normal route. A control that works on an ordinary Tuesday and collapses during an incident offers little protection when it counts.

Accountability. When something goes wrong with a provider, the public, oversight bodies and legislators do not hold the provider alone responsible. They ask what the agency knew and what it asked for. “The service was authorized” is a weak answer if nobody asked who was operating it.

Cost. Restrictions on who can support a system are real costs, paid in price, in slower escalation and sometimes in reduced expertise. Spending that money everywhere is wasteful; spending it nowhere is reckless. The value lies in choosing deliberately.

Reputation and trust. Residents who hand over tax records, criminal history or benefits information assume that the government knows who can reach it. A report that the answer was “we are not sure” damages trust in a way that is slow and expensive to repair.

A sheriff’s office that got it right

Take a county sheriff’s office moving its records management system to a cloud provider. Because the system holds criminal justice information, the CJIS Security Policy applies. Before signing, the county’s contracting officer requests the personnel access matrix and finds that escalated database support is handled by a team whose screening status is unclear. The county asks the provider to route escalations for its environment to screened personnel, to require peer approval for changes to security settings and to record privileged sessions. The provider agrees, at a higher price and with a longer target time for escalated fixes. The county records why it accepted those terms, writes them into the contract and asks for an annual independent assessment of those specific controls. A year later, when the provider reorganizes its support teams, the advance notice clause means the county hears about it before the change, not after.

Deciding where restrictions are worth paying for

Not every workload needs restricted support. A public website does not justify the cost of a narrower support pool. Restrictions mean fewer eligible specialists, slower escalation and often a higher price.

The agency, not the provider, should decide which workloads carry those costs, record the decision, and make it enforceable through the contract and verifiable through evidence it actually receives. A sensible approach sorts systems into tiers. A public information site might accept the provider’s standard global support. A benefits system holding residents’ personal data might require screened personnel for privileged access and recorded sessions. A law enforcement or tax system subject to CJIS or Publication 1075 would carry the strictest terms, including restrictions on offshore access and peer approval for sensitive changes.

The failures in this area follow a familiar pattern. Agencies treat an authorization as proof of who operates the system. They ask about first-tier support and stop there. They accept a supervision model without asking whether the supervisor can understand the work, or demand strict controls and then complain about slower recovery. And some apply the same expensive restrictions to everything, which wastes money on low-risk systems and makes the restrictions harder to defend where they matter.

What the next cloud contract should pin down

1. For each critical cloud service, do we have a personnel access matrix that covers standing, temporary and indirect access, including escalated support and incident response?
2. When someone supervises a privileged session, can they actually understand the commands, and do they have authority to stop them?
3. Which changes require a second engineer of comparable skill to approve them, and are sessions recorded?
4. Does our contract require advance notice if support locations or supervision models change?
5. Have we decided, in writing, which workloads justify restricted support and which do not?

With hindsight

In late August 2025, Hegseth said the department had sent Microsoft a formal letter of concern and would require a new third-party audit of the escort program, alongside an investigation into whether China-based engineers had put anything into the code. He acknowledged that the program had been designed to comply with contracting rules, and said it nonetheless exposed the department to unacceptable risk.

Policy then hardened into rules. In September 2025 the Pentagon barred IT vendors from using China-based personnel on its systems, and the defense authorization act signed that December wrote a similar prohibition into law. What began as a newsroom investigation ended as a statutory requirement.

That admission — that a program designed to comply could still expose the department to unacceptable risk — is the durable part of the episode. The arrangement passed the paperwork and failed the substance. We have not found a public account of the audit’s findings, and we would not claim one.

What holds up in 2026 is the distinction the story forced into view: a system can be properly authorized while the people who operate it are supervised in ways that provide little real assurance. That distinction matters to any organization that buys managed technology services. A state agency, a hospital or a bank relies on someone else’s people, and on someone else’s idea of what supervision means.

Agencies that now ask for a personnel access matrix, and for evidence that supervisors can understand what they approve, are testing the control rather than the paperwork. When a provider says a control is in place, the test is whether the customer can see it working, and whether the person operating it would know if something went wrong. A certificate on file does not, on its own, answer either question.