India's IT giants are giving AI agents their own security badges

01

WHAT ACTUALLY CHANGED

Financial Express reported the shift on September 20 through direct comments from security and technology leaders at Infosys, Mphasis, Persistent Systems and Google Cloud. The article places AI applications, APIs and agents inside the enterprise security perimeter rather than treating them as ordinary software already covered by a user login.

Infosys executive Umashankar Lakshmipathy said the company's cybersecurity approach is anchored in security for AI and Zero Trust. He also described work with CrowdStrike, Palo Alto Networks, Zscaler and Microsoft and pointed to employee training through Infosys LEX and cyber labs. The public report does not provide an architecture, deployment count, test result or outside assessment of those controls.

Mphasis executive Ravi Vasantraj said the company combines Zero Trust with continuous threat monitoring, proactive threat hunting and AI-assisted detection while strengthening governance, access controls and data protection. The statement describes a control direction. It does not show which agents are covered, how permissions are issued or whether a red-team exercise has demonstrated that the controls stop a realistic attack.

Persistent Systems chief information officer Debashis Singh said many AI-related data leaks begin with ordinary behavior, such as an engineer pasting source code into a free chatbot or a team sending customer contracts to an unvetted summarizer. He said Persistent classifies personally identifiable information, source code, financial data and intellectual property and specifies what AI systems may process.

Persistent also said it uses identity- and role-based controls and AI-specific red teaming for prompt injection, data leakage, model manipulation and unauthorized retrieval. Those details are more concrete than a generic safety promise, but the test cases, pass thresholds, findings, remediation record and coverage are not public.

Google Cloud security executive Daryl Pereira told the publication that prompts, training data and external model outputs can all create risk. He recommended a scanning layer between external models and internal systems and described API rate limits as one way to contain brute-force activity. He also argued that Zero Trust must expand from user IDs to AI agents.

The report connected the security shift with breaches disclosed by several Indian IT companies in August. It did not establish that AI caused those incidents. They are background evidence that identity, cloud and credential controls remain consequential, not proof that agents created the compromise.

NIST's Zero Trust Architecture supplies the older foundation. It rejects implicit trust based on network location or asset ownership and moves protection toward users, assets and resources. Applying that logic to agents is an extension of the resource and workload model, not a declaration that a new security product has solved the problem.

OWASP separately identifies prompt injection and excessive agency as risks for LLM systems. It recommends minimum tool functionality, minimum downstream permissions, user-context authorization, human approval for high-impact actions, complete mediation in downstream systems, monitoring and rate limits. Those controls describe what the badge metaphor must become in code.

02

WHY THIS MATTERS

An agent can act faster than a person and repeat the same mistake across many systems. A human who opens the wrong file may expose one document. An agent with broad search, mail and storage permissions can collect, transform and send thousands before anyone notices.

Identity answers which actor made a request. Authorization answers whether that actor may perform this exact action on this exact resource now. Enterprises need both. A beautifully labeled agent account with administrator access is still an administrator account.

The human owner and the agent should remain distinguishable. A worker may be allowed to approve a payment while the assistant is allowed only to prepare it. If the agent simply borrows the worker's full session, downstream systems cannot reliably enforce that difference.

Prompt injection turns outside content into a possible instruction channel. A malicious line in an email, document or web page can try to redirect the agent. Input scanning may catch some attempts, but permissions must assume the filter will occasionally miss one.

Shared service accounts make investigation harder. If ten agents use one credential, a log may show that the account changed a record without showing which model, task, user request or tool path produced the action. Separate workload identities make containment and reconstruction possible.

A policy written for employees may not fit machine speed. An agent can make hundreds of API calls, recurse through linked records and retry after failure. Rate limits, budgets, time bounds and circuit breakers are authorization controls for tempo as much as for access.

Human approval is valuable only when it is informed. A button asking approve or reject is weak if the reviewer cannot see the intended action, affected records, source evidence, cost, reversibility and permission being used. The approval screen must expose the consequence, not merely the agent's confident summary.

Zero Trust does not mean distrusting every employee or model as a moral judgment. It means the system does not grant continuing access merely because something is inside the company network or passed an earlier check. Each resource enforces policy using current identity and context.

India matters beyond one national market because its IT services firms design, operate and secure systems for customers around the world. Their agent controls can become templates embedded in global outsourcing contracts, managed services and cloud transformations.

The difference between policy and evidence remains large. Named programs, partner lists and executive interviews show attention. They do not reveal coverage, failure rates, bypasses, exceptions or whether customers receive the same protections. Security claims become credible when tests and incidents produce reviewable records.

03

WHERE IT COULD HELP

• Give every production agent and tool connector a unique workload identity instead of a shared administrator or developer credential
• Bind each identity to a named human owner, business purpose, model version, approved tools, permitted data, spending limit and expiration date
• Use short-lived credentials and narrowly scoped tokens so a stolen secret cannot become a permanent skeleton key
• Authorize every downstream request at the resource boundary and never rely on the model to decide whether its own action is allowed
• Separate read, draft, approve, send, modify and delete permissions so an assistant can prepare work without automatically publishing or destroying it
• Keep untrusted email, web pages, uploaded files and retrieved documents visibly separated from system instructions and treat them as possible prompt-injection carriers
• Require human approval for payments, account changes, code deployment, external communication, access grants and irreversible data operations
• Show reviewers the exact action, target, evidence, credential scope, cost and rollback plan before asking for approval
• Set rate, time, recursion, data-volume and financial limits, then stop the agent when its behavior crosses the task envelope
• Record prompts, retrieved sources, tool calls, authorization decisions, outputs, human approvals, errors and final side effects in a tamper-resistant audit trail
• Make revocation immediate and test it regularly, including whether cached sessions, queued jobs, delegated agents and copied tokens actually stop
• Red-team indirect prompt injection, confused-deputy attacks, permission escalation, data exfiltration, forged approvals, log gaps and recovery from partial execution