Most organizations are stuck in the gap between thinking about GenAI governance and doing it. Perhaps a policy exists, but the tools are already in production and employees are wiring them into business systems faster than anyone is accounting for.

Managing the risk introduced by these systems is on every CISO’s 2026 priority list, but treating all risks as equally urgent is how well-intended AI security initiatives stall. So the work starts with prioritization: rank GenAI risks by what each would actually cost the business, and apply your controls accordingly. What follows is where I’d start, and why agentic risk sits first.

Rank the risk by what it would cost you

GenAI risk is not just a technology problem. Your challenge is identifying where it impacts your business processes, determining the magnitude, allowing that to show you which failures would hurt most. 

For agentic risk specifically, there is a shift in how you size the exposure. The old decomposition, scoped by records exposed or data accessed, doesn’t fully capture what an agent can do. The magnitude that matters now is the reachable privileged actions (the blast radius), and a frequency term I expect to keep climbing. That reframing, based on what an agent can reach and break, is the part most models underestimate. Quantifying that financial exposure can move the internal conversation from abstract to actionable, and it’s what tells you where the next control belongs.

Here are the scenarios I modeled around:

Agents taking actions they shouldn’t. Thin authorization models lead to problems, and the incident-response cost compounds with both frequency and scope. OWASP’s Top 10 for Agentic Applications (2026) prioritizes identity and privilege abuse with agents operating with permissions inherited from whoever configured them, no scope limits, no runtime monitoring, and coins “least agency” as the discipline of granting only the autonomy a task actually needs. In April 2026 at the SaaS company PocketOS, a well-known AI coding agent hit a credential mismatch during a routine task and decided on its own to fix it by deleting a cloud storage volume. It went looking for an API token, found one in an unrelated file whose permissions weren’t scoped to that action, and deleted the production database and all volume-level backups in a single API call. Nine seconds; a 30-plus-hour outage; recovery only from a three-month-old backup until the infrastructure provider restored the rest. The agent did exactly what its access allowed, which is why this risk sits first.

Data security through the periphery. A close second, and the most underinvested. Although the first instinct is to scrutinize the AI model and its training data, the most weakly governed surface is everything bolted around the model: the skills, plugins, and connectors that reach into your systems. CISA and ASD’s May 2026 guidance speaks directly to this risk, but in most organizations those integrations multiply faster than anyone tracks them. The mechanics are shared with any shadow IT: an employee installs a plugin, adds a browser extension, or routes a workflow through an unapproved connector, but the effect can be unintentional data exposure either by design (gratuitous retention policies) or malice. The attackers have certainly noticed the latter. In early 2026 the ClawHavoc campaign flooded an agent-skill registry with hundreds of malicious skills in a matter of days, harvesting API keys, credentials, and cloud tokens, and in several cases writing persistent instructions into agents’ own memory files. Yet many organizations have no review process standing between an employee and a new skill.

Overreliance. When AI tools go down, organizations that built critical workflows on top of them find a business-continuity gap they hadn’t modeled. Unless you’re self-hosting, your model provider is now a single point of failure you don’t control.  According to the 2026 AI Index report, agentic AI adoption is most prevalent in the domains of IT, knowledge management, and marketing or sales, and typically show 5-10% “scaling” or “fully scaled” agentic AI usage. But based on what I’ve seen in my role in 1H 2026, I expect adoption numbers to at double to triple by the end of 2026.  Also, considering how much IT and knowledge management cross-cut business functions, this significantly increases the impact of an outage.

Policy versus governance

The most common way an organization thinks it has GenAI governance when it doesn’t: it has a policy document.  But without enforcement, observability, and clear ownership, it doesn’t change what people actually do.

The foundation for the GenAI policy is likely your IT productivity suite. Select a major AI provider that’s already integrated, and move people onto a managed tier that gives your security in infrastructure team visibility and controls. This is your first encouraged pattern, rather than your policy turning into a long list of prohibitions.

To ensure your policy lays the foundation for proper governance, consider how you will conduct audits and grant approvals.  Some of this is augmenting your vendor risk management program, but increasingly requires focus on open source components and marketplaces for skills, plugins, and extensions.  In a Technology organization, you’ll also need to account for the fact that non-engineers are now developing and contributing code and building systems, so AI specific design principles are a must.

One “gotcha” with policy is the system interface working against the intent. For example, your policy might read that you have to have a human in the loop for all decisions.  But if you build a workflow where the UX strongly pushes one choice, like an “accept all” or “don’t ask me again” option, you’ve effectively removed the control you thought you had. This pattern is one to watch out and audit on both homegrown systems and common productivity tools. 

Classification-driven governance

The structural fix is to let the level of oversight scale with the level of autonomy. A flat policy that applies the same rules to every use case produces governance that’s either too restrictive to use or too permissive to protect anything. An employee drafting a document with an AI tool needs different controls than a developer running an agent that reads and writes to production.

At Resilience, we formalized this as a four-tier autonomy model. Advisory uses, drafting, summarizing, brainstorming, sit at Level 0 with no additional controls beyond privacy and contractual protections. Coding assistants and tools where a human approves each action before it executes sit at Level 1. Agents with bounded autonomy on shared infrastructure require CISO approval and a defined set of technical controls. Level 3, full autonomy for sensitive actions, is not currently allowed.

Action security, and the trail you need to investigate it

The mental model many CISOs are updating is the shift in importance between data security and action security. Given the state of controls in most businesses, what matters most is what an agent can do, to which systems, without a human checking each step.

For any agentic workflow, five data points are the minimum viable audit trail: the agent identity, the human principal who authorized the action, the action itself, the target system, and the timestamp. When those five aren’t being captured, one of two things is true: either the organization has validated agent autonomy to the point it no longer needs the tie to a human identity, or it hasn’t engaged with the risk of agent actions at all. Very few are in the first group. Usually the telemetry just isn’t there, which means that when an agent does something it shouldn’t, there’s no forensic trail to work from.  As adoption accelerates, investment in observability is going to separate the security teams that can respond from the ones that can’t.

Where to start if you’re starting from scratch

We’ve already discussed the importance of a grounded and enforceable policy.

From there, order the controls by how much risk they generally remove, but tailored to your business processes. A few I’d recommend emphasizing:

• Role-based access control and reviews scoped to what each agent or tool actually needs. The PocketOS deletion turned on exactly this: an over-scoped token sitting where an agent could find it.
• Observability and cost controls. A cost anomaly is often the first signal that something is running outside its intended scope.
• A review process for plugins, connectors, and skills, since most organizations have no systematic way to evaluate a new integration before it goes in.
• Software Supply Chain Management. As attacker tradecraft accelerates, perimeter-device exploitation, CI/CD misconfiguration, software-supply-chain compromise, phishing and vishing, the frequency on all of those perils moves the same direction.
• Security-team AI adoption: automated code review, automated dependency review, AI built into SecOps and configuration management. If you’re not using these tools yourself, you’re working at a speed disadvantage.
• AI-specific tabletop exercise. This is where you can test your assumptions.

The prerequisite for all of it is executive ownership. When security, engineering, and the business pull in different directions on GenAI, governance stalls at the document until someone at the executive level decides the governed path is the path. Without that decision, every control you build is a suggestion.

The CISOs putting proper governance in place now will be the most prepared to respond to incidents in any GenAI-enabled business. If you haven’t already started, the time to invest is now.

Nothing here should be taken as legal, financial, or security advice for your specific situation. See the full disclaimer at cyberresilience.com/disclaimer.