Today, the question is not how many people sit on a security team, but whether the people already there can account for actions that machines now perform on their behalf, writes Nik Kale, CISSP.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
I’ve spent the last year attending many design reviews, for AI systems that are about to be deployed to production. A pattern is beginning to emerge: teams present a demo of an agent that can investigate an alert, correlate telemetry across tools and even make a recommendation to take a containment action; then someone asks who will own the decision when the agent actually executes. And… the room is silent.
This silence points to a workforce question that no one seems ready to answer. ISC2’s 2025 Cybersecurity Workforce Study captured the visible part of the shift: AI is the top skills need (cited by 41% of respondents), with cloud security next (36%). Nearly all respondents (95%) reported at least one cybersecurity skills need, with 59% describing those needs as critical or significant. Even more recently, ISC2’s Aligning Skills, People and Hiring in Cybersecurity deep dive in April 2026 sharpened the point further, with 34% of respondents saying their organizations already have the right number of people.
It seems that the problem is not simply one of headcount, but whether existing teams have the skills, authority and governance models to supervise systems that now act on their behalf.
From Operators to Supervisors
Security operations have been built around a human operator model. An analyst checks an alert; an incident responder quarantines a host; an engineer revokes a credential. Even where workflows were automated, the accountability chain pointed to a person who reviewed evidence, applied judgment and made a decision.
This is changing with agentic AI, and academic research is starting to structure the evolving relationship. The AI cybersecurity researcher Víctor Mayoral Vilches points to a six-level taxonomy of automation versus autonomy in cybersecurity AI; most current autonomous systems sit at levels three or four, requiring human input for edge case reviews and strategic decision-making. In the AAAI Symposium Series, a group of authors suggest a new security operations center (SOC) function they call Agent Collaboration and Oversight, reflecting the growing need for human supervision and configuration of agent behavior.
Such research is catching up with what I see for myself in the field. The role of SOC analyst certainly isn’t being eliminated, but it is changing. The analysts who used to investigate an alert and decide whether to instigate containment? Now, they’re reviewing what an agent decided: whether the decision was in scope and whether the escalation path was correctly engaged. This is a quite different cognitive task, requiring different training, different decision-making authority and different tools.
The Agent Accountability Plane
Based on my own experience with AI governance reviews, the most difficult question is rarely about whether the agent delivered a useful output. More usually it’s about whether an organization can reconstruct who sponsored the agent, what authority the agent was granted, what the agent was supposed to do and where the human intervention was supposed to occur.
I think of this absent layer as the Agent Accountability Plane: the controls that connect an autonomous system’s identity, declared intent, authority, escalation threshold, audit trail and accountable human owner. In practical terms, this plane of accountability has to answer a few uncomfortable questions before the agent acts, not after something goes wrong. If an agent can act, a team should be able to reconstruct the chain of authority around that action:
- This starts with identity; the agent should not be hidden behind a generic service account or an inherited user session.
- Purpose matters too, because “the agent called the API” is not the same as understanding why the call was justified.
- Next comes authority. A read-only investigation agent should not quietly drift into modifying access policies, isolating hosts or changing production settings. Such limitations should be established and agreed upon prior to launching a workflow, not discussed in a post-incident review. The same applies to ownership. Every production agent must have a human sponsor who owns access reviews, exception management and retirement.
- The last test is reconstruction. In the event of a consequential action, the security team should understand the evidence used by the agent, which tool was invoked, what authority was used, whether there was an escalation path and what the result was. If such a record does not exist, the organization has automation, but it does not have accountable autonomy.
This problem is also being formalized in standards work:
- The Coalition for Secure AI (CoSAI), hosted under OASIS, is publishing guidance on agentic identity and access control as part of its Workstream 4 on secure design patterns for agentic systems.
- The Open Worldwide Application Security Project (OWASP) released a 2026 Top 10 for Agentic Applications, with several of its top risks centered on agent identity, authority and oversight.
The convergence is telling, with different communities arriving at the same architectural gap.
Where Traditional Supervision Breaks
Many organizations will respond with familiar controls: train analysts, add a human approval step, log tool calls and assign someone ownership somewhere in the workflow. My view is that those are all useful, but they are not enough by themselves.
Training is helpful – but only if the agent’s authority is already defined. I’ve participated in reviews at which the team could explain the purpose of the agent but struggled to explain the purpose of an associated credential, tool permission or API path. That is where supervision begins to fail; people cannot supervise authority that hasn’t been clearly defined.
The same challenge exists with sponsorship. A production agent should not continue to exist as an orphaned actor with credentials, integrations and workflow permissions that aren’t actively managed; someone needs to be responsible for ownership of its access, its exceptions and its retirement. If not, the agent just becomes yet another identity that exists for a long time for obscure business reasons.
Event logging has the same limitation. A log may show that a tool was invoked, but almost never explains why the agent considered the invocation appropriate. In their work on secure human oversight, This paper make a similar point: oversight can itself become an attack surface. So, for security teams, the decision trail is as valuable as the event trail.
The expression “human in the loop” is useful, but only up to a point: it doesn’t specify which actions need approval, who provides that approval, or even when the system must halt and when it may continue. A real oversight model has thresholds. Reading logs may not need approval – but revoking credentials, isolating hosts, deleting data or changing production policy should probably require approval.
Three Controls I Would Build First
The route ahead doesn’t require us to give up AI-driven security automation. It does mean building accountability into the workflows where autonomous decisions are made.
So, the first control I’d create is a consequence model for agent actions. Not all actions require the same level of supervision; for example, reading logs or summarizing telemetry data or making a recommendation is a lot less impactful than revoking a credential, isolating a host or changing a policy in production. Personally, I find it helpful to separate actions into four rough groups: observe, inform, modify and execute. The distinctions serve a purpose: the closer the action is to altering access, availability or data, the more rigorous the approval path should be.
The second control is ownership: each production agent must have a human sponsor. This is a privileged responsibility for the sponsor. The sponsor reviews access, approves privilege changes, handles exceptions and checks whether the agent is still needed. In deployments I’ve reviewed, sponsorship is most effective when there is a named primary sponsor, a backup sponsor and a recurring access review. If the sponsor leaves the role, the agent should be unable to continue operating on inherited authority.
Another type of control involves how decisions are recorded; for consequential actions, the basic logs will not suffice. A security team has to reconstruct the agent identity, human sponsor, task intent, data used, tool invoked, authority level, escalation path and outcome. The Journal of Computer Information Systems, described transparent accountability as one of the unresolved challenges in deploying agentic systems. A decision record is a practical way to make that accountability inspectable after the fact and visible during review.
Notably, these controls map to domains that CISSPs already know:
- Identity and Access Management covers agent identity and sponsorship
- Security Operations covers escalation, monitoring and response
- Security Architecture and Engineering covers the design of safe execution boundaries
- Security and Risk Management covers authority, ownership and acceptable risk
- Software Development Security covers the secure integration of AI agents into production workflows.
Therefore, I don’t think that this all requires a wholly new discipline. It is simply a matter of taking core principles of cybersecurity and applying them to a new actor. This same point is made, albeit in other words, in the 2026 ISC2 Exam Guidance for Artificial Intelligence: AI security concepts are already mapped across more than 50 core cybersecurity exam domains in ISC2’s certification portfolio. The profession is already building the needed experience; the challenge is to direct it purposefully.
The Work We Own
AI won’t eliminate the need for cybersecurity professionals, but it does place higher demands on what these professionals need to know. The focus of our work is changing, from operational tasks to supervised delegation. It’s changing from reviewing each action to governing which actions can take place unreviewed.
So, yes, the agent may execute the workflow. But the organization still owns the decision.
Nik Kale, CISSP, has nearly two decades of experience in enterprise software, AI platforms, cloud security, identity and access management. He has held principal engineering roles, with responsibility for designing AI security and enterprise systems at scale. His cybersecurity work spans the Coalition for Secure AI through OASIS, the IETF OAuth working group, ACM CCS 2026 and IEEE S&P SAGAI program committees.
