Clearance, access and need-to-know: three controls the Discord leak pulled apart

The week

In early April 2023, photographs of what looked like classified US military and intelligence documents, including assessments of the fighting in Ukraine, began circulating on social media, where people who follow the war picked them up. The trail led back to a small Discord chat group, where the images had first appeared. Discord is a popular chat app, built originally for video gamers, where people gather in invitation-only groups called servers to talk, swap jokes and share pictures.

The question everyone asked was simple: who had access to these papers, and how did they end up in a chat room?

The answer arrived quickly. On April 13 the FBI arrested a 21-year-old member of the Massachusetts Air National Guard. He was charged by criminal complaint with unauthorized retention and transmission of national defense information. Those are offenses under the Espionage Act, the century-old federal law that covers the mishandling and disclosure of national defense secrets. A criminal complaint is the quick first step prosecutors use to make an arrest; a fuller indictment usually follows.

What surprised many people was who he was. He was neither a spy nor a senior intelligence officer. He worked in an information technology role, supporting his unit’s computer networks, the kind of job that keeps machines patched, accounts working and printers running. He also held a top secret clearance, the government’s formal judgment, after a background investigation, that a person can be trusted with highly sensitive information.

Prosecutors alleged that he had transcribed documents he accessed at work, and later photographed them, and shared them with the group. The material had not left through a sophisticated hack but through a person who was allowed into the building, allowed onto the network, and, it turned out, able to read far more than his job required.

The Defense Department said it was reviewing how intelligence was distributed and how access was controlled. That response pointed at the real issue. A clearance says a person can be trusted with secrets in general. It does not say which secrets that person needs. For any organization that holds sensitive information, from a defense agency to a bank or a hospital, that distinction turned out to matter enormously.

The leak was quickly framed as a clearance failure, and inquiries focused on missed warning signs. That framing was important but incomplete. The airman held a valid clearance appropriate to his job. The problem lay in the gap between his job and the information he could reach. An IT specialist needs access to systems. He does not need to read intelligence reporting. In his unit those two things had become entangled.

Three controls should be designed separately: the access model for administrative roles, monitoring of how that access is used, and supervision of the people who hold it. You do not need to run a classified network for this to apply. If your organization holds tax records, patient files, customer accounts or case notes, you have the same three problems in a different uniform.

Clearance, access and need-to-know are different things

Start with the vocabulary, because the confusion between these words is part of what went wrong.

A clearance is a judgment about a person. After a background investigation, the government decides that someone is trustworthy enough to handle information up to a certain level, such as secret or top secret. It vouches for the person, not for any particular use of information.

Access is a technical and physical fact. It is what a person can actually reach: which buildings and rooms they can walk into, which computers they can log on to, which folders and databases open when they click.

Need-to-know is a judgment about the work. It asks whether this person, in this job, has a mission reason to see this specific material. Classified information is supposed to require both a clearance and a need-to-know. A cleared analyst working on one region does not automatically get to read everything about another.

The trouble is that need-to-know is often enforced coarsely. On a network accredited for a classification level, anyone cleared at that level who can log on may be able to browse much of what is there. Briefing products are often distributed widely so that many people stay informed. So in practice, clearance plus a login can become a stand-in for need-to-know. Nobody decides that a technician should read intelligence assessments; it simply happens because the system does not stop him.

A civilian comparison helps. Suppose a hospital lets every employee with a staff badge open any patient’s chart. The badge (the clearance) says you are a trusted employee. The login (the access) gets you into the records system. But nothing checks whether you are actually treating that patient (the need-to-know). Most staff will behave well. The system, however, is relying entirely on their good behavior.

The access model for administrative roles

An access model is simply the set of rules that decides who can do what inside your systems. It is the organizational chart translated into permissions. In a well-designed model, permissions follow roles: a payroll clerk gets payroll, a nurse gets the charts of patients on her ward, and so on.

Administrative roles complicate this. People who maintain networks, workstations and printers need broad technical permissions. In IT language these are privileged accounts: accounts with the power to install software, reset passwords, change settings and restore lost data. Those permissions concern systems, not content.

A sound access model separates the two wherever technology allows. Administrators get rights to configure, patch and restore systems without rights to open the files those systems hold. Several familiar tools help:

• Encryption with keys held by data owners. Encryption scrambles data so it is unreadable without a digital key. If the key is held by the business owner of the data rather than by IT, an administrator can back up, move and restore the scrambled files without being able to read them.
• Separate administrative accounts with no mailbox or file share access. An administrator uses one account for powerful technical work and a different, ordinary account for email and documents. The powerful account cannot open mail or shared folders at all.
• Role-based access to document repositories. Folders and libraries grant access by job role, so being an administrator of the server does not make you a reader of what sits on it.

Distribution is the other lever. Products pushed to every cleared terminal in a unit keep many people informed, but they also maximize the number of people who can open and print them. Pull-based access, where a reader requests a product and the request is logged against a stated purpose, adds friction for legitimate readers. It also turns need-to-know into a recorded decision that someone can later review. Civilian agencies face the same choice with shared drives and broadcast reports. The weekly briefing emailed to a hundred people is convenient. It is also a hundred copies.

Where separation is impossible, compensating controls must carry the load. Physical access to secure rooms, printers and terminals cannot be split by role in software. A technician who fixes the printer is standing next to whatever it prints. There, the controls are logging, monitoring and supervision.

The same principle applies in civilian agencies holding tax, benefits, health or law enforcement records. A database administrator or desktop technician needs to keep systems running, not to read case files. A practical starting point is a list of every privileged role, the systems it administers, and whether it can also read content. Each yes needs either a fix or a documented reason.

Twelve technicians, two who need the files

Suppose a county social services department holds benefits files for tens of thousands of residents, and its IT team of twelve has full administrator rights on the file servers, because that was the easiest way to let them fix problems. When the county builds the list described above, it discovers that all twelve technicians can open any case file, and that nobody had ever decided they should. The fix has nothing to do with distrusting the technicians. It means giving them separate administrative accounts that can manage the servers but not open documents, and keeping a short, named list of the two people who occasionally need content access for data recovery, with each use logged. The work takes weeks, not years, and it shrinks the number of people who could leak a resident’s file from twelve to two.

Monitoring how access is used

The second control is detection. Even with good design, some people will legitimately be able to reach information they should not read. National policy requires user activity monitoring on classified networks as part of insider threat programs. Many civilian systems holding sensitive data log access too.

Logging means the system keeps a diary: who opened what, when, from which machine, and what they printed or copied. Monitoring means someone, or some software, actually reads that diary looking for trouble. An insider threat program is the organized effort to spot and stop harm caused by people who already have legitimate access, whether through malice, carelessness or coercion.

The value of monitoring depends on whether anyone looks for activity that does not fit the role. Examples include an IT specialist searching for or printing intelligence products, a benefits clerk opening records of people outside the caseload, or a contractor querying records at unusual hours. Monitoring works when it is tuned to role: it asks what this person’s job requires and flags departures from that. Generic rules produce alerts that nobody can review.

Logs are only useful to someone who knows what normal looks like for each role. A benefits clerk opening files in her own caseload during office hours is normal; the same clerk opening records outside her caseload at 3 a.m. is not. Without that sense of normal, every entry looks the same, and the logs become an expensive record of a theft nobody noticed.

That makes the access model and the monitoring dependent on each other. Monitoring needs a documented definition of normal activity for each role. An agency with heavy monitoring but no such definition generates noise. An agency with a clear model but no monitoring never learns when the model is breached. Useful measures include the share of privileged roles with a documented activity baseline, the number of role-deviation alerts reviewed within a set time, and how often reviews lead to action.

Monitoring also carries costs and limits. It requires trained analysts, clear legal authority, and rules on privacy that the workforce understands. It works best when staff know it exists, which deters some misuse on its own. Secret surveillance tends to corrode trust; openly stated monitoring, explained as protection for the mission and for employees, tends to be accepted.

Supervising the people who hold access

The third control is human. Reporting on the case described colleagues and supervisors who had noticed concerning behavior, including searches for material unrelated to his duties. Later reviews examined why that did not lead to decisive action. The pattern is common in insider cases. Someone saw something, but the reporting path was unclear, the behavior seemed minor, or the observer did not want to cause trouble for a colleague.

Supervision of privileged staff needs to be explicit. Supervisors should know what their technical staff can access, which behaviors should prompt a report, and exactly where to report. Reporting is more likely when it is framed as protecting the mission and the individual, and when people see reports handled fairly. If the only outcomes anyone has ever seen are “nothing happened” or “someone’s career was destroyed,” people will keep their concerns to themselves.

Night shifts and small detachments need particular attention. Where technical staff are junior and supervisors are focused on other duties, the people with the broadest access can be the least supervised. This is an uncomfortable inversion that shows up in many organizations: the chief financial officer’s activity is reviewed by auditors, but the contractor who administers the finance system overnight may be watched by nobody.

These controls also limit external attacks. A stolen administrator credential is dangerous for the same reasons a careless insider is. A credential is simply a username and password, or the digital equivalent, and criminals prize administrator credentials because they open so many doors. Separating technical from content access, monitoring by role and supervising privileged staff reduce both risks at once.

The same gaps in banks and hospitals

This story carries a lesson for a bank chief executive or a hospital board as much as for national security officials. The mechanics are the same anywhere sensitive information lives.

Money and reputation. When customer or patient data leaks through an insider, the costs include investigation, notification, legal exposure and lost trust. Customers rarely distinguish between “a hacker broke in” and “an employee walked it out.” Both read as “they could not look after my information.”

Regulators. Financial, health and government regulators increasingly expect organizations to show that access follows business need and is reviewed, and owning security tools does not prove that. A regulator asking “who can read this data and why?” wants an answer more precise than “everyone in IT.”

Staff. Clear rules protect employees too. A technician who cannot open case files cannot be accused of having done so, and cannot be pressured by an outsider into doing so. Good access design removes temptation and suspicion at the same time.

Resilience. Because the same controls blunt an outside attacker using stolen administrator credentials, investment here pays twice. It is one of the rare security measures that addresses two of the largest risks on most boards’ registers with a single program.

Inventories, separate accounts and a named reporting path

The organizations that manage this well do unexotic things. They keep a current inventory of privileged roles, showing which systems each administers and whether it can also read content. Administrators use separate, powerful accounts for technical work, and those accounts cannot open mail or documents. Sensitive reports are made available on request, with the request recorded, rather than broadcast to everyone who might conceivably be interested. Each privileged role has a written description of normal activity, and monitoring flags departures from it. Alerts are reviewed within a set time, and leaders can see how many were reviewed and what came of them. Supervisors, including those on nights and weekends, know what their technical staff can reach and where to report concerns.

The failures are just as familiar:

• Treating the clearance or background check as the whole answer. Vetting tells you about a person at a point in time. It does not limit what they can reach tomorrow.
• Granting broad rights because it is convenient. “Give IT full access so they can fix anything” is the single most common way content access spreads to technical roles.
• Buying monitoring software without defining normal. The result is thousands of alerts, a fatigued team and real warnings lost in the noise.
• Leaving reporting paths vague. If a worried colleague has to work out whom to tell, many will tell nobody.
• Forgetting the night shift. Off-hours operations, remote sites and small teams often run with the least oversight and the most access.

Each control leaves evidence a director can request

A leader does not need to understand the technical detail to test whether these three controls exist. These questions, asked plainly and expecting plain answers, will reveal a great deal:

1. Can you show me a list of every role with administrator rights, and for each one, whether it can also read the data on the systems it manages?
2. Do our administrators use separate accounts for technical work, and can those accounts open email or documents?
3. How many monitoring alerts did we receive last quarter, how many were reviewed within our target time, and how many led to action?
4. If a team member noticed a colleague searching for material unrelated to their job, would they know exactly whom to tell, and have we checked?
5. If an outsider stole one of our administrator passwords tonight, what could they read, and how quickly would we notice?

The questions need no technology background to ask, only someone in the organization who has done the work. If the answers are vague, that vagueness is itself the finding.

With hindsight

The airman pleaded guilty in March 2024 and was sentenced in November 2024 to 15 years in prison. By then, the institutional side of the story had also come into focus.

An Air Force inspector general review made public in December 2023 found that members of his unit had been aware of concerning activity and had not taken proper action. An inspector general is an independent internal watchdog that investigates how an organization performed. Its review cited weak supervision, including of night shift operations, and the Air National Guard disciplined 15 people, including the wing commander, who was relieved.

The same review listed inconsistent definitions of need-to-know and the conflation of classified system access with need-to-know among the factors that enabled the leak, which is the gap described above. Being able to log on had been treated as if it meant being entitled to read. That was a design flaw as much as a personal failing, and it exists in many organizations that have never handled a classified document.

Of the three controls, supervision has proved the hardest to fix. Technical separation and monitoring can be specified, bought and audited. A leader can ask for a list of privileged accounts and get one. A leader can ask whether monitoring alerts are reviewed and see the numbers. Whether supervisors notice and report problems depends on training, staffing and culture, and it is the control most likely to erode without anyone noticing.

The practical conclusion has less to do with espionage than with ownership. Someone in your organization should own each of the three controls by name: the access model, the monitoring and the supervision of privileged staff. The first two are largely engineering problems with clear deliverables. The third is a leadership problem. It shows up in whether a junior colleague on a slow night shift feels both able and expected to say, “This doesn’t look right,” and whether anyone acts when they do.

The starting point was ordinary: a young technician, a valid clearance, a network that let him browse. Most organizations have some version of that arrangement today, and most have not yet asked what it would take to close it.