Soon your organization will run hundreds or thousands of AI agents. Who has published guidance on keeping them under control, and what should you read first?

TL;DR - Between early 2025 and late 2026, government cyber agencies, standards bodies, security nonprofits, audit associations and analyst firms all published guidance written specifically for AI agents. Most of it is advisory, and the formal control baselines are still drafts. If you read only five things, read the Five Eyes "Careful Adoption of Agentic AI Services" guide, Singapore's Model AI Governance Framework for Agentic AI, the OWASP Top 10 for Agentic Applications, NCSC-UK's two agentic AI blog posts, and ISACA's Cybersecurity Recommendations for Securing AI Agents. The rest of this post is organized by topic so you can go deeper where you need to.

Table of Contents

  1. Why I put this together
  2. If you only read five things
  3. The agents you’re likely to run into
    1. Personal agents
    2. Coding agents
    3. Enterprise agent platforms
  4. What is final and what is still a draft
    1. If you work in or for a federal agency
  5. Agents acting on a human’s authority
  6. Keeping track of many agents
  7. Personal agents at work (BYOAgent)
  8. Protecting the organization’s information
  9. Observability and audit
  10. Human approval, risk tiers and stopping an agent
  11. AI supervising AI
    1. The chief of staff
    2. Guardian agents
    3. Sentinel agents
    4. Cautions that apply to all three
  12. AI-found vulnerabilities, and AI to fix them
  13. Governance, audit and the operating model
  14. Where to watch for what comes next
  15. A caution about the numbers
  16. Keep the conversation going

Why I put this together

I was asked to lead a discussion on trust, observability and control of AI agents at a SIMCAC DC dinner for CIOs. I build Delegate, a platform where people hand work to AI agents, so I read a lot of this material because I had to. This is the reading list I assembled while preparing for that dinner.

It is a list of sources, organized by the questions I expect a CIO to have. I’ve tried to say what each document is, who published it, and whether it’s final. Everything here was current as of November 2026. This area moves monthly, and several of the documents below are drafts that will change.

If you only read five things

  • Careful Adoption of Agentic AI Services, CISA, NSA and the national cyber agencies of Australia, Canada, New Zealand and the UK, May 2026
    • The first joint government guidance written specifically for agentic AI. It covers giving each agent its own identity, least privilege, keeping a human on high-impact or irreversible actions, and starting with low-risk tasks before expanding. It’s also on CISA’s site and ASD’s site.
  • Model AI Governance Framework for Agentic AI, Singapore IMDA, version 1.5, May 2026
    • The most complete government framework I found, and the only one that touches every topic in this post. It is organized around four dimensions: bounding the risks up front, keeping humans meaningfully accountable, technical controls, and end-user responsibility. It also has the plainest statement anywhere of the rule I care most about: the human “should not be able to set permissions for the agent greater than what the human user is himself authorised to do.”
  • OWASP Top 10 for Agentic Applications for 2026, OWASP GenAI Security Project, December 2025
    • Ten risks, from ASI01 Agent Goal Hijack through ASI10 Rogue Agents. If your security team already uses the OWASP Top 10 for LLM applications, this is the agent edition. The full PDF has mitigations for each item.
  • NCSC-UK’s two posts: Thinking carefully before adopting agentic AI (May 2026) and Managing the cyber risk of agentic AI (August 2026)
    • The first is short enough to hand to an executive. Its test is one I’ll be repeating: “If you cannot understand, monitor or contain an agent’s actions, it is not ready for deployment.” The second is the most operational government text I found. NCSC labels it interim, with formal guidance to follow.
  • Cybersecurity Recommendations for Securing AI Agents, ISACA, September 2026
    • Written for people who run audit and risk programs. It asks for an agent inventory where every entry has a named owner, tamper-resistant logs of tool calls and approvals, an approval gate for irreversible actions, and kill switches that work globally and per capability.

The agents you’re likely to run into

The guidance below makes more sense if you know what’s actually showing up in your environment. Roughly, there are personal agents that employees adopt on their own, coding agents that developers adopt, and enterprise platforms that IT buys and governs. The first two often arrive before anyone in IT has signed off. Every vendor below publishes its own security and admin documentation, and it’s worth asking for it before a pilot.

Personal agents

These act on one person’s behalf, usually in a browser or on their desktop, with whatever access that person has.

  • ChatGPT agent, OpenAI
    • Runs multi-step tasks in its own cloud sandbox. OpenAI also ships an AI browser, ChatGPT Atlas.
  • Claude Cowork and Claude in Chrome, Anthropic
    • Cowork works with the files on a person’s own computer. The Chrome extension acts in their logged-in browser.
  • Gemini Agent, Google
    • Google’s agent mode in the Gemini app.
  • Comet, Perplexity
    • An AI browser that acts on the tabs a person already has open, including their email and calendar.
  • OpenClaw
    • An open-source personal agent that people install themselves, and a good example of why this category worries security teams. It runs with broad local access and connects to services like email and payments. An ICML 2026 paper, Your Agent, Their Asset, is a careful safety analysis of it. If your endpoint tooling can’t see installs like this, they’re shadow AI.

Coding agents

These have the deepest access of anything here: source code, terminals, and often cloud credentials.

Enterprise agent platforms

These are bought and administered centrally. Most now include some kind of agent registry, identity, and policy layer, which is where the governance topics below become product features you can evaluate.

Gartner named Microsoft, IBM and ServiceNow as leaders in its first Magic Quadrant for AI Agent Management Platforms, reported on November 2, 2026.

What is final and what is still a draft

Check the status of anything here before you cite it in a policy or an authorization package. There is plenty of final, advisory guidance. Formal control baselines for agents mostly don’t exist yet.

The Five Eyes guide, the IMDA framework, the NCSC posts, the OWASP Top 10, MITRE ATLAS, the ISACA paper, the CIS companion guide and the CoSAI papers are all published. These are still in progress:

If you work in or for a federal agency

The practical result for a federal CIO is that there’s no agent-specific control set to point to in a system security plan today. You are left applying existing SP 800-53 controls to agents as non-person entities, with the Five Eyes guide as the nearest thing to a deployer baseline. OMB’s M-25-21 doesn’t mention agents, but its “high-impact AI” test can apply to an agent whose output drives rights- or safety-impacting decisions. The Congressional Research Service reported in February 2026 that DoD had no official guidance specific to agentic AI. GSA’s internal directive CIO 2185.1C now requires AI use cases to carry an “Agentic AI” label, the first federal inventory category for agents I’ve seen.

The NIST material worth following:

Agents acting on a human’s authority

The principle behind everything else here is that an agent should act only on authority a person delegated to it, and never on more than that person holds. Several bodies now say so directly.

  • MITRE ATLAS, MITRE’s knowledge base of attacks on AI systems, modeled on ATT&CK
    • The v2026.10 release has 129 techniques and 44 mitigations, and its agent mitigations have the most precise wording on delegation that I found. AML.M0027: “The user’s permissions establish an upper bound; the agent should not automatically receive every permission available to that user.” AML.M0026 says permission to invoke an agent must not confer all of its authority. AML.M0037 says an agent’s maximum authority has to be granted before it runs, and can’t depend on the system prompt or on the model noticing that an action is out of scope.
  • Identity Management for Agentic AI, OpenID Foundation, October 2025 (announcement)
    • Written by 21 identity practitioners. It describes moving agents from impersonating users to explicit delegation, where the token names both the human and the agent. It’s also candid about what’s unsolved, and calls revoking delegated access “a critical, and largely unsolved, problem.”
  • Agentic Identity and Access Management, Coalition for Secure AI (CoSAI, an OASIS project), March 2026
    • Nine identity imperatives, including zero standing privilege and keeping an agent’s own rights separate from the rights it holds on someone’s behalf. It also requires that “delegation chains MUST remain visible in credentials and logs.”
  • Agentic AI Identity and Access Management: A New Approach, Cloud Security Alliance, August 2025
    • Just-in-time, task-scoped credentials and global revocation.
  • AEGIS, Forrester, August 2025 (introduction)
    • The source of “least agency”: limiting what an agent can decide and do even when it has access. OWASP uses the same idea in its Top 10. I find it a useful distinction for a board audience. Least privilege limits what an agent can reach, and least agency limits what it can decide.
  • ITIL AI Governance white paper, PeopleCert, November 2025
    • Describes staged delegation. AI starts by making recommendations, moves to making decisions that humans can audit, and later operates autonomously “within carefully defined parameters.”

For your architects, the protocol work:

Keeping track of many agents

Gartner forecasts that the average Fortune 500 company will have over 150,000 agents in use by 2028, up from fewer than 15 in 2025. The same release says only 13% of organizations think they have the right governance for them, and lays out six steps for managing sprawl, starting with an inventory that finds shadow agents as well as sanctioned ones.

  • The machine identity counts are already large. CyberArk reports more than 80 machine identities per human. Palo Alto Networks reports 109 to 1, and says only 37% of organizations can revoke an AI agent’s credentials. These are vendor surveys and vendors count differently, so treat them as a range.
  • The OWASP Non-Human Identities Top 10 predates agents but maps straight onto them. Number one is improper offboarding.
  • CoSAI’s identity paper says “all agents, regardless of capability or risk classification, SHOULD be registered and monitored,” and asks organizations to be able to “prove control on demand”: which agents existed, what they were allowed to do, and what they did.
  • NCSC’s May post gives the ownership questions to answer before an agent touches a real system: who owns it, who approves its access, who monitors it, who reviews incidents, and who can stop it.
  • MITRE ATLAS mitigation AML.M0043 treats resources an agent creates as lifecycle-managed assets, because they can outlive the agent. Technique AML.T0103, Deploy AI Agent, covers an attacker planting a shadow agent of their own.

Every framework asks for a registry, and nobody has published a registry standard yet. The efforts underway are the Cloud Security Alliance’s Agent Registry Specification (status not stated), the W3C community group mentioned above, and an ITU-T focus group on trust and identity for agents.

Personal agents at work (BYOAgent)

Shadow AI is turning into shadow agents. I’ve been calling it BYOAgent, after BYOD. An employee installs a personal agent such as OpenClaw, ChatGPT agent, Claude Cowork or an AI browser, then points it at work email, files and SaaS accounts with their own login. Microsoft’s 2024 Work Trend Index found that 78% of AI users were already bringing their own AI tools to work, and that 52% of people who use AI at work were reluctant to admit using it for their most important tasks. That survey predates most agents, so read it as a floor.

What organizations have done about it:

  • Gartner told CISOs to “block all AI browsers for the foreseeable future,” covering browsers like Perplexity Comet and ChatGPT Atlas that can navigate and complete transactions on their own. The research note is paywalled. CSO Online’s December 2025 coverage quotes it and cites Cyberhaven data showing 27.7% of organizations already had at least one user with Atlas installed.
  • Wired reported in February 2026 that a Meta executive told his team to keep OpenClaw off their regular work laptops “or risk losing their jobs.” The CEO of Massive told staff the agent was “unvetted and high-risk” and asked them to keep it “off all company hardware and away from work-linked accounts.” Valere banned it, then let its research team run it on an old computer to find the flaws.
  • In South Korea, Kakao, Naver and Karrot Market restricted OpenClaw on corporate networks and work devices. Kakao said it acted “to protect the company’s information assets” (Korea Times, February 2026).
  • In March 2026 Chinese authorities told state agencies and state-run banks not to install OpenClaw on office devices, according to Bloomberg’s reporting (Tom’s Hardware summary). Other coverage describes it as a warning with approval and disclosure requirements, short of a formal ban.

The implications, with the sources that speak to each:

  • A personal agent using an employee’s login won’t show up in your agent inventory, and its actions are logged as the employee’s. The OpenID Foundation paper calls that pattern “a black hole for accountability and forensics.”
  • The data goes to a service the organization can’t audit, retain or recall. Gartner’s Evgeny Mirolyubov, quoted by CSO Online: “the loss of sensitive data to AI services can be irreversible and untraceable.”
  • When the employee leaves, the agent may keep working with their tokens. Improper offboarding is number one on the OWASP Non-Human Identities Top 10.
  • It already shows up in breach costs. IBM’s 2025 Cost of a Data Breach found that one in five organizations reported a breach due to shadow AI, and that heavy shadow AI use added $670,000 to the average breach. That figure covers AI tools generally, not agents.
  • A ban doesn’t remove the demand. Microsoft’s finding that half of AI users hide what they use suggests a ban mostly removes visibility. NIST’s SP 800-46 Rev. 2, the federal guide to telework and bring-your-own-device security, is the closest precedent for allowing personal tools under controls instead of forbidding them.

My view is that BYOAgent will go the way of BYOD. Organizations that only prohibit it will lose track of it. Organizations that register personal agents, scope what they can touch, and can cut them off will at least know what’s running.

Protecting the organization’s information

The security community has largely accepted that prompt injection can’t be reliably filtered out, so the advice has moved to architecture. Start with these two short pieces:

  • The lethal trifecta for AI agents, Simon Willison, June 2025
    • An agent with access to private data, exposure to untrusted content, and a way to communicate externally can be tricked into sending your data out. If you only read one thing on prompt injection, read this.
  • Agents Rule of Two, Meta, October 2025
    • A working version of the same idea. A session may have at most two of these properties: processing untrusted input, accessing sensitive data, and changing state or communicating externally. A session that needs all three needs supervision.

Then the deeper material:

  • NIST CAISI ran a red-teaming competition with Gray Swan: more than 250,000 attack attempts from over 400 participants, with at least one successful attack against every target model. The earlier agent hijacking evaluations post explains how NIST tests for this.
  • MITRE ATLAS technique AML.T0086, Exfiltration via AI Agent Tool Invocation, describes data smuggled out inside a legitimate-looking tool call. Mitigation AML.M0030 suggests blocking automatic tool use once untrusted data is in the agent’s context.
  • NCSC’s August post has maturity ladders for network access (from unrestricted to no external access) and compute isolation (from none to dedicated hardware). It recommends proxies that inject credentials “so the agent never sees them.”
  • CoSAI’s Model Context Protocol Security paper, version 2.0 from August 2026, defines 12 threat categories and four assurance levels, from sandbox to regulated. The version 2.0 announcement is a good summary.
  • OWASP’s MCP Top 10 is in beta, and its guide to secure MCP server development came out in February 2026.
  • The Cloud Security Alliance’s MAESTRO is a seven-layer threat model for agentic systems. It is one of the few that treats the monitoring tools themselves as attack targets.
  • CIS published an AI Agents Companion Guide to CIS Controls v8.1 in April 2026, with separate guides for LLMs and MCP.
  • Singapore’s Cyber Security Agency published Securing Agentic AI, an addendum to its AI security guidelines, in June 2026.
  • For data protection in general, CISA, NSA and FBI’s AI Data Security guide from May 2025 is the federal baseline. It isn’t specific to agents.

Several of these say the same thing about credentials. The IETF AIMS draft says the model “MUST NOT have access to an agent’s credentials” and that “static API keys are an antipattern for agent identity.” OWASP’s Top 10 says keys “must never be directly available to agents.”

Observability and audit

An agent’s own account of what it did is not evidence. The record of what it did is.

  • The IETF AIMS draft puts it most directly: “Observability is therefore a security control, not solely an operational feature.”
  • The OpenID Foundation paper explains what goes wrong without it. When agent calls are logged as the user’s actions, you get “a black hole for accountability and forensics.” It recommends recording both the human and the agent in every entry.
  • The OWASP Top 10 PDF asks for immutable, signed logs of actions, tool calls and messages between agents.
  • The October 2026 NIST, NSA and CISA Key Practices call for telemetry across the model, the harness, the host and the network. They also say to keep the tool calls an agent attempted and was refused, and to protect the monitoring tools from the agents they watch.
  • NCSC’s August post says to treat agent activity like user activity in your SOC, and to make agent traffic identifiable to the third parties it reaches.
  • The Partnership on AI’s work on AI agents includes a piece on the observability gap, the finding that current agent frameworks don’t consistently produce the records enterprises need.

Here the sources disagree. NCSC recommends capturing an agent’s chain-of-thought reasoning, while IMDA cautions that chain-of-thought “may not be a faithful explanation” of why the agent acted. A reasoning log shows what the model said, which isn’t necessarily why it did something.

In ISACA’s 2026 AI Pulse Poll, only 43% of respondents were highly confident they could investigate and explain a serious AI incident.

Human approval, risk tiers and stopping an agent

The closest thing to an international consensus is that the stakes and reversibility of an action decide whether a person has to approve it. IMDA lists the triggers as “permanently deleting data, sending communications, making payments.” MITRE ATLAS AML.M0029 says human review “should follow the degree of consequence.”

Several bodies have published tiering models you can borrow:

  • The Cloud Security Alliance’s Agentic Trust Framework (February 2026) moves agents through four levels, Intern, Junior, Senior and Principal, with promotion gates between them. It’s openly licensed.
  • CoSAI’s identity paper has a capability-versus-risk matrix tied to autonomy levels.
  • The ITIL AI Governance white paper pairs staged delegation with mandatory intervention thresholds for high-risk, low-confidence, ethical or regulatory cases.
  • NCSC’s August post distinguishes humans in, on and out of the loop, and suggests running agents during office hours before letting them run overnight or on weekends.
  • The Partnership on AI’s Prioritizing Real-Time Failure Detection in AI Agents ties the level of monitoring to stakes and reversibility.

Approval fatigue is a named risk. OWASP’s Agentic AI Threats and Mitigations lists it as threat T10, “Overwhelming Human-in-the-Loop,” meaning an attacker can deliberately flood approvers. IMDA suggests measuring it: a low human override rate “may signal rubber-stamping,” and very fast approvals may signal review fatigue. The ITIL white paper argues the scale problem from the other direction. AI systems “cannot pause for human approval on each decision,” so governance has to move “from approval-based governance to guardrails-based governance.”

On stopping agents:

  • ISACA asks for global and per-capability kill switches with rollback, and its October 2026 article The Pathway to Securing Agentic AI says to “treat AI agents like privileged accounts” and to test the kill switch.
  • IMDA says to deny by default when the approval system itself is down.
  • A PeopleCert post on ITIL AI Governance controls says AI with wider organizational impact needs “human oversight and the option to have an ‘off’ button.”
  • No standard defines a kill switch for a fleet of agents. In practice you build one from short-lived tokens, revocation signals and de-provisioning.

ISACA’s poll found that only 36% of organizations have humans approve most AI actions before they run, and 56% don’t know how quickly they could halt an AI system after an incident. A follow-up post adds that 39% don’t know whether their organization has a documented shutdown process. Those figures cover AI generally, not agents specifically.

AI supervising AI

Several different ideas tend to get lumped together under this heading, and I think they should be kept apart. A chief of staff is the agent a person works with most. A guardian is a small, narrow agent attached to a single task agent. A sentinel watches systems instead of agents. None of these terms has a standard definition. The definitions below are mine, and the sources are the closest published material I found.

The chief of staff

This is the agent you interact with more than any other. It keeps up with what your other agents are doing in general, creates new agents and disables ones you no longer need, and gives general direction to the agents working for you. It keeps you informed about the things that matter and handles the rest. None of the sources below use the term “chief of staff.”

  • Anthropic’s Building effective agents (December 2024) names the underlying pattern orchestrator-workers: “a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results.”
  • Anthropic’s How we built our multi-agent research system (June 2025) is a worked example. A lead agent “analyzes it, develops a strategy, and spawns subagents,” combines what they find, and decides whether to launch more.
  • The ITIL AI Governance white paper would put a chief of staff under its Coordination capability (“AI autonomously executes, orchestrates, or triggers actions across systems”), which it rates high for autonomy risk.
  • A chief of staff that creates and disables agents is doing lifecycle management, so the sources in the section on keeping track of many agents apply to every agent it creates. CoSAI says every agent should be registered and monitored. OWASP ranks improper offboarding as the top non-human identity risk, and MITRE ATLAS AML.M0043 warns that resources an agent creates can outlive it. ISACA’s kill switches, covered in the approval section, are how you disable them.
  • So does the delegated authority rule. IMDA’s framework says a person can’t give an agent more permission than they hold. A chief of staff acting for you can’t give the agents it creates more than you hold either.

Guardian agents

A guardian is paired with a task agent. It is usually a smaller model with one job: classifying the task agent’s proposed actions as allowed or not allowed, and blocking the ones that aren’t. It acts as a guardrail. My view is that every task an agent takes on should have a guardian assigned to it.

Gartner coined the term, and its definition is broader than mine:

  • Gartner’s June 2025 release describes three roles: reviewers that check output, monitors that track actions, and protectors that can adjust or block actions at runtime. The protector role is closest to what I mean. Gartner forecasts guardian agents at 10 to 15% of the agentic AI market by 2030. Its first Market Guide for Guardian Agents came out in February 2026 and is paywalled. This vendor-written summary is the most detailed public account I found.
  • OWASP’s Agent Control Standard (version 0.1, September 2026) is the closest thing to a spec. Its Guardian Agent sits at hooks in the task agent’s lifecycle and can allow, deny, modify, escalate to a human, or defer each action. Deterministic policy always runs before any model-based judgment. The repository notes that its reference implementation currently fails open by default, so treat it as an early spec.
  • IMDA endorses “using agents to monitor other agents” alongside human oversight, and OWASP’s Top 10 recommends watchdog agents that validate other agents’ behavior.

Several open models are small enough to run beside every task agent:

  • Meta’s LlamaFirewall (May 2025) is “an open source guardrail system for building secure AI agents.” It combines PromptGuard 2, a jailbreak detector, with an alignment check that audits the agent’s reasoning and CodeShield, a static analyzer for generated code. Meta’s PurpleLlama repository also has Llama Guard 3 in 1B and 8B sizes.
  • IBM’s Granite Guardian models come in sizes from 2B to 8B, plus much smaller filters. They cover “hallucinations related to tool calls and retrieval augmented generation in agent-based systems,” which makes them one of the few families built to check what an agent is about to do.
  • Google’s ShieldGemma comes in 2B, 9B and 27B sizes and evaluates text “against a set of defined safety policies.”
  • NVIDIA’s NeMo Guardrails is an open-source toolkit for wiring rules and classifier models around an LLM application.

Most of these models were built to moderate content. Using them to decide whether an agent may take an action means writing your own policy for them to classify against, and testing it.

Sentinel agents

A sentinel is a watcher. It monitors the state of a target system or process, and when something goes wrong it can take intelligent action, which a traditional threshold alert can’t. It can resolve the issue, open a ticket, or bring in other agents as needed. The way I’d build one, the sentinel first writes the scripts that do the condition monitoring. Those scripts run on their own, and the sentinel is invoked only when one of them returns a failure it was told to watch for. It can also be invoked on a schedule to run deeper checks. The effect is like having a focused expert assigned to every part of a mission-critical system. As with the other two, the term and the definition are mine.

The closest published material:

  • The monitoring chapter of Google’s Site Reliability Engineering book sets the standard that heuristic alerting is usually measured against: “Every page should be actionable. Every page response should require intelligence. If a page merely merits a robotic response, it shouldn’t be a page.” A sentinel takes on the responses that need some intelligence but don’t always need a person.
  • NIST SP 800-137, Information Security Continuous Monitoring, is the federal baseline for continuous monitoring. It predates agents, but it’s the program a sentinel’s monitoring would sit inside at a federal agency.
  • Microsoft’s Azure SRE Agent is the closest product I found. On an alert it “queries your monitoring tools, correlates signals across systems, identifies probable root cause, and proposes mitigations.” It can also run scheduled “proactive health checks, compliance sweeps, and routine operational tasks,” and it creates or updates tickets in ServiceNow or PagerDuty. In its Review mode an administrator approves write actions, and in Autonomous mode it applies them without waiting.
  • AWS DevOps Agent (preview December 2025, generally available March 2026) “identifies probable root causes and recommends targeted mitigations,” and updates linked tickets as its investigation goes.
  • PagerDuty’s SRE Agent (March 2026) describes itself as a “virtual responder” and can be started automatically from an incident workflow.
  • The script-first part of the pattern draws on Anthropic’s Code execution with MCP (November 2025), which describes agents writing code to work with their tools. It notes that “agents can also persist their own code as reusable functions.”

A sentinel that can restart a service or roll back a deployment has standing write access to production, and it often runs when nobody is watching. NCSC’s advice to run agents during office hours before letting them run overnight applies directly, and so does the Key Practices point about protecting monitoring tools from tampering. Writing the checks as scripts helps here. The monitoring itself is deterministic code that a person can review, and the model only gets involved once a check fails.

Cautions that apply to all three

  • MITRE ATLAS AML.M0029: “dedicated audit agents, may assist human approval, but final adjudication should be conducted by a human decision-maker.”
  • NCSC: “‘Judge’ AI models need independent evaluation, as they have their own limitations.”
  • The NIST, NSA and CISA Key Practices say monitors must be protected from the agents they monitor.
  • The World Economic Forum’s AI Agents in Action (November 2025, with Capgemini) flags the risks of agents monitoring agents.
  • MAESTRO models attacks on security agents themselves.

My reading of all this: a chief of staff is defensible if it acts only on authority you delegated, can’t hand out more than you hold, and logs every agent it creates or disables. A guardian is defensible if it sits behind deterministic policy, is owned and evaluated separately from the task agent it guards, and sends irreversible decisions to a named person. A sentinel is defensible if its monitoring scripts are reviewed like any other code, its fixes stay inside a runbook a person approved, and anything outside that becomes a ticket for a person. That’s my synthesis. No single framework states it.

AI-found vulnerabilities, and AI to fix them

This sits next to agent governance, and it’s the strongest reason I know to let agents take defensive action. AI systems now find software vulnerabilities faster than the people who maintain that software can fix them. My view is that the only workable response is to have AI do much of the defensive work as well, from applying mitigations and patches to enforcing policy. No framework says “only” in so many words. The sources below are the evidence I’d point to.

AI is finding more vulnerabilities:

  • Anthropic’s report on AI-found zero-days (February 2026) says one of its models found and validated more than 500 high-severity vulnerabilities in open-source projects. Its Project Glasswing page (April 2026) says an unreleased model has since found thousands, including flaws in “every major operating system and web browser,” and describes giving defenders early access so those get fixed first. Both are the vendor’s own claims.
  • Google’s summer 2025 security update says its Big Sleep agent found CVE-2025-6965, a SQLite vulnerability attackers were preparing to use. Google calls it “the first time an AI agent has been used to directly foil efforts to exploit a vulnerability.”

The volume is outrunning the system that tracks it:

  • NIST’s April 2026 announcement, NIST updates NVD operations to address record CVE growth, says CVE submissions rose 263% between 2020 and 2025, and that the first quarter of 2026 ran nearly a third higher than the year before. The National Vulnerability Database now fully analyzes only CVEs in CISA’s Known Exploited Vulnerabilities catalog, CVEs in software the federal government uses, and CVEs in software designated critical. NIST doesn’t say what is driving the growth, so connecting it to AI discovery is an inference.
  • Jerry Gamblin’s 2025 CVE data review counts 48,185 CVEs published in 2025, up 20.6% from 2024. It’s an independent analysis of the public CVE data, and the easiest place to see the year-by-year trend.
  • NCSC-UK’s assessment Impact of AI on cyber threat from now to 2027 (May 2025) says the time between disclosure and exploitation “has shrunk to days and AI will almost certainly reduce this further.” It also predicts a “digital divide” between systems that keep pace with AI-enabled threats and the many that don’t.

The evidence that AI can do the defensive work:

  • DARPA’s AI Cyber Challenge results (August 2025). In the final round, the teams’ autonomous systems found 86% of the planted vulnerabilities and patched 68%. A patch took 45 minutes on average and a task cost about $152. The systems also turned up 18 real vulnerabilities in open-source code. DARPA’s director said “finding vulnerabilities and patching codebases using current methods is slow, expensive, and depends on a limited workforce.”
  • Google DeepMind’s CodeMender (October 2025) is an agent that writes and validates security patches. Google says it had upstreamed 72 fixes to open-source projects, and that “it will become increasingly difficult for humans alone to keep up.” Human researchers review every CodeMender patch before it is submitted.
  • NIST’s draft Cyber AI Profile (IR 8596, initial preliminary draft, December 2025) has three focus areas. One of them is “Conducting AI-Enabled Cyber Defense.” It’s the closest thing to a federal framework for this so far.

A defensive agent that can patch production code or change firewall rules holds some of the widest permissions in the organization. Everything earlier in this post applies to it: a named person delegating its authority, a record of every change it makes, and a human approving the changes that can’t be undone. CodeMender’s review step is one working example.

Governance, audit and the operating model

  • ITIL AI Governance white paper, PeopleCert, November 2025 (announcement)
    • The paper only uses the word “agent” inside a statistic it cites. Its 6C AI Capability Model covers agents anyway, under the capability it calls Coordination: “AI autonomously executes, orchestrates, or triggers actions across systems.” It rates Coordination high for autonomy risk. It also describes four governance patterns (Directive, Guided, Federated and Autonomous) for distributing decision authority across a large organization, which is the part I found most useful for operating-model discussions. The related certification is ITIL AI Governance (Version 5).
  • ISACA
  • The Institute of Internal Auditors
  • Forrester
  • Gartner
    • It predicts that over 40% of agentic AI projects will be canceled by the end of 2027. The same release estimates that only about 130 of the thousands of vendors marketing “agentic” products offer real agents.
  • OECD

Where to watch for what comes next

Most of the gaps above are actively being worked on. These pages are where the next versions will show up:

A caution about the numbers

Most agent statistics are forecasts or vendor surveys. I could only read Gartner’s figures through trade press coverage of its press releases (The Register for the agent sprawl numbers, IT Pro for guardian agents, CSO Online for the AI browser advice), so check the release itself before you put a Gartner number on a slide. Machine identity ratios range from 17 to 1 up to 144 to 1 depending on which vendor is counting. The ISACA poll covers AI in general. None of that makes the numbers useless, but cite the publisher and the date when you use one.

Keep the conversation going

Have an opinion on this, or a source I missed? Twitter me about it