Autonomous agents are a new Zero Trust subject
Tata Consultancy Services’ recent focus on Zero Trust for Autonomous Agents signals an important shift in enterprise security thinking. Zero Trust has traditionally concentrated on people, devices, workloads, applications, and network connections. Autonomous AI agents introduce a sixth security subject: software that can interpret a goal, select tools, retrieve information, call APIs, and sometimes execute a multi-step process with limited real-time human review.
That is not simply another chatbot deployment. A generative AI assistant that drafts a response from a controlled knowledge base creates one type of risk. An agent that can read customer records, query a data warehouse, open a support ticket, change a cloud configuration, approve a refund, or initiate a supplier workflow creates a very different one. The agent becomes an operational identity with access, authority, and the capacity to make consequential decisions.
The practical implication is clear: organizations cannot treat an agent as inherently trustworthy because it was built internally, runs in an approved cloud account, or was launched by an authenticated employee. Zero Trust’s core premise—never trust implicitly, always verify continuously—must now apply to each agent, each delegated task, each tool call, and each data retrieval.
Why traditional access controls are insufficient
An agent’s risk changes during execution
Conventional access control commonly evaluates a user at login and grants access based on a static role. That model struggles with autonomous agents because their actions can evolve during a session. An agent may begin with a legitimate request—such as summarizing a sales account—but then encounter content that attempts to redirect it toward an unrelated action, a classic prompt-injection scenario.
For example, an AI agent reviewing inbound supplier documents may be instructed through malicious text embedded in a PDF to export payment information, change bank-account details, or retrieve unrelated records. The agent is not “compromised” in the traditional malware sense; it may be following instructions it cannot safely distinguish from authorized ones. A single broad permission set makes that failure far more damaging.
Zero Trust reduces this exposure by requiring contextual authorization at the point of action. The relevant question is not only, “Is this agent registered?” It is also: “Is this specific action appropriate for this agent, this user-delegated request, this data classification, this environment, and this moment?”
Delegation creates an accountability gap
An agent may act on behalf of an employee, a business process, or another agent. Unless that delegation is explicit and verifiable, security teams lose a reliable answer to a basic incident-response question: who authorized this action, and under what limits?
A mature design should preserve a chain of authority. If a procurement employee asks an agent to prepare a purchase order, the agent should receive a narrowly scoped, time-limited delegation token—not the employee’s standing credentials and not unrestricted access to procurement systems. Every downstream call should retain evidence of the original requester, the agent identity, the approved purpose, and the exact permissions used.
API access turns reasoning errors into business actions
Language models can be useful despite occasional mistakes when their output is reviewed by a human. The security stakes rise when an agent can invoke APIs. An inaccurate inference, manipulated instruction, or flawed tool selection can lead to a real database update, cloud policy modification, financial transaction, or disclosure of regulated data.
For Zero Trust practitioners, this means tool access deserves the same rigor previously reserved for privileged administrator access. The risk is not merely that the AI model generates an incorrect sentence. It is that the model’s output becomes an executable request.
The Zero Trust controls organizations should apply
Give every agent a distinct, verifiable identity
Do not use shared service accounts for multiple agents, environments, or business functions. Each agent should have a unique workload identity tied to its owner, purpose, deployment environment, approved tools, and lifecycle status.
This identity should be cryptographically protected where possible and managed through a centralized identity platform. Teams need to be able to revoke it quickly, rotate its credentials, and determine whether it is a production agent, a test instance, a subordinate agent, or an unauthorized copy.
A useful policy principle is: one agent, one purpose, one identity boundary. A customer-service agent should not silently inherit the permissions of a finance agent simply because both were developed on the same platform.
Replace broad permissions with task-scoped authorization
Least privilege must become more granular for autonomous systems. Instead of granting an agent permanent access to an entire CRM, define the smallest set of actions and records required for a specific task.
For instance, an account-support agent might be allowed to read support cases associated with a named customer account for 20 minutes, redact sensitive fields before presenting them to a user, and create a draft case update. It should not be able to search all customers, download the whole database, or close a case without an approval step.
Policy decisions should consider attributes such as:
- The agent’s assigned function and trust tier.
- The human or workflow that delegated the task.
- The requested tool, API method, and data sensitivity.
- The environment, device posture, and network context.
- Transaction value, destination, and anomaly indicators.
- Whether the action is reversible or requires human approval.
This is where attribute-based access control, policy-as-code, and just-in-time authorization become more valuable than static roles alone.
An agent should not have unrestricted network reachability simply because it runs inside a trusted virtual private cloud or Kubernetes cluster. Apply microsegmentation and service-level authentication so that the agent can communicate only with explicitly approved model endpoints, data stores, APIs, and orchestration services.
This is especially important for multi-agent systems. A planning agent, research agent, transaction agent, and approval agent should not automatically trust one another. Each handoff needs authenticated identity, a narrowly defined message schema, authorization for the requested task, and logging. Otherwise, a compromised or manipulated low-privilege agent can become a pathway to a higher-impact system.
Treat prompts, retrieved content, and tool outputs as untrusted input
Zero Trust is not only a network architecture. For AI agents, it must extend to the information entering the reasoning process. Web pages, emails, documents, retrieved knowledge-base entries, and tool responses can all contain malicious or misleading instructions.
Organizations should separate data from executable instructions, sanitize retrieved content where feasible, enforce tool allowlists, and validate parameters before an API call is made. Sensitive operations should use deterministic controls outside the model—for example, a policy engine that rejects an attempted payment above a threshold regardless of how persuasive the model’s reasoning appears.
Monitor behavior, not just authentication events
A valid agent identity can still behave dangerously. Security telemetry should capture agent sessions, delegated authority, prompt and retrieval provenance where privacy permits, tool invocations, API parameters, data accessed, policy decisions, and final outcomes.
Behavioral baselines can help identify suspicious patterns: an agent accessing unusually large volumes of records, calling a tool it rarely uses, operating outside normal hours, repeatedly failing authorization checks, or attempting lateral movement across applications. The goal is not to log every model token indiscriminately; it is to create actionable evidence of decisions and actions while protecting sensitive data.
A practical implementation roadmap
Organizations do not need to solve every AI governance issue before applying Zero Trust. Start with an inventory. Identify every agent in development or production, its business owner, model provider, data sources, tools, identities, and permissions. Shadow agents built through low-code platforms deserve equal attention.
Next, classify agents by impact. An internal research assistant with read-only access has a different risk profile than an agent that can modify payroll, provision cloud resources, or communicate externally. Prioritize controls around agents that can execute transactions, access regulated data, or affect production systems.
Then establish a minimum control baseline: unique nonhuman identity, secret management, least-privilege API scopes, short-lived credentials, explicit delegation, approved tool allowlists, centralized logging, and emergency revocation. For high-impact actions, add transaction limits and human approval gates.
Finally, test the controls with realistic adversarial scenarios. Ask whether a malicious document can alter the agent’s intended behavior, whether an agent can exceed the user’s authority, whether a compromised tool can request more data than needed, and whether the security team can reconstruct and stop a harmful action quickly.
The strategic takeaway
The TCS framing matters because autonomous agents are moving security design beyond the familiar user-device-application model. The central issue is not whether enterprises should use AI agents; many already are. The issue is whether those agents will receive durable, opaque, and overly broad power—or whether their authority will be continuously verified, narrowly constrained, and observable.
Zero Trust provides a disciplined answer. It does not promise that an AI model will never be manipulated or make an error. It limits the blast radius when that happens. For security leaders, that is the essential objective: allow useful automation while ensuring no autonomous agent is trusted beyond what it can prove it needs for the task at hand.
FAQ
What is Zero Trust for autonomous AI agents?
It is the application of Zero Trust principles to AI systems that can independently retrieve data, use tools, call APIs, and complete workflows. It requires strong agent identity, explicit and context-aware authorization, least privilege, segmentation, continuous monitoring, and rapid revocation.
Why can’t an AI agent use a standard service account?
A shared or long-lived service account obscures accountability and commonly grants excessive access. A unique agent identity enables teams to restrict permissions by task, trace actions to a specific agent and delegation chain, rotate credentials, and revoke access without disrupting unrelated services.
Should every AI agent require human approval?
No. Requiring approval for low-risk, reversible actions can eliminate the operational value of automation. Instead, apply risk-based controls. Routine read-only tasks may be automated, while actions involving payments, production changes, external communications, regulated data, or irreversible updates should require stricter policies or human approval.
What is the first Zero Trust control to implement for agents?
Create a complete inventory and assign each agent a unique nonhuman identity. Without knowing which agents exist, who owns them, what tools they use, and what data they can reach, an organization cannot enforce least privilege or investigate misuse effectively.
Source: Tata Consultancy Services — Sun, 27 Sep 2026 11:23:33 GMT
