Unlike traditional security automation, which follows predefined rules and playbooks, AI agents interpret evidence, select tools, and determine next steps. This approach often requires access to identities, configurations and sensitive systems. While such flexibility can accelerate defensive operations, it also increases the potential consequences of compromised credentials, manipulated information or poor judgement.
Those risks become particularly apparent when considering where authority is granted. An autonomous security agent might quarantine an employee’s computer to contain a threat, but granting similar authority over production infrastructure carries far greater risks because an incorrect decision could disrupt customer services or affect sensitive data. Both actions may serve a legitimate security purpose, but the risks differ considerably.
For security leaders, the challenge is deciding what an agent can change, how far its actions could spread, and when human intervention becomes necessary. These decisions grow more complicated as specialised agents operate across interconnected environments, where they may reach conflicting conclusions or attempt incompatible actions.
In this interview, Robert Huber, Chief Security Officer, Head of Research and President of Tenable Public Sector, discusses how business impact should shape the boundaries of autonomous cyber defence, drawing on the decisions and considerations involved in overseeing Tenable’s own security programme.
Autonomous agents introduce a different level of authority
Security teams have automated responses for years through rules and predefined playbooks. What materially changes when a system can interpret what it sees, choose its next action and continue acting without each step being predetermined? At what point should an organisation stop treating it as automation and start treating it as a privileged actor within the environment?
Robert Huber: A predefined playbook provides a relatively inspectable sequence, while an agent can interpret evidence, select tools, and adapt its next action. That creates more possible paths through the environment, including paths the operator does not anticipate. Our recent tests on Anthropic’s Claude Mythos Preview highlight the distinction between repeatable, deterministic tools and probabilistic AI systems whose findings can vary across runs.
The change to treating the system as a privileged actor should start as soon as it can independently exercise consequential access, including retrieving sensitive information, altering permissions, changing configurations, or initiating remediation.
The issue with such automation is that organisations tend to trust AI much more than they should, leading to minimal human oversight and excessive privileges being given. That widens the blast radius of an AI cybersecurity incident to everything the agent’s keys can unlock. If those keys are stolen or misused, all of that access is potentially at risk.
Broader access can increase the consequences of compromise
A capable security agent may need visibility across identities, vulnerabilities, cloud environments, endpoints and business systems, as well as permission to act on some of them. At what point does giving an agent enough context and access to be useful create a concentration of privilege in its own right? How should organisations limit that exposure without restricting the agent so heavily that it loses much of its value?
Robert Huber: The challenge arises when an agent is given elevated privileges, such as access to sensitive internal systems like enterprise resource planning and customer resource management tools, when its initial role was, for example, technical support resolution. A compromised endpoint could become a route for threat actors to breach sensitive data, leading to an AI cybersecurity incident.
Organisations can reduce this exposure by first mapping the tools, systems and data stores each agent can access, then assessing data sensitivity and assigning permissions according to its intended purpose. Where necessary, data stores should be separated, while write and update capabilities should be restricted to essential tasks or specific fields. These measures should be supported by ongoing monitoring of the prompts that trigger agent actions, particularly attempts to change behaviour or access, as well as activity that could indicate data leakage or deviations from intended business logic.
However, securing AI agents cannot be treated as a standalone exercise. A unified strategy means assessing agents alongside the identities, applications, cloud environments, and vulnerabilities they interact with, rather than managing each exposure in isolation. This lets security teams understand how excessive permissions, misconfigurations, and vulnerabilities can combine to create exploitable attack paths.
By continuously reviewing these interconnected risks, firms can focus on remediating what matters most rather than treating each exposure independently.
Confidence alone cannot determine autonomous action
Security decisions are often made with incomplete or conflicting information. When an agent cannot determine with high confidence whether an activity is malicious, what should govern whether it observes, gathers more information, contains the activity, reverses a change or escalates to a person? How should that threshold change based on the system’s criticality and whether the action can be easily undone?
Robert Huber: Both the strength of the evidence as well as the consequences of the proposed action should be considered instead of simply defaulting to the agent’s own confidence score. Firms should also assess whether independent signals support the agent’s conclusion, whether the information it relies on is up to date, and what the consequences would be if the decision to act, or not act, proves to be wrong.
Usually, when evidence is weak or conflicting, the next step should be to gather more information for human intervention and judgement. However, if active harm is evident during the process, containment before investigations are completed would be justified.
These thresholds should be predefined before an incident and stress-tested against realistic scenarios. When an escalation occurs, it should include evidence, proposed action, and likely impact along with the timeline needed for a decision to be made. If no human responds or intervenes, the agent should have a previously defined fallback, within bounded authority, to carry out.
Autonomous defenders also require protection
An autonomous security agent can itself become part of the attack surface. An attacker may not need to compromise the underlying model if they can manipulate the data, context, credentials or tools the agent relies on. When an agent takes an incorrect action, how can a security team establish whether the failure came from the agent’s judgement or from information and access that were deliberately manipulated? What visibility and controls are needed around the agent itself?
Robert Huber: Organisations must first establish clear ownership and accountability for the autonomous security agent. For visibility and controls around the agent, the strongest controls are those the agent cannot override. Organisations should also ensure that the agent’s actions can be traced and distinguished from human actions. This information is required for organisations to determine whether the failure was due to an agent’s judgement or malicious manipulation.
Implementing cyber controls and governance is paramount to ensure agents communicate with trusted resources. These include zero-trust protocols, input and output guardrails, unique identities, least privilege, gateways for MCP and API access, and human-in-the-loop checkpoints.
Blast radius determines where human intervention remains
From your experience overseeing Tenable’s own security programme, what is one type of security action you would be comfortable allowing automation or an agent to carry through from detection to remediation today, and one where you would still deliberately interrupt that chain? What is different about the risk in those two cases?
Robert Huber: At this point in time, it is based on the blast radius, or possible impact to the enterprise. The higher the potential blast radius or impact, the less likely we are to let agents act autonomously. A simple example is a single user desktop. The overall enterprise impact of this one device is minimal, so we are more inclined to let the agent take necessary actions to restrict, quarantine, or mitigate risk. Contrast that with our production SaaS infrastructure, where the potential impact could extend to customer availability or data loss.
Conflicting agents require explicit decision authority
As organisations introduce specialised agents across vulnerability management, identity, cloud, endpoint security, and other areas, those systems may eventually overlap in permissions or reach different conclusions about the same incident. When autonomous systems disagree or attempt conflicting actions, what should determine which one takes precedence, and where should final authority sit? Does that require organisations to establish a hierarchy of authority for machines in the same way they define privileges and escalation paths for people?
Robert Huber: Organisations need explicit authority and escalation rules based on potential business risk and incident responsibilities for agents. An AI model’s apparent confidence, or the order in which agents submit requests, must not determine which action takes precedence.
For each consequential action, there should be a clear policy owner and an enforcement point that checks permissions, dependencies and the current incident state. Agents can share evidence and recommendations, but they should not be allowed to grant one another additional authority or disregard other restrictions.
For example, what should happen if an identity agent recommends that an account be disabled, but another system says the team needs it? If the account is confirmed to be compromised, the active session can be shut down immediately while the incident lead sets up another way for the team to get in. If the activity is only suspicious, or the account is a protected emergency account, the bar for disabling it should be higher. If the evidence remains conflicting and the stakes are high, a person should make the call within a set timeframe.
Organisations must also stop agents from working against each other, such as one repeatedly undoing another’s fix or acting on outdated information. These scenarios should be tested before a real incident, rather than discovered during one.
Final authority should rest with a person: the designated incident commander, working with the owners of the affected systems. Agents can speed up the response, but people must remain accountable for consequential decisions. This is why I believe the need for experienced cyber practitioners with sound judgement will only grow.
Delegated authority needs boundaries that survive failure
An autonomous security agent’s authority should depend on the potential consequences of its actions. Huber’s distinction between quarantining an individual workstation and intervening in production infrastructure illustrates why business impact must shape those decisions. An agent’s confidence alone is insufficient, particularly when evidence is incomplete or an incorrect action could disrupt critical operations.
Maintaining those boundaries becomes more complicated as specialised agents operate across interconnected systems. Organisations need enforceable permissions, clear escalation rules and controls that individual agents cannot override. They must also account for manipulated information, conflicting decisions and situations where immediate containment is necessary but human intervention is unavailable.
Security teams need the ability to trace an agent’s actions, restrict its authority and intervene when necessary. Those controls must remain effective when information is incomplete, autonomous systems reach conflicting decisions, or an incorrect action threatens to disrupt critical operations.
