Updates

November 2026

Share this update

What changed this month, and what it means for your risk.

Four new pieces of guidance from NIST, CISA and Australia's ASD. None of them is a crisis. All of them change what a well-run security program looks like, and three of them point at the same thing: AI agents are now part of your attack surface, and they need to be governed like everything else.

Edition 2Published November 2026Read time 4 minutes
IdentityShort-lived accessLeast privilegePrompt injectionMicrosoft 365ScubaGear 2.0Configuration driftApp consentGovernanceSP 800-100Risk ownersExecutive oversightAI as an assetShadow AIAgent inventorySupplier assuranceAI agents

This month's theme

AI agents just became an identity problem.

An AI agent that reads your email, searches your files or acts in your systems is doing it with real permissions. This month, NIST, CISA and ASD each published guidance that treats those agents the way we treat people and servers: give them an identity, limit what they can reach, watch what they do, and be able to shut them off.

  1. 01NIST design tenets for AI agent identityHow agents should get, use and lose accessAI governance
  2. 02CISA ScubaGear 2.0 for Microsoft 365A free check of your tenant, now covering AI agentsM365 hardening
  3. 03NIST SP 800-100 Rev. 1 draftSecurity governance, rewritten for executivesRisk management
  4. 04ASD: AI considerations within the EssentialsTreating AI as an asset in ordinary controlsAI governance

AI governance

NIST sets ground rules for AI agent identity.

NIST published ten design tenets for managing the identities of AI agents, drawn from public comments on its agent identity and authorization project.

What it is

A starting point for how agents should be identified and authorized. Each agent gets its own identity, separate from the people who use it. Access is granted when a task starts and expires, instead of living in long-lived keys. The system that decides what an agent is allowed to do sits outside the AI model, and agent activity is monitored for unusual behavior.

Why it matters for risk

An AI model can be talked into things. Content hidden in an email or a document can change what an agent tries to do, which is known as prompt injection. If the agent runs on a person's account or a shared key, it can do anything that account can, and the logs can't tell you whether a person or the agent acted. Separating "what the agent wants" from "what it is allowed" is what keeps a manipulated agent contained.

Potential impact

  • Data leaves through a helper. An agent with broad mailbox or file access is tricked into summarizing and sending sensitive data outside the company.
  • Payment fraud without a person in the loop. An accounts payable agent reads a supplier email with hidden instructions and changes the bank details on an invoice. The money is gone before anyone looks.
  • No clean way to stop it. If agents share credentials with people or with each other, cutting off one agent means disrupting the business.
  • No answer for the auditor. Without a separate identity and logs, you can't show who did what, which matters for incident response, insurance claims and regulators.

Questions to ask your team

  • How many AI agents and connectors are running in our environment, and who owns each one?
  • Does each agent have its own identity, or is it using a person's account or a shared key?
  • If one agent misbehaved today, how quickly could we shut off just that agent?

M365 hardening

CISA's free Microsoft 365 check now looks for AI agents.

ScubaGear is CISA's free tool that compares your Microsoft 365 settings with CISA's secure configuration baselines. Version 2.0 adds a new required policy: block risky AI agents.

What it is

ScubaGear reads the settings in your tenant and reports which ones fall short of CISA's baselines for Entra ID, Exchange, SharePoint, Teams and more. You can also give it a file describing the settings you intend to have, and it flags where the live tenant has drifted from them. Version 2.0 adds a policy requiring risky AI agents to be blocked, which depends on Entra ID P2 and Microsoft's newer agent licensing.

Why it matters for risk

Microsoft 365 holds your email, your files and the identities that unlock everything else. It also changes constantly: admins make exceptions, Microsoft ships new features, and AI agents arrive with permissions of their own. A tenant that was hardened last year is not necessarily hardened today. Drift is how good configurations quietly go bad.

Potential impact

  • Old doors reopen. A temporary exception for legacy sign-in or external sharing becomes permanent and nobody notices.
  • AI agents with no guardrails. Agents added to the tenant can reach mail and files with no risk-based control on what they do.
  • One click, every mailbox. An employee approves an AI add-in that asks to read all mail and files. Without an app consent policy, nobody reviews it and data leaves quietly for weeks.
  • Nothing to investigate with. Audit logging is switched off during a change and never switched back on. After an incident, nobody can say what happened.
  • A report nobody acts on. The tool produces a long list of failed settings, not a ranking of what matters to your business, so the important fixes get lost among the minor ones.

Questions to ask your team

  • When did we last compare our Microsoft 365 settings with a known baseline, and what changed since?
  • Do we have a written record of the settings we intend to have, so drift can be measured?
  • Which AI agents can reach our mail and files today, and what would block a risky one?

Risk management

NIST rewrites its security handbook for executives.

NIST released a draft of SP 800-100 Revision 1, Information Security Handbook: A Guide for Executive Leadership. It replaces the 2006 edition and is organized around NIST CSF 2.0.

What it is

A handbook for the people who oversee security and risk without being hands-on technical staff. It covers governance and risk management and connects them to the operational work underneath: monitoring, configuration, contingency planning and incident response. It is a draft, open for public comment until December 4.

Why it matters for risk

It puts security oversight squarely on leadership, and it expects a line of sight from a business objective to the control evidence that protects it. A risk assessment that lists technical findings without a business owner, a business impact and a way to measure progress will look increasingly thin next to it.

Potential impact

  • A higher bar for boards. Once final, expect auditors, examiners and insurers to use it as a reference for what executive oversight should look like.
  • Findings without owners stall. Gaps that aren't tied to a business objective and an accountable executive tend to sit on a list for years.
  • Colors aren't evidence. "High, medium, low" doesn't show leadership how much risk they are accepting, or whether it is going down.

Questions to ask your team

  • For each major gap, can we name the business objective it threatens and the executive who owns it?
  • Which metrics tell leadership whether our risk is going up or down?
  • Do we want to comment on the draft before December 4?

AI governance

Australia folds AI into everyday security controls.

ASD published AI considerations within the Essentials, a companion to its new Essentials series. It is written for Australian organizations, but it is one of the most practical AI security models available anywhere.

What it is

Guidance that treats AI systems as assets in scope for security, the same as servers and applications. That includes models you build or fine-tune, the infrastructure that hosts them, and AI-enabled security tools. It adds AI-specific points for enterprise IT, cloud and operational technology, and it ties AI back to executive accountability.

Why it matters for risk

Many organizations govern AI with a policy statement and little else. This guidance moves AI into the controls you already run: inventory, identity, least privilege, supplier assurance, logging and recovery. It also makes a point that is easy to miss: with cloud AI services, some of the responsibility sits with your provider and some stays with you.

Potential impact

  • Shadow AI. Teams adopt AI tools outside IT, so they never make it into the inventory, the risk register or the vendor review.
  • Overshared data, found faster. AI assistants surface files people could always technically open but never knew about, like salary sheets or board materials.
  • Vendor terms you didn't read. A provider may keep, train on or process your data in places your contracts or regulators don't allow.
  • Trusted by default. AI-enabled security tools are added and trusted without being assessed like any other system with privileged access.

Questions to ask your team

  • Do we have an inventory of the AI tools and services in use, including the ones IT didn't buy?
  • Do we know what sensitive data our AI assistants can see, and is it classified?
  • For each AI provider, do we know where our data goes, how long it is kept and whether it is used for training?
Share this update

Updates summarize public guidance in our own words and link to the original source. They are for awareness, not legal or compliance advice. If you want to know how any of this applies to your organization, ask us.

Where to start

Not sure which of these matters to you?

That's what a risk methodology is for. Once we know what your business can't afford to lose, each new piece of guidance either moves your risk or it doesn't, and you can tell which in minutes.

Want to know what this means for you?

Tell us which update caught your eye and where your program stands. We'll tell you whether it moves your risk, and what we would do first.

No obligation. We reply within one business day.

Cybersecurity, decided. © 2026 CyberRisk One