The Hidden Security Risks of Agentic AI in Enterprises—And How to Mitigate Them

Agentic AI is emerging as a transformative force in enterprise operations, offering the ability to break down complex tasks, engage in reasoning and planning, and leverage tools to retrieve data and execute operations. While this capability holds immense potential, it also introduces unique security challenges—especially in authentication and access control.

Unlike deterministic AI systems, where predefined workflows govern decision-making, agentic AI operates in a non-deterministic manner, dynamically deciding how to accomplish tasks. This unpredictability raises significant security concerns, particularly regarding how these AI agents access enterprise data and tools. If not properly managed, an agentic AI system could inadvertently—or maliciously—access sensitive information or execute unauthorized actions.

In this article, we’ll explore these risks in depth and discuss strategies enterprises must adopt to ensure secure AI-driven automation.

What Is an Agentic AI System?

An agentic AI system is an AI-powered agent capable of reasoning, iterative planning, and autonomous problem-solving. Unlike traditional AI models that follow scripted flows, agentic AI can adapt dynamically, making real-time decisions to achieve a goal.

Key characteristics of agentic AI include:

• Task decomposition: Breaking down complex problems into smaller, manageable subtasks.
• Reasoning and planning: Analyzing multiple possible approaches and determining the best course of action.
• Tool access and execution: Leveraging enterprise applications, APIs, and data sources to gather insights and take action.

For enterprises, these capabilities can drive efficiency, especially in areas like customer service, cybersecurity, and research. But the power of agentic AI also introduces risks, particularly when it comes to how these AI agents authenticate and interact with enterprise tools.

Security Risks: How AI Agents Access Enterprise Tools

Let’s consider an example: an Agentic IT Support Assistant.

A traditional IT support chatbot follows a rigid, deterministic workflow. You ask a question, it parses the intent and then guides you down a predefined workflow. Ask it why your system is running slow? It may tell you to close applications, check your network, reboot your machine, until it lands on the right solution. This process is predictable but tedious.

An agentic support assistant, on the other hand, can take a more intelligent approach. It could:

• Query multiple enterprise data sources (ServiceNow, Digital Experience Monitoring tools, Network Monitoring platforms, APM tools, etc.).
• Formulate a troubleshooting plan based on real-time data.
• Evaluate different potential causes and recommend the best resolution.

This would be a significant improvement in efficiency—but it also introduces a critical challenge: How does the AI agent authenticate and interact with these tools?

Enterprise tools have varying authentication and authorization methods. Our IT support assistant may require data from multiple sources. And yes, these sources all have APIs. But the method of integrating into these APIs are going to differ from product to product.

• ServiceNow supports multiple authentication flows, including OAuth2 for secure, delegated access.
• Cisco ThousandEyes, however, only supports bearer token authentication, requiring users to retrieve tokens manually.
• Microsoft Intune APIs can provide valuable insights for troubleshooting devices, but they require elevated permissions.

Why do these different products have different API authentication and authorization methods? Because they have different audiences in mind. ServiceNow is designed to be used by your employees to submit tickets and requests. But ThousandEyes and Intune are meant to be used by Network and Desktop Engineers, not individual users. Yes, you want your Agentic AI system to be able to play that role of L1 Network and Desktop Engineer. However, granting AI agents broad permissions to act in that role is a serious risk. Why? Because while you want your AI agent to perform some Network Engineering functions, you do not want your users to be able to perform those functions. But granting your AI agent access to these tools with the out-of-the-box permissions could open the door to prompt injection attacks, where a malicious actor manipulates the AI to retrieve sensitive data or execute unauthorized actions.

The Nightmare Scenario: AI Agents Executing Unauthorized Actions

Consider the following prompts:

• "Show me how often John Doe's device was active last week."
• "Retrieve the IP addresses of all routers in my company."

An average user should not have unrestricted access to another user's information, nor should they be able to footprint your network. However, if your AI agent has access to all this data and your prompt guardrails fail, this data could fall into the wrong hands.

Now imagine an AI agent with write permissions—capable of locking or wiping devices. If an attacker successfully manipulates the AI into executing an unauthorized command, the consequences could be devastating, leading to data breaches, service disruptions, or even enterprise-wide downtime.

Prompt Validation with tools such as AI Guardrails can help mitigate that threat, validating the inputs and outputs of LLMs against certain tests. But enterprises need to think in terms of defense in depth, and ensuring autonomous agents can't access unauthorized data through principals of least privilege.

How Enterprises Can Secure Agentic AI Systems

AI agents should only have access to the specific tools and data required for their role.  This required access may differ for different data sources.  For example, the authentication and authorization required for a vector database that contains general support documentation is different from the authorization to a system that contains Personal Information or sensitive enterprise information.  This is going to vary by tool and the use case for that tool.

For some tools, service-to-service authentication and authorization makes sense, such as for your general knowledge base in your vector database.  When adding tools that for accessing sensitive data or executing actions, more thought and likely more effort is required.  This will likely include:

1. Ensuring APIs support limited scopes so the agent can only retrieve data for the requesting user
2. Use delegated authentication where the AI operates on behalf of the user, inheriting their permissions.  This can be achieved with the OAuth 2.0 On-Behalf-Of token exchange.
3. This may require building custom APIs and wrappers that mediate access between the AI agent and enterprise APIs, ensuring controlled interactions.  The AI agent interacts with the custom API that supports least privilege access, and the API service only returns enterprise data authorized for the authenticated user.
4. Limit execution capabilities initially to limited, low-risk functions and data. Test and validate less risky interactions first before moving on to more risky ones.
5. Ensure there are manual Human-in-the-loop approval workflows for higher-risk actions.

MCP to the Rescue?

This is all easy to say; implementing these controls on a tool-by-tool basis will require architectural and engineering effort. Anthropic recognized the challenges of integrating tools for AI Agents and developed the Model Context Protocol (MCP). It promises to be a standardized interface for AI integration and has been gaining attention a lot of attention lately. However, current versions of MCP are designed for local integrations and do not yet support enterprise-grade authentication [yet].

As the MCP standard evolves, it may provide a more secure framework for managing AI interactions with enterprise tools. There is an ongoing and active discussion on how to incorporate enterprise level authentication and authorization into MCP, and we may see new versions of the protocol in the near future. And even if the protocol evolves, enterprise services will need to offer MCP servers or enterprises may need to build them themselves. And AI Engineers will need to ensure that their MCP servers are secure and connecting to their AI agents using the authentication and authorization methods appropriate for their use case.

Conclusion: A Secure Future for Agentic AI

Agentic AI systems have the potential to revolutionize enterprise operations, but they also introduce significant security risks if authentication and access controls are not properly implemented.

To ensure AI-driven automation remains secure, enterprises must:

• Enforce the principle of least privilege for AI agent access.
• Build delegated and scoped API endpoints for sensitive and privileged systems.
• Leverage Defense in Depth strategies for AI systems.
• Stay informed on emerging standards like MCP for future enterprise AI integrations.

As AI adoption accelerates, I imagine enterprise SaaS providers will also evolve as businesses demand that their tools can securely integrate with agentic AI systems.

These are my thoughts; however, I invite you to share yours in the comments! If there is anything I missed or you want to add, please let me know!