Hotline: Cybersecurity and Privacy | April 2026

Trust Has an Attack Surface

Dear Hotline: How should cybersecurity teams guard institutional systems and environments from artificial intelligence (AI) agents and agentic browsers? How can institutions ensure that a student, not a bot, is submitting an assignment in the learning management system (LMS)? This issue sits at the juncture between fraudulent students, accounts hacked by phishers, and cheating via bots. Is multi-factor authentication (MFA) sufficient, or are additional or differently layered controls needed? How can this be addressed while maintaining reasonable usability?

Worried CIO

Dear Worried: Two rules of thumb come immediately to mind: if you think you've seen a mouse, you have—and if you've seen one, you have ten. The reason they matter is embedded in your framing: "How should cybersecurity teams guard institutional systems and environments . . . ?" With agentic artificial intelligence (AI), we're not guarding; we're already dealing with an infestation. The threat extends well beyond fraudulent actors and cheating. AI is reshaping workflows, data, and communication across the institution, and security and privacy teams are under pressure to respond. I'll focus on cheating, as it's the question I hear most often and illustrates the complexity of this problem.

To get to the heart of the matter: short of turning your campus into a spiritual retreat with no electronics, there is no silver bullet. MFA is necessary for account protection, but it won't prevent cheating; identity alone is no longer sufficient as a control plane. (It's worth noting that the effectiveness of MFA is eroding; the smart money is on phishing-resistant MFA.^Footnote1) While there is quite a bit you can do to prevent cheating via agentic AI or agentic browsers, the reality is that perfect detection is impossible. Worse, the false-positive and false-negative rates of even the best AI detectors have me questioning their reliability as enterprise tools. An effective set of controls revolves around behavioral signals, device context, and adaptive friction.

When I've been asked to outline an approach to cheating detection, I break the mitigations into five layers. Keep in mind that this is a rapidly evolving space, so what's correct today may be woefully lacking tomorrow.

• Layer 1: Identity trust: passkeys, FIDO2, and automated account compromise detection
• Layer 2: Device context: hardware binding and sophisticated device fingerprinting
• Layer 3: Session behavior: telemetry from typing patterns and mouse movements to find anomalies
• Layer 4: Adaptive friction: intelligent CAPTCHA and "step-up" authentication triggered by suspicious behavior
• Layer 5: Integrity signals: LMS-level data such as draft history, editing telemetry, and instructor-led reviews

It's worth noting that agentic browsers (like MultiOn or Skyvern) behave differently from LLM wrappers—they actually mimic human clicks, which is why Layer 3 (telemetry) is vital.

I included this list for three reasons. First, mitigating AI risks requires gathering and analyzing evidence at multiple layers, not just detection and flagging. Second, because cheating-detection tools are inherently probabilistic, any approach must account for ambiguity—your "Is it cheating?" Magic 8 Ball will usually answer "maybe," not "definitely." Third, if you're exploring cheating-detection tools, this list may serve as a good starting point for analyzing and reviewing vendor solutions.

It's unclear whether there is a technological solution to detect AI-based cheating. The AI arms race is in full swing, and we are definitely at a disadvantage. Keep in mind that many students don't view their use of LLMs or agentic browsers as cheating; they view them as newer tools that differ from spell check in scope and style, not in legitimacy. Institutions will have to address this challenge—which is behavioral and academic—with at least as much effort as those of us in IT organizations are putting in. Ultimately, this is not just a detection problem; it's a redefinition of authorship and assessment.

Tradeoffs Are Inevitable

Dear Hotline: It's a scary time in higher education, particularly with funding freezes and budget cuts. If you had to cut your cybersecurity budget by 30 percent tomorrow, what would you keep, and what would you cut? Why?

CapEx Dreams, OpEx Nightmares

Dear Sandman: Great and timely question, though sadly, this may not be a theoretical exercise. While the CIOs I speak with all tell me they're working to protect their cyber budgets, the reality is that it would be prudent to start serious planning now. This is particularly challenging for cybersecurity because, as I like to say, you can cut services, but you can't cut risk.

Every institution has a unique portfolio of cybersecurity services and functions, so I'm not sure it makes much sense for me to zero in on what to zero out (though I'll take a stab at it below). The real risk to cybersecurity is making cuts without a rigorous understanding of their impact. For example, if you eliminate an expensive item—say, a next-generation firewall—it's easy to find significant cost savings. But these days, a firewall is more than a network ingress filter. It's a security hub that touches almost everything transiting your network. Its impact is ubiquitous across every service.

Approach a cut of this magnitude as a governance, prioritization, and survivability exercise. Develop the equivalent of a business continuity plan and "field test" it through tabletop exercises. By that, I mean something more rigorous than the typical exercise in which the CIO asks each team to submit a list of cuts or positions to eliminate. Existential threats require a planning and analysis effort of similar magnitude.

Focus the tabletop on decision scarcity, not crisis chaos. While most tabletops inject volatility (ransomware, outages, etc.), this one should inject constraint: a fixed budget reduction (e.g., 30 percent), no "magic efficiency gains" allowed, and realistic institutional constraints (HR rules, contracts, shared services). Your goal will be to surface what is truly mission-critical versus what is merely habitual. You'll quickly find where your program is fragile or resilient.

Many tabletop exercises fail because they remain conversational. You want hard outputs. Create a control impact map (CIM) and use it to inform a "keep/cut/transform" matrix. For every major cut, require the CIM to identify which controls degrade or disappear, which framework obligations are affected (e.g., NIST, ISO), and whether the risk is accepted, transferred, or partially mitigated.

A well-designed tabletop for budget cuts should force institutional honesty. You should be able to answer these questions:

• What do we actually value?
• What risks are we truly willing to accept?
• Where are we substituting structure with effort (also known as heroics)?

If participants leave the exercise saying, "We could make this work if everyone just tries harder," it has failed.

My specific recommendations focus on leveraging managerial experience while staying strategic. In a high-scarcity scenario, start by eliminating spending on activities with the lowest marginal security value. Most environments carry redundant tooling, such as multiple agents or platforms solving overlapping problems. Collapse these into a single, broadly capable platform (often your endpoint detection and response solution) and retire the rest. Apply the same discipline to data: stop paying to ingest and index low-value logs in your security information and event management tool. Instead, archive them cheaply for compliance while reserving active monitoring for high-signal events. Strip out low-impact awareness efforts—posters, gamified training, and vanity phishing metrics—and replace them with minimal, targeted education focused on high-risk roles. Finally, reconsider external validation work; if you have a competent internal team, defer "check-the-box" assessments and accept the risk explicitly rather than displacing core staffing.

From there, shift from a "best-of-breed" strategy to a "good enough and integrated" one. Consolidate onto the native security capabilities of your primary platforms (such as Microsoft, Google, or AWS), trading some feature depth for reduced operational overhead and tighter integration. Where possible, centralize functions such as the security operations center into shared services across a system or an enterprise. This sacrifices some local control but may meaningfully reduce duplicated costs in tooling and headcount. Be careful, though. Too often, the cost savings of centralization prove elusive and are the result of magical thinking rather than realistic analysis.

At the same time, define and protect a small set of non-negotiable capabilities. Identity and access management are foundational. If you lose control of authentication and authorization, nothing else compensates. Backup and disaster recovery are equally critical; immutable, reliable backups are what make recovery possible after a major incident. And while tools can be swapped in and out, experienced staff cannot. Losing that institutional knowledge degrades your program in ways that are slow to detect and hard to reverse. Always protect people over tools.

Finally, building on my tabletop comments, treat the entire exercise as a governance shift, not just a cost-cutting exercise. Every reduction should be documented as an explicit risk decision: what control is being weakened and what exposure that creates. Update your risk register accordingly and communicate clearly where coverage is being withdrawn. In some cases, that means formally notifying parts of the organization that they are now responsible for their own risk in specific areas. The goal is to replace implicit, heroics-driven coverage with explicit, institutionally acknowledged risk ownership. I hope that achieving this will allow you to sleep soundly, regardless of a budget crisis.

Heroics Don't Scale

Dear Hotline: Every year, auditors ask for the same documentation. Every year, the IT department scrambles. I want a sustainable program, not an annual panic attack. Responding to the ever-growing list of audit requests is a big time suck. C'est moche. What is an appropriate way to tell leadership that heroics are not a governance strategy?

Audit This, Pal

Dear Pal: Wow. If this question were any denser, it would be a black hole. Black holes might be a great metaphor for audits. They seem to be an intrinsic part of the universe, and they power a lot of fiction. But too often information goes into them, and nothing but faint radiation tunnels its way out. So, let's start with the audit, then address the "time suck," and finally discuss heroics.

Let's talk about audits. For most of my career, auditors have been my best partners. At our annual audit planning meeting, I could point them at problematic areas—both inside the IT department and across campus—and they'd investigate, review, and produce a fine report that essentially said, "Go work with and listen to the security team." It was a great and productive relationship for both of us.

Starting around fifteen years ago, however, I saw a shift from assurance-centric "audit" toward advisory, risk- and maturity-oriented "assessment." That is, the formal, standardized, evidence-based audit that produced a pass/fail or compliant/noncompliant opinion evolved into an evaluative, advisory assessment. These produced recommendations and maturity insights, if not outright roadmaps. Instead of answering whether the department met a predefined bar, the audit assessed where it was, and what it should do next.

This isn't surprising. Modern frameworks are built around assessment models. Of course, there are commercial incentives as well (those matter more than we'd like to admit), but just as important, cybersecurity is not audit-friendly. A traditional audit assumes stable control environments and binary compliance states. But in cybersecurity, controls degrade continuously, and the threats evolve faster than audit cycles. As we all know, "compliant" does not mean "secure." Thus, we end up with continuous evaluation (assessment) over periodic validation (audit). Audits tell you if you passed. Assessments tell you what to do next. Modern cybersecurity demands the latter. All of this is a long way of saying that it's no surprise the auditors are all up in your business.

So, let's turn to the "time suck" of responding to audit requests. When I leave my house, I know I'm coming to a stop sign at the end of the block. I don't wait until I see the stop sign to buy brakes for my car. If you know they're asking for the same documentation every year, you have an opportunity to create pre-defined evidence repositories. Ensure that you identify control owners and establish documentation cadences. Your goal should be to create audit-ready reporting pipelines.

Managing this can be tricky, as it requires you and the auditors to work together to define standard reports and measures. Of course I'm assuming you're all good-faith actors. I have seen some auditors who truly suffer from role confusion and try to manage you and your shop rather than identify and assess risk. I recommend radical transparency and recurring conversations with your auditors. Try to understand their motivations and goals, and help them understand the choices you're making.

As for heroics, to paraphrase, the most difficult heroic act is to remain kind in a world that is not. Bear that in mind as you face the time tariffs of audit demands and unsympathetic management. It's important to remember that the need for heroics is a symptom of low institutional maturity rather than a personal virtue. Heroics feel like commitment, but in governance terms, they are unmanaged risk. The goal is not to perform better under audit pressure but to eliminate the conditions that require performance under pressure at all. While I can't offer any advice about your specific situation or about your particular manager or leadership, culture isn't what we write in the strategic plan; it is the sum of our daily acts. That is to say, do not valorize the heroics you find yourself engaging in by responding to repeated, redundant audit requests. Rather, recognize them as a symptom that your relationship with the audit process needs attention. I'm not talking about collegiality; I'm talking about the working relationship of definitions, planning, goals, metrics, and reporting.

I've written a lot about audits, but your question was really about a usable argument for leadership. The message you want to give to your leadership is this: our current audit response model depends on discretionary effort rather than institutional capability. It is not repeatable, not scalable, and introduces risk. If we expect audit demand to persist—and it will—then we need to fund and formalize it as an operational function, not absorb it through periodic heroics.

In the end, make peace with the presence of audits and assessments in your work plan, and include the time they take in your resource planning exercises. Make sure your management is aware of that demand, but primarily focus on steering the audit process toward benefiting your program and achieving its goals. C'est moche, mais ça se corrige.

Notes

1. CISA has a terrific fact sheet on phishing-resistant MFA. See Implementing Phishing-Resistant MFA (Cybersecurity & Infrastructure Security Agency, October 2022).Jump back to footnote 1 in the text.↩

---

Michael Corn is an Executive Strategic Consultant at Vantage Technology Consulting Group.