AI agents change the security conversation because they do something ordinary generative AI generally does not: they act.
A chatbot can give someone a bad answer and leave the human to decide what happens next. An agent can receive a goal, choose tools, call APIs, write data, trigger workflows, maintain state and continue working through multiple steps before a person sees the result.
That difference sounds technical until the agent has credentials.
At that point, the CISO is no longer evaluating only whether an AI system produces reliable information. The organization is deciding what authority software should be allowed to exercise, which human remains accountable for that authority, where intervention should occur and what happens when the agent encounters conditions nobody anticipated during design.
Microsoft's current AI agent shared-responsibility guidance describes this shift directly. Agents create new security responsibilities around orchestration, tools, permissions, memory, identity and autonomous action, while organizations continue to retain responsibility for data, access, authorization, human oversight and accountability. Microsoft's AI Agent Shared Responsibility Model is a useful starting point because it treats autonomy as a change in the operating model rather than merely another feature of an LLM.
For CISOs, that means the most useful pre-deployment questions are not just about the model.
They are about the system of authority around the agent.
This should be one of the first questions because “agent” can describe very different things.
One agent may search internal documents and draft a recommendation. Another may update customer records, send external communications, execute code or change production infrastructure.
Those systems should not inherit the same security assumptions simply because they use similar underlying AI.
The useful inventory is therefore not merely a list of agents. CISOs need to understand the actions available to each agent, the tools it can call, the systems those tools reach and the consequences those actions can create.
Microsoft's current guidance makes this distinction explicit by separating the tools and actions layer from the underlying AI model. It recommends least privilege for each tool, authorization on individual actions and stronger human controls around sensitive or difficult-to-reverse activities such as payments, production changes, deletes and external communications.
That is a useful mental model.
The risk of an agent is shaped at least as much by what it can do as by what it can say.
This question gets complicated quickly.
An agent may act using its own identity. It may operate using delegated permissions from the person who invoked it. In some environments, those patterns can change depending on the task.
Microsoft now distinguishes between agents acting as themselves and agents acting on behalf of users because the identity relationship determines which permissions and access rules apply. Microsoft's guidance on agent authority shows how the actor and the human subject of the access can remain distinct even when an agent is using delegated permissions.
For a CISO, the practical concern is whether that relationship is understandable and enforceable.
If the agent uses a broad standing identity, could it perform actions the requesting employee would never have been allowed to perform directly? If it operates on behalf of a person, are permissions constrained to what that person can legitimately delegate? Can security teams determine which human, agent and credential were involved in a consequential action later?
The familiar principle of least privilege still applies.
The challenge is that agents create another actor through which privilege can be exercised.
Organizations can spend considerable time discussing whether an AI system is “agentic” while avoiding the more useful question of how much independent authority it has received.
Can the agent choose which tools to use? Can it decide the order of operations? Can it initiate actions without approval? Can it delegate tasks to another agent? Can it continue working after the original user has moved on to something else?
Each additional degree of autonomy changes the supervisory problem.
Microsoft's shared-responsibility guidance describes agents as systems that can plan and loop through intermediate steps, use tools and APIs, hold state and interact with other agents. It recommends controls such as step limits, iteration limits, cost ceilings and restrictions on which tools can be chained.
These may look like technical implementation details, but they reflect a broader risk decision.
Before deployment, the organization should be able to explain what the agent may decide independently and which decisions remain outside its mandate.
If that boundary cannot be described clearly, it will be rather difficult to supervise later.
Happy-path workflows are generally quite impressive in demonstrations.
The more revealing question is what happens when the situation stops looking like the demonstration.
The agent encounters contradictory instructions. It needs access it was not originally given. The customer case does not fit the expected pattern. A downstream system responds differently from normal. The agent discovers another possible route to accomplishing its goal.
Does it improvise?
Does it stop?
Does it escalate?
NIST's October 2026 work on agent identity management proposes mandates and constraints as part of the answer. The originator of an agent task should be able to define intended outcomes and boundaries for the agent's activity, while risk thresholds can trigger human review when the system reaches conditions that should not be resolved autonomously. NIST's Design Tenets for Agent Identity Management Systems makes that transition between autonomous activity and human authority particularly explicit.
Cybermaniacs approaches the same problem through Human-Agent Accountability and intervention points.
The agent needs a mandate.
The organization also needs to know what happens when the mandate runs out.
The useful answer is unlikely to be “all of them.”
If every tool call requires a person, the agent will spend much of its life waiting for permission and the organization will have recreated a manual workflow with more interesting infrastructure.
If no actions require human intervention, the organization is assuming that technical constraints and autonomous decision-making are sufficient across every condition the agent may encounter.
The sensible middle depends on consequence.
Microsoft recommends human-in-the-loop gates for high-impact, irreversible and sensitive actions. NIST similarly recommends defining organizational risk thresholds that trigger human review and explicitly warns about consent fatigue when escalation occurs so frequently that people begin approving actions habitually.
This is why Cybermaniacs treats intervention as a design problem rather than a checkbox.
Our Guide to What Should Trigger Human Intervention in AI Systems? looks at conditions such as rising consequence, changing authority, uncertainty, irreversibility and mandate drift.
The CISO should be able to ask a very practical question before deployment:
What can this agent do without a person, and what specifically causes that autonomy to end?
Naming an agent owner is useful.
It is not the same thing as building accountability.
The owner may approve deployment while a process manager supervises the work, an infrastructure team manages identity, a business user provides the goal and a different person receives an escalation when something goes wrong.
That is a perfectly plausible operating model, but somebody needs to understand how those responsibilities connect.
Microsoft's shared-responsibility model states that organizations continue to retain responsibility for human oversight and for determining who is accountable for autonomous agent behavior. Its guidance also highlights acceptable-use policy and accountability for agent actions as responsibilities that remain with the deploying organization regardless of the technology model.
At Cybermaniacs, we use Human-Agent Accountability for the wider system of human ownership, delegated authority, supervision, intervention and evidence that keeps agent activity connected to meaningful human responsibility.
The important pre-deployment question is not simply “Who owns the agent?”
It is whether that person—or the surrounding accountability chain—has the visibility and authority necessary to own the outcome in practice.
This is where workforce design starts colliding with security architecture.
A manager may formally remain accountable for an agent but have almost no idea what it does between receiving the task and presenting the result. Another supervisor may have excellent observability but be responsible for enough agents that meaningful review becomes impossible.
Neither problem is fixed by adding the person's name to a governance register.
Cybermaniacs uses supervision sufficiency to examine whether the amount and quality of human supervision remain appropriate for the autonomy, complexity and consequence of agent activity. Our Guide to Supervision Sufficiency goes deeper into the concept.
Before deployment, CISOs should ask what the supervisor will actually see, which conditions require their attention and how much activity the role can reasonably handle.
A human control can be technically present and operationally useless.
That is particularly likely when agent throughput scales faster than human attention.
Prompt injection becomes much more consequential when an AI system can act.
An ordinary model may read malicious instructions embedded in an email or webpage and produce a compromised answer. An agent with tools and permissions may allow the same manipulation to influence which actions it takes.
Microsoft explicitly warns that untrusted content from retrieved documents, tool outputs and other agents can enter the agent's reasoning loop and should not be treated as trusted instruction. Its current guidance recommends separating instructions from data, reapplying safety controls at agent boundaries and placing stronger gates around consequential actions.
OWASP's recent agentic AI work has similarly emphasized risks such as goal hijacking, tool misuse, identity and privilege abuse, memory poisoning and unexpected code execution.
For CISOs, the architectural question is important:
If the agent consumes untrusted information, what prevents that information from quietly becoming authority?
The answer cannot rely entirely on the model recognizing malicious intent correctly every time.
Permissions, action authorization, tool restrictions and intervention controls need to limit what a compromised reasoning process can actually accomplish.
Persistent memory is useful because agents can maintain context across tasks and sessions.
It also creates another place where risk can survive.
Microsoft's shared-responsibility guidance identifies memory poisoning as a specific agent risk: malicious or incorrect information can persist and influence future behavior. It recommends isolating memory by user and tenant, validating persistent information, tracking provenance and applying ordinary data controls such as retention and access management.
The security implications stretch beyond prompt injection.
What personal or confidential information can the agent retain? How long does it remain? Can one user influence information later used for another? Is memory included in deletion and retention obligations? Can security teams determine where a consequential belief or instruction entered the agent's context?
These questions can feel less exciting than an agent demonstration.
They become more interesting the first time a supposedly resolved issue survives for another three weeks inside persistent memory.
Multi-agent systems create another trust boundary.
One agent may plan the work while others perform specialized tasks. An orchestrator may delegate work to agents with different identities and permissions. The output of one agent can become the instruction or context for another.
That means a problem can propagate.
Microsoft recommends treating each inter-agent message as a new trust boundary rather than assuming that information produced inside the agent system is automatically trustworthy.
This also complicates accountability.
The user may interact with one visible agent while consequential activity occurs several layers away. Security teams still need to be able to determine which agents participated, which identity each used and where authority changed hands.
Our Human-Agent Accountability Guide describes this as the need to preserve a human accountability anchor even when activity moves through an agent chain.
More agents should not mean less clarity about who ultimately owns the objective.
A stop mechanism sounds almost embarrassingly basic until an autonomous system is moving through multiple connected tools.
Can the organization halt the current task? Can it revoke the agent's access? Does stopping the orchestration also stop credentials and network activity? Can security responders intervene without waiting for the business owner who created the workflow?
Recent agent-security incidents have made these questions more concrete. OWASP's 2026 agentic exploit roundup describes incidents where agents exceeded intended boundaries, used available infrastructure in unexpected ways and expanded access through credentials and connected systems. The operational lesson is familiar from incident response: containment needs to affect the actual mechanisms through which activity continues.
Cybermaniacs' Human Override Guide treats this as more than a button. Effective override requires an authorized human to be able to stop, reject, redirect, constrain or take control while doing so can still affect the outcome.
CISOs should test that capability before deployment rather than assuming the platform's “disable” control means what everyone hopes it means.
An agent saying “done” is not audit evidence.
Security and risk teams need enough traceability to understand what happened: which tools were invoked, which identity was used, which resources were affected, which inputs influenced the action and whether human approval or escalation occurred.
Microsoft recommends action-level audit logging for agent tool use, including inputs, outputs, identities and relevant decision information.
The amount of information required will vary by risk. Nobody wants to build an archaeology department for harmless internal agents.
For consequential systems, however, accountability becomes difficult without usable evidence.
Our Guide to How Should Employees Verify AI-Generated Work? makes a related distinction between reviewing an AI system's claim and independently establishing whether the intended outcome actually occurred.
With agents, that distinction becomes even more important.
The organization needs evidence about actions, not merely confidence in the agent's summary of them.
This question can disappear beneath identity, permissions and architecture because those issues are easier to specify technically.
But agent deployment changes human work.
Employees may move from performing tasks to supervising outcomes. Managers may become accountable for work they no longer directly observe. Teams may need to recognize escalation conditions, verify agent activity and intervene when authority needs to return to a person.
Those are new responsibilities, not simply new software features.
Cybermaniacs' Agentic Readiness & Change (ARC) work focuses on this layer: changing roles, workflows, supervision, accountability and workforce capability as agents enter the operating environment.
Our broader AI Enablement & Change (AIECM) work addresses workforce readiness, confidence, behavior and adoption, while Human Risk Assessment & Assurance helps organizations understand whether the people relied upon within AI controls possess the competency, judgment and organizational support required.
This is where security and change management become difficult to separate.
The safest technical agent can still sit inside a badly designed human system.
There will be different requirements for different agents, but a CISO should be able to get clear answers to a fairly consistent set of questions.
The organization should understand what the agent can do, which identity and permissions it uses, what authority has been delegated and which actions require human involvement. It should know what happens when the agent leaves its intended mandate, how untrusted information is handled, what memory persists and whether other agents introduce additional trust boundaries.
Someone should remain meaningfully accountable.
That person should have enough visibility and authority to perform the role. Security teams should be able to stop the agent when necessary and reconstruct consequential activity afterward.
The workforce around the agent should also understand the new job it has been given.
This does not mean applying the same heavyweight governance process to every agent. An internal assistant with narrowly scoped read access creates a very different environment from an autonomous system able to make production changes.
The controls should scale with the authority.
The CISO has an essential role in agent deployment because agents create new identity, authorization, data, execution and monitoring risks.
But secure deployment requires more than a technically secure agent.
It requires a clear relationship among the agent's authority, the human who remains accountable for it and the controls that determine when autonomous activity can continue.
Cybermaniacs uses Human-Agent Accountability to make that relationship explicit. Human-AI Risk Intelligence provides the wider evidence layer for understanding whether capability, behavior, psychology, culture, authority and working conditions support the controls the organization believes it has.
That is why the pre-deployment conversation should not end with “Is this agent secure?”
The better question is whether the organization is ready to let this agent, with these permissions, exercise this amount of authority inside this workflow—and whether the humans around it are prepared for what happens next.