As artificial intelligence agents gain access to security data, developer tools and recovery workflows, enterprises need controls designed for actors that can chain actions together at machine speed rather than simply follow a fixed user interface.
In this TNGlobal Q&A, Ananth Nag, General Manager and Vice President, Asia Pacific at Rubrik, discusses identity and permission boundaries for agents, Model Context Protocol risks, validation of AI-generated security findings, human approval and recovery from harmful automated actions.
MCP can give AI agents access to security data and operational capabilities that previously required direct human interaction. What are the most important permission boundaries enterprises should put in place before allowing agents to initiate security or recovery actions?
The first boundary organizations should put in place is identity. Every agent action should be attributable to a specific human user and agent, with higher-risk actions requiring explicit approval. Traditional credentials, such as static API keys, were not designed for autonomous actors operating at machine speed. Organizations therefore need strong identity controls that make it clear who or what is acting, on whose behalf, and what permissions have been granted.
The second boundary is scope of action. Permissions should be granted according to specific tools and tasks, rather than giving agents broad access. For example, an agent diagnosing a failed backup may need permission to read relevant data, but it should not automatically be able to change retention policies or initiate a recovery. Access to sensitive data and high-impact actions should be narrowly scoped, with human approval required where appropriate. Every action should also be logged so teams can see what the agent accessed, proposed and executed.
Existing role-based access controls were largely designed around human users and conventional applications. Where do those controls need to evolve when an autonomous agent can chain several permitted actions together in ways an administrator may not have anticipated?
Role-based access controls need to evolve from asking “Can this human access this application?” to “Should this agent be allowed to perform this specific action right now?”
The distinction matters because individually valid permissions can create an unintended outcome when an agent combines them. For example, when we expanded our use of Claude Code in internal test environments, we discovered a class of security issues that did not map cleanly to our existing controls. We asked an AI agent to generate and share an internal report. When the AI agent could not share the report through the intended method, it found a workaround and uploaded it to a public GitHub gist instead, unintentionally exposing internal data. No sensitive customer data was shared and we resolved it by creating a simple policy boundary in Rubrik Agent Cloud stating that data from the agent environment should not be transferred to public-facing platforms such as code repositories. However, it highlighted how powerful and intelligent agents are, and that they will choose any available workaround to complete a task.
Static roles should remain part of the foundation, but autonomous agents require additional controls around what actions they can perform, under what circumstances, and how combinations of otherwise permitted actions are governed.
Code Guardian analyzes an isolated copy of source code rather than the live repository. What risks does that isolation address, and which risks still remain around model behavior, sensitive code, generated findings and the remediation process?
Isolation prevents AI security testing from directly affecting the live repository or production environment, but it does not remove the need to validate what the model finds or carefully control remediation.
The isolated copy creates an important boundary as Rubrik Code Guardian probes for attack paths without touching live production systems. Isolation reduces the risk of the analysis disrupting a build or affecting running services.
However, isolation does not mean every finding is actionable. As the model may generate many potential findings, exploitability must be validated and issues prioritized before they reach engineers. Source code and detailed attack paths are sensitive, so organizations must control who can access the analysis and the results.
AI-based security analysis may identify complex attack chains that conventional scanners miss, but it can also produce incorrect conclusions. How should security teams independently validate AI-generated findings before allowing them to trigger remediation or operational changes?
Security teams should treat an AI-generated finding as a hypothesis to verify, not an instruction to act. Teams should reproduce the issue in an isolated environment, validate the underlying weaknesses against source code, configuration or other security telemetry, and confirm that the claimed attack path is genuinely exploitable. Only once the finding has been independently verified and its potential consequences understood should it trigger remediation or operational change.
MCP is becoming a common interface for connecting AI agents to enterprise tools. From a defender’s perspective, what new attack surfaces does MCP introduce, particularly around tool permissions, prompt injection, identity and compromised agents?
MCP turns LLMs from passive text generators into active, state-changing agents integrated directly into enterprise infrastructure. The main attack surfaces MCP introduces are over-permissioned tools and gaps in identity protection. A lag in those controls could enable rogue commits, repository ransomware or rapid IP exfiltration.
The risk is amplified by how agents behave. Agents are ruthlessly goal-oriented. If one route is blocked, an agent may find another available path to complete the task, even if that path sits outside the organization’s intended controls. We experienced this when a coding agent could not find the approved MCP server and instead attempted to use an unrestricted command line.
As models become better at reasoning across entire codebases, defenders also need to understand how individual weaknesses combine into exploitable attack paths and prioritize the risks that genuinely require action.
As organizations allow agents to participate in incident response, which actions do you believe should remain explicitly human-approved, even if the underlying agent has sufficient technical permissions to perform them?
Actions that modify production state or carry significant consequences should remain explicitly human-approved, even when the agent has the technical permission to execute them.
An agent can accelerate investigation, gather information and recommend the next step, but permission to access a system should not automatically translate into permission to change it. The higher the potential blast radius or the harder an action is to reverse, the stronger that human checkpoint should be.
We applied this principle when building Rubrik AI. Every action Rubrik AI executes goes through explicit human approval, with a clear preview showing what will change after it takes action. The objective is not to remove automation, but to place human judgment at the point where autonomous reasoning becomes consequential action.
Cyber resilience increasingly includes the ability to reverse an AI agent’s actions or restore a known-good state. How should organizations design recovery and auditability when agent activity may involve dozens of automated steps across multiple systems?
Organizations should focus on three things:
First, ensure visibility. Maintain an end-to-end audit trail that shows which agent acted, what initiated the session, which systems it touched and the sequence of changes it made. Visibility helps teams understand the blast radius and determine exactly what needs to be reversed.
Second, know what can be safely recovered. Organizations need to identify a clean state and maintain immutable backups that attackers or compromised agents cannot alter. Having a backup is not enough; organizations need confidence that it is clean, protected and recoverable within their required Recovery Time Objectives (RTOs).
Third, regularly test recovery plans before an incident occurs. Rubrik found that only 30 percent of organizations have tested capabilities to contain, reverse and recover from harmful agent actions. As such, teams need to understand where their clean recovery points are, define RTOs for critical systems and ensure they can orchestrate recovery before an incident hits.
Over the next 12 to 18 months, what evidence should enterprises look for before treating agentic cyber-resilience tools as production-ready rather than experimental? Are there particular metrics, testing methods or failure scenarios you think buyers should insist on seeing?
Organizations should look for evidence that agentic systems can operate safely when things do not go as planned, not just when they perform as expected. Such evidence includes tested guardrails, clear visibility into agent actions, and more critically, the ability to reverse harmful or unintended actions.
Testing should cover the full workflow and include realistic failure scenarios, such as an agent taking an unintended action or triggering a chain of unwanted changes. Organizations should test whether those actions can be detected quickly, contained and rolled back, with systems and data restored to a safe and known recovery point.
Ultimately, production readiness should be demonstrated through recoverability. Before deploying agentic systems at scale, organizations should be confident that if an agent makes a mistake, such changes can be identified, contained and reversed before they cause lasting impact.
Ananth Nag is General Manager and Vice President, Asia Pacific at Rubrik.
Editor’s note: This Q&A has been lightly edited for clarity and TNGlobal house style. The substance of the interviewee’s responses has been preserved.
Share your perspective: TNGlobal welcomes contributed insights and expert commentary from across Asia’s technology and innovation ecosystem. Submit a contribution for editorial consideration, or explore more conversations in our TNGlobal INSIDER and TNGlobal Q&A and Interviews archive.