Artificial intelligence is changing how enterprises access information, execute tasks and interact with business systems. What began with employees using generative AI applications has evolved into a much more complex ecosystem of self-hosted language models, autonomous agents, multi-agent workflows and AI capabilities embedded directly into enterprise software.

These systems are no longer limited to generating content or answering questions. They can retrieve confidential information, invoke APIs, modify business records, execute code, access databases and delegate tasks to other agents.

This shift introduces a fundamental security challenge: the identity and permissions of the person initiating an action are not necessarily the identity and permissions under which an AI agent executes it.

Enterprise security architectures need to account for this change.

‍

The Expanding Enterprise AI Attack Surface

AI is entering enterprise environments through several channels, each introducing different security considerations.

1. Public GenAI applications
   Employees increasingly use applications such as ChatGPT, Claude.ai, Mistral Le Chat and Gemini through browsers and desktop clients. These interactions can involve confidential documents, customer information, source code and internal business data.
   Without adequate visibility and controls, sensitive information can be shared with applications that have not been approved or assessed by the organisation.
2. Self-hosted LLMs
   Organisations are deploying models such as Llama and Mistral within their own infrastructure, connecting them to internal databases, document repositories and Retrieval-Augmented Generation (RAG) systems.
   While self-hosting provides greater control over infrastructure and data residency, it does not automatically address access control, data leakage or inappropriate retrieval of information.
3. Autonomous agents and agent-to-agent communication
   AI agents increasingly interact with other agents, invoke tools, call APIs and execute multi-step workflows. The Model Context Protocol (MCP) and emerging Agent-to-Agent (A2A) communication patterns make these interactions more structured and capable.
   However, every additional tool, agent and delegation introduces another identity, permission boundary and potential path to sensitive resources.
4. AI embedded in enterprise SaaS
   Applications across CRM, ITSM, collaboration, development and productivity platforms are embedding copilots and autonomous agents into existing workflows.
   These capabilities may operate through OAuth permissions and SaaS APIs, creating access paths that traditional network security gateways may not fully inspect.
   The challenge is therefore not simply controlling access to individual AI applications. It is governing the complete chain of interactions between users, agents, models, tools and enterprise data.

‍

What Recent Security Incidents Tell Us

The risks are no longer theoretical.

IBM's 2026 Cost of a Data Breach Report found that incidents involving Shadow AI among breached organisations more than doubled, from 20% in 2025 to 43% in 2026. The average cost associated with these incidents increased to $5.39 million.

Several recent incidents further illustrate why traditional security assumptions need to evolve.

PocketOS: Excessive privileges in an AI coding workflow
A Cursor coding agent running Anthropic's Claude Opus 4.6 was working on a staging environment issue when it encountered a credential mismatch. It located a broadly privileged Railway API token and used it to delete a production database and its volume-level backups through a single API call. The operation took approximately nine seconds.
The incident demonstrated how an agent operating within one environment could exercise permissions extending far beyond its intended task.

McKinsey's Lilli: Inadequate application-level controls
Security researchers at CodeWall used an autonomous agent to identify vulnerabilities in McKinsey's internal AI platform, Lilli. Their research identified unauthenticated API endpoints and exposed access to millions of chat messages.
The incident highlighted how AI-powered security testing can uncover weaknesses in the underlying APIs, application authorization and data-access architecture.

Vercel: Third-party AI tool compromise
A compromise involving Context.ai, a third-party AI tool used by a Vercel employee, provided an attacker with a path to take over the employee's Google Workspace account and subsequently access Vercel systems.
This illustrates another dimension of AI security: third-party AI applications can become part of an organisation's identity and supply-chain attack surface.
Together, these incidents demonstrate that securing AI requires more than model-level safeguards. Credentials, authorization boundaries, API access and runtime behaviour all matter.

‍

Three Principles for Securing Agentic AI

Securing autonomous systems requires extending established identity and Zero Trust principles to AI agents and their interactions.

‍

1. Authenticate Every Identity

Every AI agent should have a distinct, verifiable identity.

Treating agents as extensions of human users or allowing multiple agents to operate through shared API keys creates accountability and authorization problems.

A secure architecture should incorporate:

• Unique identities for individual agents and machine workloads.
• Short-lived credentials and token-based authentication.
• Mutual TLS (mTLS) for service-to-service communication where appropriate.
• Device identity and posture validation for endpoint-based agents.
• Integration with enterprise Identity Providers (IdPs) and secrets-management systems.

The objective is to establish exactly which human, application or autonomous agent is initiating an interaction.

‍

2. Authorize Every Interaction

Authentication establishes identity. Authorization determines what that identity can access and execute.

For agentic systems, authorization cannot depend exclusively on the initiating user's permissions or the access granted to the underlying application.

Policies should evaluate multiple dimensions:

User × Agent × Model × Tool × Dataset

For example, an employee may be authorized to access a customer database through an approved business application. That does not automatically mean an AI agent acting on the employee's behalf should be permitted to retrieve the entire database, export records or delegate those permissions to another agent.

Delegated authorization should follow least-privilege principles. Permissions should be restricted to the specific task and become narrower, not broader, as requests move through agent-to-agent workflows.

Corporate tenants, approved models, authorized tools and permitted datasets should all be considered during policy evaluation.

‍

3. Enforce Controls at Runtime

Even authenticated and authorized agents can make unintended decisions, process malicious instructions or expose sensitive information.

Security controls therefore need to operate during AI interactions, not just when users initially access an application.

Runtime enforcement should include:

• Prompt and response inspection.
• Detection and redaction of PII, PCI data, credentials and confidential information.
• Inspection of uploaded files and retrieved RAG context.
• Detection and mitigation of direct and indirect prompt injection.
• Validation of tool arguments before API calls are executed.
• Token, usage and rate limits.
• Human approval for sensitive or destructive operations.

These controls should be applied as close as possible to the interaction or execution point, before sensitive information is disclosed or an action is performed.

‍

Why an LLM Proxy Alone Is Not Enough

‍

‍

An LLM proxy can provide visibility into requests and responses passing through supported model endpoints. However, enterprise AI usage extends well beyond direct model API calls.

An autonomous agent may invoke an MCP server, call an internal API, delegate a task to another agent or interact with a SaaS application through OAuth.

A security architecture that only inspects model prompts and responses leaves important parts of the execution chain outside its enforcement boundary.

This requires a broader architecture consisting of three complementary components:

• Gateway Proxy
  Provides enforcement and visibility at supported AI entry points through endpoint agents, LLM proxies, MCP and A2A proxies, and SaaS agent integrations.
• Policy Enforcement Engine
  Applies authentication, authorization and runtime guardrails across supported interactions. Decisions consider user identity, agent identity, model, tool, dataset, device and contextual policies.
• Control Plane
  Provides centralised discovery of AI applications, agents and MCP servers, policy management, IdP and secrets-vault integration, human approval workflows and audit capabilities.
  The architecture should support consistent policy decisions across different AI channels rather than requiring separate security policies for every model or application.

‍

The Zaperon Approach: Identity-Centric Security for Agentic AI

At Zaperon, we have been working on extending identity-centric security beyond human users and conventional application access to the increasingly complex ecosystem of AI agents.

The Zaperon Agentic AI Gateway is designed to bring public GenAI applications, self-hosted LLMs, autonomous agents, A2A workflows and SaaS-embedded AI capabilities within a unified security architecture.

It combines gateway proxy capabilities, policy enforcement and centralised control-plane functions to establish identity, evaluate permissions and apply runtime controls across supported AI interactions.

Every policy evaluation should result in an explicit decision:

Allow | Redact | Block | Ask a Human | Audit

The objective is to make security decisions before data is exposed or an action is executed, while maintaining visibility and accountability across the AI execution chain.

As enterprises move from AI assistants to autonomous systems, the definition of identity and access management must evolve accordingly.

The question is no longer just who has access to enterprise data.

It is also which agent is acting, under whose authority, what resources it can access, which actions it can perform and whether those actions remain within the intended boundaries.

Securing the agentic enterprise begins with getting identity, authorization and runtime controls right.