Zero Trust for AI Assistants and Agents: Least Privilege for Prompts, Plugins, and Connectors

Overview

Artificial intelligence (AI) assistants respond to prompts. AI agents go a step further by taking action, accessing data, triggering workflows, and interacting with connected systems through plugins and connectors.

Because these systems can read, write, and move data across enterprise environments, organizations need zero trust controls built into every layer of the workflow. That includes least-privilege access, continuous verification, and inline policy enforcement at the prompt, plugin, and connector level.

An AI assistant primarily generates information, summaries, or recommendations. An AI agent can also execute multi-step tasks using tools and external systems, which significantly expands the security risk and potential blast radius.

Introduction

Without zero trust controls, AI agents often end up with broader access than most employees. They can read email, query databases, update customer relationship management (CRM) systems, and trigger workflows across connected environments. In many organizations, that access was granted through the path of least resistance: full-scope tokens, inherited permissions, and standing service accounts.

Most authorization models assume a human user completing tasks one at a time. AI agents operate very differently, chaining together actions across multiple systems and applications in seconds.

According to the Zscaler ThreatLabz 2026 AI Security Report, AI transaction volume grew 83.3% year over year. The agents driving those interactions are already embedded inside enterprise environments, and many organizations still lack effective governance over how those systems operate.

Zero trust provides a more practical security model for AI-driven workflows.

Applying least privilege, continuous verification, and inline enforcement at the prompt, plugin, and connector level gives security teams more control without slowing AI adoption. The shift from open-ended agent access to scoped, verified, and auditable workflows helps organizations scale AI more safely across the enterprise.

Why do AI agents expand the attack surface?

AI assistants answer questions. AI agents plan multi-step workflows and execute them through tools, plugins, and connectors. That distinction matters because the security implications are fundamentally different.

Microsoft 365 Copilot can query organization-wide email and calendar data. Salesforce Einstein can read and update customer relationship management (CRM) records. GitHub Copilot can access large portions of source code repositories. Agents built on Model Context Protocol (MCP) servers can also connect directly to databases, application programming interfaces (APIs), and internal services through standardized interfaces.

Most of these systems inherit permissions originally designed for a human sitting at a keyboard. The difference is scale. A person reads one email at a time, while an agent can query thousands in seconds. The permission model may appear identical, but the resulting exposure is not.

New attack paths and prompt-based threats

Overprivileged connectors create one of the biggest risks in AI workflows.

An agent with broad access to a file system, CRM platform, or internal application can expose significantly more data than a typical user session ever would. Retrieval-augmented generation (RAG) pipelines, long-term memory stores, and conversation logs expand that exposure even further, creating additional surfaces for data leakage.

Prompt injection attacks introduce another layer of risk by manipulating agent behavior through crafted instructions.

In indirect prompt injection attacks, malicious instructions are hidden inside content the agent later retrieves, such as a shared document, support ticket, email thread, or internal knowledge base article. The model processes those instructions as legitimate context without recognizing them as adversarial.

The stakes increase significantly once agents can modify systems or trigger workflows directly. An agent with write access to a ticketing platform, deployment pipeline, or business application may act on injected instructions automatically. At that point, the issue is no longer limited to data exposure. The agent can begin affecting operational systems directly.

Data poisoning compounds the problem further. Attackers can inject malicious content into retrieval corpora, including document repositories, email archives, or vector databases, influencing how the agent behaves during future workflows.

Blast radius: The risk metric that defines agent impact

Blast radius measures the potential scope of damage a compromised or manipulated agent could cause.

Security architects should account for blast radius during connector design and permission scoping, before an agent ever reaches production. In most cases, three variables define the risk profile:

• The number of systems the agent can access
• The types of data domains it can reach
• Whether the permissions are read-only or write-enabled

An agent with full mailbox access, CRM write permissions, and connected source code repositories creates a fundamentally different level of exposure than an agent limited to read-only access within a single project folder.

The underlying technology may be similar, but the operational risk is dramatically different.

That is why blast radius should function as a practical scoping tool when designing connector permissions and workflow boundaries.

How zero trust secures AI agent workflows

Zero trust exchange: Mapping zero trust steps to AI workflows

Traditional zero trust models focused primarily on verifying a human user requesting access to an application. AI workflows require organizations to extend that model across several additional layers.

In an AI-driven workflow, security teams need visibility into:

• The human initiating the request
• The agent acting on the user’s behalf
• The connectors the agent is authorized to access
• The specific actions attempted within each connector
• The data the agent retrieves, generates, or modifies

Each layer requires its own verification and policy decision: verify identity, determine what the agent is attempting to access, assess risk, and enforce policy before execution occurs.

That evolution matters because AI workflows introduce runtime behavior traditional access models were never designed to evaluate continuously.

Identity for agents: Who and what is acting

Three identity layers converge inside every AI workflow:

• The human user
• The AI agent
• The workload or infrastructure hosting the agent

In practice, organizations usually handle these identities in one of three ways, but only one consistently supports secure AI operations at scale.

Inherited user token

In this model, the agent operates with the same permissions as the user who launched it.

While convenient, inherited access often creates overprivilege risk because the agent gains visibility into systems and data unrelated to the specific task being performed. A marketing analyst’s Copilot session, for example, may unintentionally grant the agent access to every resource the employee can reach, regardless of what the workflow actually requires.

Shared service account

Some organizations rely on shared credentials across multiple agents or workflows.

The biggest issue is accountability. When several agents share the same token, incident responders lose the ability to attribute actions to a specific workflow, execution path, or user request.

Scoped agent token

This is the preferred model for AI workflows. Each agent receives a dedicated, short-lived token scoped specifically to the task being performed. Permissions expire automatically when the workflow completes.

MCP servers require separate governance under this approach because they expose callable tool endpoints that agents use during execution. Those endpoints need their own identity controls independent of the agent token itself.

Strong authentication, multifactor authentication (MFA), scoped permissions, and time-bound credentials help reduce unnecessary standing access while improving visibility and auditability.

Continuous verification builds directly on this foundation. Scoped access limits what an agent can reach, while continuous verification ensures activity stays within policy boundaries throughout execution.

Continuous verification for agent activity

Static authorization at login is not sufficient for AI workflows.

AI agents may perform dozens or hundreds of actions during a single session, requiring authorization checks throughout execution rather than only at login.

Step-up authentication becomes important for sensitive actions such as:

• Modifying production databases
• Exporting customer data
• Changing access controls
• Triggering external workflows

Behavioral signals provide additional context for risk evaluation.

An agent that normally accesses five documents per session but suddenly queries hundreds may indicate compromise, abuse, or misconfiguration. Unusual access patterns, sudden volume spikes, and workflow sequences that fall outside expected behavior should all trigger additional verification and policy enforcement.

Least privilege as the default for agents

Least privilege should serve as the baseline for every AI workflow. That means limiting both the data an agent can access and the actions it can perform.

Organizations should adopt just-in-time and just-enough access models wherever possible. Instead of granting standing permissions during deployment, agents request scoped access during execution and relinquish it once the task is complete.

Time-bound approvals add another layer of protection. For example, a user may authorize an agent to send emails on their behalf for the next 30 minutes instead of granting indefinite access. Once the approval window closes, the permissions expire automatically.

That approach reduces persistent privilege risk while maintaining operational flexibility.

How to secure AI plugins, connectors, and MCP servers

Connector inventory and classification

Organizations cannot secure connectors they have not cataloged.

A complete inventory should identify every plugin, connector, and MCP server operating across the environment, including the owner, deployment environment, purpose, associated permissions, and connected systems or data domains.

From there, connectors should be classified across two dimensions:

• Privilege level, including read-only, write, or administrative access
• Data domain, including Human Resources (HR), Finance, Legal, Engineering, customer data, or source code

Embedded AI agents inside software-as-a-service (SaaS) platforms require special attention.

Tools like Microsoft 365 Copilot, Salesforce Einstein, and ServiceNow AI agents operate under delegated user identity and inherit existing SaaS permissions. That creates a different governance challenge than traditional API-scoped connectors because the permissions often originate from the underlying user account itself.

MCP servers also deserve separate governance consideration.

MCP servers expose callable tool endpoints that agents use during execution. A compromised or misconfigured MCP server can unintentionally expand an agent’s access far beyond the intended scope. Treating MCP governance as its own inventory category improves visibility and helps reduce hidden privilege escalation paths.

Permission scoping patterns

Least privilege should extend directly into connector design. In practice, that means narrowing permissions as much as possible without breaking the workflow itself.

Effective permission scoping patterns typically include:

• Read-only access by default
• Folder-level or project-level permissions instead of full drive or mailbox access
• Allowlisting specific API endpoints and actions
• Separate tokens for separate tools and workflows
• Explicit approval requirements for write or administrative privileges
• Regular review and rotation of connector credentials

These controls reduce standing access and help limit blast radius if an agent becomes compromised or manipulated. Even small reductions in scope can significantly reduce downstream risk.

Guarding against indirect prompt injection

Prompt injection attacks introduce another layer of risk by manipulating agent behavior through crafted inputs.

In indirect prompt injection attacks, malicious directives are hidden inside retrieved content that may come from:

• Retrieval-augmented generation (RAG) systems
• Shared documents
• Email threads
• Internal knowledge bases
• Support tickets
• Web content

Without safeguards, the model may interpret retrieved instructions as trusted context.

One of the strongest mitigations is architectural separation.

Data context and instruction context should be processed independently so retrieved content cannot override system-level instructions. When an agent retrieves a document, for example, that content should enter a controlled data layer rather than being treated as executable instruction context.

Security teams can also apply enforcement controls before retrieved content reaches the model.

Those controls may include:

• Filtering and classifying retrieved content
• Restricting which instructions can trigger actions
• Constraining tool execution rules
• Requiring user confirmation for sensitive workflows
• Validating outputs before execution

Together, these controls reduce the likelihood that manipulated content can trigger unintended downstream actions.

Connector governance controls

Connector governance needs to extend beyond formal approval workflows.

Many organizations focus only on officially requested integrations while overlooking shadow connectors introduced through developer environments, unmanaged tools, or unsanctioned AI experimentation.

A mature governance process should include:

• Approval workflows for all new connectors
• Visibility into connectors appearing outside formal information technology (IT) processes
• Verified publisher or developer requirements
• Privacy and data handling reviews
• Ongoing connector usage assessments

Connector governance should extend through the full lifecycle, including decommissioning. Removing a connector from an approved list is not enough. Effective programs also typically revoke associated tokens, review access logs covering the connector’s active period, and confirm the connector can no longer authenticate successfully after removal.

Without those steps, residual access may persist long after the integration is considered retired.

How to control data access in AI workflows

Inspect and enforce at the prompt layer

Prompts have become a major enterprise data exposure point.

Employees routinely paste sensitive information into AI systems, including personally identifiable information (PII), Payment Card Industry (PCI) data, protected health information (PHI), credentials, source code, and confidential business content.

That is why organizations need visibility and policy enforcement directly at the prompt layer.

Effective controls typically include:

• Prompt capture and classification
• Acceptable use enforcement
• Content moderation
• Inline data loss prevention (DLP) for prompts and uploads
• Blocking or restricting sensitive data types
• Redaction and tokenization where appropriate

Inspection should not stop at prompts alone. Responses also need to be evaluated because models can unintentionally echo sensitive retrieved data, expose internal system context, or generate policy-violating content.

Response inspection closes the loop on inline enforcement and helps prevent downstream exposure.

Reduce data sharing risk with isolation controls

Isolation controls provide another layer of protection for high-risk AI workflows.

Browser and session isolation become especially important on unmanaged devices and bring your own device (BYOD) endpoints where organizations may lack endpoint agents, local DLP, or visibility into user activity.

Instead of relying entirely on device posture, isolation enforces security controls directly at the session layer.

Organizations can restrict or monitor:

• Copy and paste actions
• File uploads and downloads
• Clipboard sharing
• Printing
• Data transfers to untrusted destinations

These controls help reduce the likelihood of sensitive information leaving controlled environments during AI interactions.

Protect outputs and downstream actions

Securing AI workflows means controlling not only what enters the model, but also what the model is allowed to do afterward.

Generated outputs can expose sensitive information, trigger unauthorized actions, or distribute content to unintended destinations if guardrails are not in place.

A stronger approach could mean implementing controls that:

• Prevent sensitive data from appearing in responses
• Restrict agent actions such as send, share, publish, or post
• Validate downstream workflows before execution
• Require human approval checkpoints for high-risk actions

Human-in-the-loop controls are particularly important for workflows involving financial transactions, external communications, access changes, or production systems.

These controls help organizations maintain oversight over sensitive actions as AI workflows become more automated.

Logging and audit trails

Every AI interaction generates an audit record.

Organizations need visibility into:

• Who initiated the request
• Which agent executed the action
• Which tool or connector was involved
• What data was accessed
• What action occurred
• When the activity took place

These logs serve both operational and governance purposes.

Operationally, security teams rely on audit trails to investigate incidents, trace unexpected agent behavior, and reconstruct workflow activity during response efforts.

From a governance perspective, frameworks such as the NIST AI Risk Management Framework, the European Union (EU) AI Act, and International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 42001 all require demonstrable visibility into AI system activity.

Organizations that cannot produce an audit trail showing what an agent accessed, modified, or executed under a specific authorization context may struggle to meet compliance expectations.

Comprehensive audit trails give organizations the visibility needed for both AI security operations and long-term governance.

Reference architecture and rollout plan for AI agent security

At a high level, the architecture should evaluate every request before an AI workflow can access sensitive data or execute downstream actions.

The workflow typically follows this pattern:

Users and devices → inline policy enforcement point → AI applications, agents, and connectors

Several supporting layers work together behind that enforcement point:

• Identity provider integrations authenticate users, agents, and workloads
• Risk engines evaluate behavioral and contextual signals
• Data protection layers apply classification and DLP policies
• Audit pipelines capture telemetry and workflow activity

The control plane manages policy creation, orchestration, reporting, and centralized governance while the data plane handles inline inspection, action enforcement, and session-level visibility during execution.

Separating those layers improves scalability, enforcement consistency, and visibility across AI workflows.

A phased rollout: Five steps from discovery to operations

Organizations should approach AI security rollout in phases rather than attempting to deploy every control simultaneously.

Each phase builds on the previous one.

Discovery comes first because organizations cannot scope or secure assets they have not inventoried. Scoping comes next because enforcement policies applied to overprivileged environments create friction without meaningfully reducing risk. Enforcement should come before isolation because organizations need visibility and policy controls in place before restricting higher-risk workflows.

Phase 1: Discovery

Inventory all AI applications, agents, connectors, and MCP servers across the environment. Identify shadow AI usage, map data flows, and document existing permission levels.

Phase 2: Scoping

Apply least-privilege permissions and remove unnecessary full-access grants. Assign blast radius scores to workflows based on system reach, data access, and write permissions.

Phase 3: Enforcement

Deploy prompt inspection, content moderation, and inline DLP policies. Enable behavioral monitoring and continuous verification controls across agent workflows.

Phase 4: Isolation

Add browser and session isolation controls for high-risk workflows, unmanaged devices, and sensitive data interactions. Constrain tool execution policies and downstream actions.

Phase 5: Operations

Operationalize governance through recurring reviews, metrics dashboards, audit processes, policy tuning, and AI-specific tabletop exercises.

Security teams should continuously evaluate agent behavior, connector usage, and policy effectiveness as workflows evolve.

Common AI agent security mistakes to avoid

Security teams tend to encounter the same failure patterns repeatedly when securing AI workflows. Most stem from overly broad access, weak governance, or limited visibility into how agents interact with systems and data.

One-time consent that never expires

One of the most common issues is granting access once and never revisiting it.

Permissions approved during initial deployment often persist indefinitely without expiration, validation, or periodic review. Over time, agents accumulate access that no longer aligns with their original use case, increasing unnecessary exposure across connected systems.

Shared service accounts and long-lived tokens

Shared credentials and long-lived tokens create major accountability and governance gaps.

In some environments, teams deploy broad-scope access because it simplifies integration and reduces deployment friction. In others, the permissions may have started appropriately scoped but were never reviewed, rotated, or revoked as workflows evolved over time.

Without clear ownership and lifecycle management, organizations lose visibility into who authorized access, which agent used it, and whether the permissions still match the workflow.

Overly broad connector permissions

Many AI workflows still operate with mailbox-wide, drive-wide, or administrative-level access when the task itself only requires a narrow subset of permissions.

This often happens because broad access is easier to configure than granular scoping. The result is a significantly larger blast radius if an agent becomes compromised or acts on manipulated instructions.

Limited auditability and workflow visibility

Organizations frequently underestimate the importance of centralized logging and audit trails.

Without visibility into prompts, connector activity, downstream actions, and data access, security teams struggle to investigate incidents or understand how agents interact with sensitive systems and information.

Incomplete audit trails also create governance and compliance challenges as AI regulations continue to evolve.

Automating sensitive actions without human approval

Automation becomes risky when organizations remove human checkpoints from high-impact workflows.

If an agent acts on manipulated instructions without approval controls, the downstream impact may include unauthorized communications, workflow disruptions, policy violations, or operational changes inside production environments.

Human-in-the-loop validation remains critical for sensitive actions involving financial systems, external communications, or privileged access changes.

Treating AI security as disconnected point solutions

Many organizations approach AI security as a collection of separate tooling problems.

One platform handles prompt inspection. Another governs connectors. Another manages posture visibility. Another monitors runtime behavior.

The result is fragmented enforcement, inconsistent visibility, and incomplete audit trails between control points.

AI security works best when governance, access control, inspection, and runtime protection operate as part of a unified framework.

How Zscaler protects AI assistants and agents with zero trust

AI adoption is accelerating faster than most security programs can adapt. Agents are already operating across enterprise environments with access to sensitive systems and data. The question is whether the controls governing them are commensurate with the access they hold.

Zscaler delivers AI security through three integrated pillars on the Zero Trust Exchange™ platform.

AI Asset Management

AI Security Posture Management (AI-SPM) helps organizations eliminate the visibility gaps that allow shadow AI usage to bypass governance controls.

Security teams gain a continuously updated inventory of AI applications, agents, models, connectors, and MCP servers operating across the environment.

AI-SPM identifies excessive permissions, risky configurations, and governance gaps before they become operational problems.

AI Access Security

AI Access Security applies least-privilege access controls and inline data protection at the prompt layer.

Every AI interaction passes through policy enforcement that inspects prompts, responses, file uploads, and downstream actions. Granular controls determine which users can access which tools, under what conditions, and with what permissions.

This allows organizations to scale sanctioned AI adoption without increasing the risk of sensitive data exposure.

AI Red Teaming and AI Guardrails

AI Red Teaming and AI Guardrails connect adversarial testing directly to runtime protection.

Automated testing identifies exploitable weaknesses, including prompt injection exposure, jailbreak susceptibility, and unsafe tool execution paths. Those findings feed directly into runtime guardrails that block policy violations and malicious behavior during production use.

That closed-loop relationship between testing and enforcement helps organizations continuously improve protection as workflows evolve.

The controls described throughout this article also align closely with governance requirements in the NIST AI RMF, the EU AI Act, and ISO/IEC 42001.

Instead of relying on disconnected tools for discovery, connector governance, runtime inspection, and posture management, organizations can apply those controls through a unified platform with centralized visibility and policy enforcement.

Zero trust is becoming the foundation for AI governance

AI adoption will continue accelerating. The question for security leaders is no longer whether agents will expand across the environment, but whether governance and enforcement controls will evolve alongside them.

Zero trust provides the architectural foundation for that shift.

Applying least privilege, continuous verification, and inline enforcement throughout the workflow helps organizations reduce blast radius, protect sensitive data, and maintain the visibility needed for both security operations and governance.

Request a demo to see how Zscaler secures AI workflows. 

Download the Zscaler ThreatLabz 2026 AI Security Report for the latest research on AI-driven threats and enterprise adoption trends. 

Read How to Detect and Defend Against Shadow AI for a practical checklist on identifying and governing unsanctioned AI in your environment.