India’s cyber resilience push must confront the internal AI agent attack surface

By Abhishek G Sharma

The uncomfortable part of agentic AI is not the model. It is the permission set around the model.
Express Computer’s April 2026 conversation on cyber resilience for India’s AI era made a useful point through Sandeep Agarwal, CTO, Security, Cisco India and South Asia: with agentic AI, the concern shifts from what systems say to what they do. That line matters because many enterprise security plans still treat AI as a content, model, or data leakage problem. Agents turn it into an action problem.

In my experience, this is where the risk often gets misread. Teams spend time arguing about model choice, prompt policy, and productivity gains, while the agent quietly receives access to ticketing queues, customer records, cloud consoles, code repositories, financial workflows, or software delivery tools.
The dangerous part is not that the agent is malicious. The dangerous part is that it may be legitimate.

The perimeter has moved inside
Traditional cyber resilience assumes a hostile actor tries to enter, move laterally, steal, encrypt, or disrupt. That attack vector still matters. Phishing, ransomware, fraud, cloud misconfiguration, identity compromise, and third-party exposure have not disappeared.

But an AI agent can sit on the other side of the perimeter.

It may authenticate properly. It may call approved application programming interfaces. It may use a service account created by the engineering team. It may act inside a sanctioned workflow, with valid credentials, using a tool the business approved.

That changes the question.

Security teams can no longer stop at asking, “Was access unauthorised?” They also need to ask, “Was the action appropriate for that agent, in that context, at that moment, with that level of evidence retained?”

Excessive agency is now an operating risk
The Open Worldwide Application Security Project’s 2025 Top 10 for Large Language Model Applications lists “Excessive Agency” as LLM06. The issue is not abstract. A large language model-based system may be allowed to call functions, invoke tools, interface with downstream systems, and take actions in response to prompts or outputs.

In operational language, this means the system can do more than answer a question. It can act.
That is the line many enterprise deployments have already crossed. A customer support agent that can update records is no longer just a chatbot. A development agent that can open pull requests, change configuration, or call deployment tools is no longer just an assistant. A finance workflow agent that can apply a rule, approve an exception, or trigger a notification is part of the control environment.
Bluntly: a prompt policy will not contain a tool with write access.

If an agent can act, the control question becomes specific. What can it touch? Who approved that scope? Which identity does it use? What evidence is retained? Who reviews exceptions? How is the action reversed? What happens when the agent follows its instruction correctly, but the business context is wrong?

The control stack has to become agent-specific
A generic AI policy is too thin for this problem. A secure agent deployment needs an operating control stack, not just a paragraph in an acceptable-use document.

The minimum stack starts with an agent inventory. Each agent should have a business owner, a technical owner, a purpose statement, connected tools, data access scope, execution permissions, and a review cadence. If the organisation cannot list its agents, it cannot govern delegated action.
Identity comes next. Agents should not share human credentials. They should not borrow broad service accounts built for older automation. Each production agent needs a distinct identity, scoped permissions, rotation rules, and a clear deactivation path.

Access then needs to be narrow. Express Computer’s earlier discussion correctly referenced just-enough and just-in-time access for agents. That principle should become default practice: no standing access where temporary access will do, no write access where read access is enough, and no production access without a separate approval gate.

The boring controls matter most.

Activity logging should capture more than the final output. It should show the instruction received, the tool invoked, the data touched, the authorisation decision, the human approval point if any, the telemetry identifier, and the final system change. If the log only says “agent completed task,” it is not an audit trail. It is a receipt.

Cyber resilience needs rollback, not just monitoring
The National Institute of Standards and Technology’s Artificial Intelligence Risk Management Framework 1.0 groups AI risk work around govern, map, measure, and manage. Its AI Risk Management Framework Playbook also points to post-deployment monitoring, appeal and override, decommissioning, incident response, recovery, and change management.
That language is relevant because agentic AI creates live operational risk, not only design-stage model risk.

Here is the practical gap I keep seeing: teams design monitoring, but not reversal.

For agents, resilience must include rollback paths. If a workflow agent changes a record, can the organisation reverse the change quickly? If it triggers a customer notification, can that notification be paused? If it writes to a production system, can the affected transaction set be isolated? If it deletes or overwrites data, does the backup design protect against that exact action path?

I do not have a clean answer yet for how far Indian enterprises will go in separating agent controls from existing automation controls. The data is still thin. But the direction is clear: treating agents as ordinary bots will understate the risk.

The internal threat does not always look hostile
There is a tempting counterargument: if the agent is inside a trusted platform, monitored by security tools, and using approved credentials, the risk is already covered. That view is incomplete.

Existing controls may detect malware, abnormal login, data exfiltration, or suspicious network traffic. They may not detect a well-authenticated agent taking an allowed action in the wrong business context. A sales operations agent that updates the wrong customer tier may not look like an attack. A finance agent that applies the wrong rule may not trigger an intrusion alert. A development agent that changes configuration may look like normal automation.

This is why agent behaviour needs its own review logic. Not every bad outcome is a breach. Some will be valid actions that lacked business judgment.

What CIOs and CISOs should ask before deployment
Before putting an agent into a live workflow, chief information officers and chief information security officers should force six questions into the deployment review:

What exact business action is this agent allowed to take?
Which systems, records, and application programming interfaces can it touch?
Where is human approval mandatory, especially for destructive, financial, customer-facing, or production actions?
What evidence is retained for each action, and who reviews exceptions?
How can the agent be paused, killed, or deactivated without breaking the wider workflow?
What is the rollback plan if the agent acts within access rights but outside business intent?

The next resilience test
The next cyber resilience test for Indian enterprises may not start with a hacker crossing the perimeter. It may start with an internal AI agent doing exactly what it was technically allowed to do.

The organisations that handle this well will not simply ask whether an AI agent is useful. They will ask whether it has a bounded identity, narrow access, observable behaviour, human approval for high-impact actions, and a recovery path when things go wrong.

Cyber resilience in the AI era will not be proven by how much automation an enterprise deploys. It will be proven by how well it can control, evidence, and reverse automated action.

That is the part that needs more boardroom attention now.

About the author
Abhishek G Sharma is Founder and CTO of EU AI Compass & Move78, a Hong Kong-based cybersecurity, EU AI ACT regulatory and AI risk management advisory firm. He has 20+ years of experience across cybersecurity, cloud risk, enterprise risk governance, ISO/IEC 42001, and EU AI Act readiness, with prior roles at JP Morgan, GE Aviation, and Tata Consultancy Services.