Zero Trust for enterprise AI: applications, copilots and agents

July 2, 2026

Introduction

The adoption of Artificial Intelligence in enterprise environments is expanding the exposure surface by combining users, data, models, connectors, APIs, automation and agents in increasingly autonomous flows. In this context, the Zero Trust approach enables organisations to move forward with the use of AI without relying on implicit trust, continuously verifying who is accessing what information, with which permissions and to perform which actions.

In this article, we describe the main risks associated with AI applications, copilots and agents: exposure of sensitive information, excessive inherited permissions, the use of non-human identities without governance, poorly protected secrets, prompt injection, loss of traceability, shadow AI and difficulty revoking access in the event of an incident.

To address these risks, we propose applying the three Zero Trust principles —verify explicitly, least privilege and assume breach— across all the layers involved in the AI lifecycle.

Why Zero Trust is becoming more important with the arrival of AI

Enterprise AI is changing how companies design, use and protect their applications. We are no longer talking only about users accessing corporate systems, but about copilots querying internal repositories, assistants interacting with customers in ways that are not always predictable, generative models processing sensitive information and agents performing actions on business tools with increasing autonomy.

This new scenario increases the exposure surface. An AI application can combine data, context, permissions, APIs, connectors, models and automation in a single flow. If any of these elements is not properly governed, the risk is not limited to an incorrect query: it can lead to information exposure, abuse of privileges, execution of unauthorised actions or loss of traceability.

Zero Trust provides a particularly useful framework for these environments because it is based on three fundamental principles: verify explicitly, apply least privilege and assume that a breach may occur. In AI applications, these principles must extend beyond the network and also be applied to data, human and non-human identities, connectors, APIs, agents, prompts, models and automated actions.

AI adoption should not be an exception to existing security models, but an opportunity to strengthen them.

How the attack surface changes with enterprise AI

Traditional applications usually follow relatively defined flows: a user accesses an application, performs a specific operation and the system applies known rules. AI applications introduce an additional layer of interpretation, generation and, in many cases, action.

This change creates new risk scenarios:

  • An enterprise copilot can access information spread across documents, emails, wikis, CRM systems or collaboration platforms.
  • An AI agent can query a database, generate a response, open a ticket and modify a record.
  • A chatbot can interact with customers, validate personal data or escalate incidents.
  • An AI-enabled SaaS solution can process internal information under conditions that are not always visible to security teams.

Some of the most significant risks are:

  • Exposure of sensitive data due to misconfigured permissions.
  • Use of shared accounts to connect models, APIs or tools.
  • Agents that execute actions without sufficient controls.
  • Prompt injection to manipulate instructions or extract information.
  • Shadow AI through the use of unauthorised tools.
  • Indirect access to data through copilots or connectors.
  • Lack of traceability between user, agent, data queried and action performed.
  • Privilege escalation through poorly governed integrations.
  • Persistence of tokens, API keys or secrets in uncontrolled environments.
  • Difficulty revoking access in real time.
  • Use of non-human identities without a clear owner.
  • Lack of separation between testing, training and production environments.
  • Risks arising from SaaS providers with integrated AI capabilities.
The central question is how to adopt AI without losing control over access, data, decisions, actions and traceability.

The starting point: dynamic trust, context and control

Zero Trust does not mean blocking every use of AI by default. It means replacing implicit trust with access decisions based on context, risk and real need.

In an AI application, the same request can have very different implications depending on the user, type of data, channel, device, location, tool invoked, sensitivity of the information or action requested.

Example: Asking an assistant to summarise a public internal policy is not the same as asking it to extract customers’ personal data, analyse confidential contracts or modify records in a financial system.

That is why control must be applied across several layers:

  • Before the interaction, validating access, device, security posture and permissions.
  • During the interaction, controlling data queried, prompts, tools invoked and possible actions.
  • After the interaction, recording events, detecting anomalies, reviewing decisions and adjusting policies.
Identity and access governance must ensure that every entity (user, service or agent) acts only when appropriate, with the necessary permissions and clear traceability.

Zero Trust principles applied to AI applications and agents

Verify explicitly

Every access request must be assessed with sufficient signals. In AI applications, verification should not be limited to login. It must also consider which resource is being queried, which tool is being invoked, which action is intended to be performed and whether all of this is consistent with the context.

Example: an authenticated user may have permission to view commercial information, but not necessarily to ask a copilot to combine customer data, margins, contracts and financial forecasts. Explicit verification must assess whether that request is consistent with their role, the sensitivity level of the data and the purpose of the use case.

Associated risks

  • Legitimate sessions used to access data that is not needed.
  • Correct initial authentication, but subsequent actions not verified.
  • Connectors operating without contextual validation.
  • Agents executing tools without additional checks.
  • Lack of adaptive controls when risk changes.

Recommended actions

  • Apply multifactor authentication and conditional access policies.
  • Use risk signals to authorise sensitive queries or actions.
  • Validate every critical API or tool invocation.
  • Require enhanced controls for high-impact operations.
  • Correlate user, device, application, agent and queried resource.

Apply least privilege

AI applications amplify the impact of excessive permissions. A poorly governed repository was already a problem before AI, but a copilot can make it more visible by enabling searches, summaries and correlations of information that previously required manual effort.

Least privilege must be applied to users, groups, service accounts, agents, connectors, functions, API keys and models that access data or tools.

Associated risks

  • Copilots inheriting overly broad permissions.
  • Service accounts with permanent privileges.
  • Agents able to read, modify and execute without separation of duties.
  • APIs with generic scopes.
  • Oversized corporate groups.
  • Permissions accumulated due to role changes or lack of recertification.
  • Third-party access that has not been reviewed.
  • Long-lived tokens without rotation.
  • Connected tools with permissions greater than the use case requires.

Recommended actions

  • Review permissions before enabling copilots or connectors.
  • Differentiate permissions for reading, summarising, exporting, modifying and executing.
  • Use just-in-time and just-enough-access permissions for sensitive operations.
  • Establish periodic access reviews.
  • Remove shared accounts.
  • Define specific identities for agents and services.
  • Limit API scopes to the specific use case.
  • Apply expiry, rotation and secure custody of secrets.

Assume breach

In AI, assuming breach means designing systems on the basis that a prompt may be manipulated, an account may be compromised, a token may be leaked, a connector may be misconfigured or an agent may execute an unwanted action.

The answer is not to prevent every use case, but to limit impact. This requires segmentation, isolation, data controls, action limits, monitoring, and records that are useful for auditing and response.

Associated risks

  • Lateral movement from AI integrations into other systems.
  • Mass access to information through compromised connectors.
  • Execution of chained actions by agents.
  • Exfiltration through model-generated responses.
  • Lack of usage limits or rate limiting.
  • Difficulty reconstructing the sequence of events.
  • Persistence of compromised credentials.
  • Absence of rapid revocation mechanisms.

Recommended actions

  • Segment environments, data, applications and APIs.
  • Isolate agents according to criticality and functional domain.
  • Establish limits for queries, actions and volume.
  • Apply DLP and exfiltration detection.
  • Record the events needed for auditing, including metadata for prompts, responses, tools invoked and actions, always respecting privacy and compliance requirements.
  • Integrate AI events into SIEM, SOAR, XDR or equivalent platforms.
  • Prepare specific playbooks for AI-related incidents.
  • Automatically revoke tokens or sessions when signs of compromise are detected.
  • Govern identity, including just-in-time privileged access.

Table of risks, controls and recommended actions

Click to enlarge

Recommendations for starting a Zero Trust strategy applied to AI

Inventory AI applications, agents and integrations

The company must know which AI solutions are in use, who manages them, what data they process, what permissions they have, which providers are involved and what actions they can perform.

The inventory should include approved applications, proofs of concept, departmental automation, SaaS connectors, plugins, APIs, notebooks, internal models and external tools.

Review permissions before connecting data

Before enabling a copilot, RAG, assistant or agent on corporate repositories, permissions must be reviewed at source. AI adoption should rely on strong document governance, not replace it.

Immediate actions

  • Identify critical repositories.
  • Review groups with broad access.
  • Detect documents without an owner.
  • Classify sensitive information.
  • Validate actual permissions through access testing.

Govern human and non-human identities

AI applications increasingly depend on non-human identities: service accounts, workloads, connectors, APIs, agents and automation. All identities must be incorporated into the security lifecycle.

Immediate actions

  • Assign an owner to each technical account.
  • Remove shared accounts.
  • Review agent and connector privileges.
  • Rotate secrets.
  • Set expiry for temporary credentials.
  • Audit the use of privileged identities.

Separate reading, analysis and execution

Not all use cases require the same capabilities:

  • An assistant that summarises documentation does not need permission to modify systems.
  • An agent that proposes an action does not necessarily have to execute it automatically.

Immediate actions

  • Define action categories.
  • Limit tools by role and use case.
  • Apply human-in-the-loop (human supervision) in critical operations.
  • Create separate environments for testing and production.
  • Record automated decisions.

Protect APIs, connectors and secrets

Integrations are one of the most sensitive components in enterprise AI. A model or agent is usually only as secure as the APIs and connectors it can invoke.

Immediate actions

  • Use OAuth with minimal scopes.
  • Apply rate limiting.
  • Rotate API keys.
  • Avoid secrets in code.
  • Monitor anomalous calls.
  • Segment APIs by functional domain.

Integrate AI events into security operations

Security teams need visibility. Infrastructure logs are not enough. AI-specific events must be captured: relevant prompts, sources queried, tools invoked, actions performed, associated identity and outcome.

Immediate actions

  • Define minimum audit events.
  • Integrate logs with SIEM or XDR.
  • Create detection rules for anomalous behaviour.
  • Design response playbooks for AI abuse.
  • Periodically review high-risk queries and actions.

Establish a continuous governance framework

Zero Trust applied to AI is not an initial configuration. Models change, providers evolve, agents incorporate new tools and users discover new uses.

Immediate actions

  • Create a secure AI governance committee or function.
  • Define approval criteria for use cases.
  • Establish periodic reviews.
  • Measure exposure, permissions, incidents and exceptions.
  • Keep the catalogue of permitted tools up to date.
  • Carry out adversarial testing and red teaming exercises.

How we can help at Telefónica Tech

At Telefónica Tech, we support companies in the secure adoption of AI through a comprehensive approach that combines strategy, governance, architecture, technology controls and security operations.

Our goal is to help deploy AI use cases with greater control over identities, data, applications, connectors, APIs, agents and models.

  • Zero Trust maturity assessment applied to AI, identifying gaps in governance, identity, permissions, data, monitoring and response.
  • Inventory and governance of AI use cases, including approved applications, agents, connectors, automation, SaaS tools and unauthorised solutions.
  • Design of secure architectures for enterprise AI, incorporating least privilege, segmentation, access controls, data protection and separation between reading, analysis and execution.
  • Protection of human and non-human identities, focusing on service accounts, workloads, agents, secrets, tokens, privileged access and lifecycles.
  • Managed monitoring, detection and response, integrating AI-specific events into SIEM, XDR, SOAR or equivalent platforms.
  • Continuous governance and compliance, through policies, periodic reviews, use case approval criteria, exception management and continuous improvement.

Conclusion: Zero Trust as the foundation for secure and governed AI

Enterprise AI brings productivity, automation and new analytical capabilities, but it also transforms the way companies must protect their data, applications and integrations.

Zero Trust offers a suitable framework for moving forward securely: verifying every access request, limiting privileges, segmenting resources, monitoring activity and assuming that any component can fail or be compromised.

In AI applications, these Zero Trust principles must be applied in a coordinated way across users, agents, APIs, connectors, data, models and workflows. To do this, companies should start by answering five questions:

  1. Which AI applications, models, agents and integrations are in use?
  2. What data can they access and with which permissions?
  3. What actions can they perform and under what conditions?
  4. What controls are in place to detect abuse, exposure or anomalous behaviour?
  5. How are access, tokens, sessions or capabilities revoked in the event of an incident?

✅ Answering these questions properly helps organisations evolve from accelerated adoption towards more secure, controlled and sustainable AI adoption.

______