As AI adoption accelerates, many organisations are exploring ways to connect large language models (LLMs) to internal systems such as ticketing platforms, operational tooling, cloud environments, knowledge repositories and business applications.

An increasingly common approach is using the Model Context Protocol  (MCP) to provide controlled access to enterprise data and tools.

Recently, we conducted a security and governance review of an internally developed MCP-powered chatbot used by our teams. The goal wasn't to perform a compliance audit or penetration test, but to understand the security implications of connecting AI systems to operational business data and establish a repeatable review framework for future initiatives.

What we found was encouraging. The solution demonstrated a strong security foundation and highlighted several important lessons that are broadly applicable to any organisation considering AI-assisted access to business systems.

Why we performed the review

Traditional security reviews focus on applications, infrastructure and identities. AI-enabled solutions introduce a different set of questions. What data can the AI access? Could it retrieve information users shouldn't see? How are customer boundaries maintained? Are AI-specific risks such as prompt injection being considered? And who is accountable for the information returned by the AI?

These questions become increasingly important as organisations deploy copilots, AI agents, chatbots, Retrieval-Augmented Generation (RAG) solutions and MCP-enabled platforms. They also raise a broader question: how should new AI capabilities be governed over time?

The solution we reviewed

The solution consists of an AI-powered chatbot integrated with an internal MCP server. The server provides controlled access to several business systems and data sources through predefined tools and queries.

From a security perspective, several important controls were already built into its design:

• Internal-only access, with Entra ID authentication
• Read-only operation
• Fixed tool execution and predefined queries
• Audit logging
• Controlled access to approved business systems
• No arbitrary SQL execution or unrestricted backend access

This architecture immediately reduced many of the traditional risks associated with AI integrations.

What worked well

Several design characteristics aligned closely with recognised security principles.

Strong identity foundation:  The platform leveraged Entra ID authentication, ensuring only authorised users could access the solution.

Read-only design:  One of the strongest controls was the decision to keep the platform read-only. The AI could retrieve information but could not modify tickets, change customer environments, execute administrative actions or alter cloud resources. This significantly reduced the potential impact of misuse.

Controlled data access:  Rather than allowing the AI to construct arbitrary database queries, access was restricted to predefined tools and fixed queries. This reduced the risks associated with unrestricted data retrieval and backend system access.

Audit logging:  The platform logged tool usage and requests, providing a solid foundation for monitoring and investigation.

The findings weren't what we expected

Interestingly, the review uncovered very few traditional security concerns. Instead, most of the discussion focused on a different category of risk: AI governance and information visibility.

The biggest question wasn't, "Can someone break into this?" It was, "What becomes possible when AI can access and correlate information across multiple systems?"

This led us to identify four key areas for consideration.

1.  Data aggregation changes the risk model

In many organisations, information already exists across multiple approved systems, including ticketing platforms, customer portals, alerts and monitoring tools, billing systems and internal knowledge bases. Individually, these systems may be well controlled. However, AI introduces the ability to rapidly discover, correlate and summarise information across those sources.

For example, a user may previously have needed to manually gather information from multiple systems to understand a customer's operational status. With AI, that same information may be assembled through a single natural-language request.

This isn't necessarily a security problem, but it is a design consideration that should be consciously understood and accepted by business stakeholders.

2.  AI introduces new threat categories

Traditional security controls remain important, but AI-enabled platforms introduce new risks that organisations should test for. These include:

• Prompt injection:  Could content stored in a ticket, document or knowledge article influence how the AI behaves?
• Tool misuse:  Could the AI be persuaded to invoke unnecessary tools or retrieve excessive amounts of information?
• Customer enumeration:  Could users use the AI to discover or inventory large amounts of organisational information?
• Authority spoofing:  Would the AI trust a user claiming to be an administrator, executive or security approver? 

These risks aren't typically covered by traditional application security testing and require AI-specific validation.

3.  Auditability matters more than ever

One of the most important questions we asked during the review was, "Can every action performed through the AI be attributed to a specific user?"

As AI adoption increases, organisations need to be able to establish who asked a question, what tools were executed, what information was accessed and what response was generated. Strong auditability will become increasingly important for governance, investigations and compliance activities.

4.  Governance is more important than technology

Perhaps the most important lesson was that today's solution is not necessarily tomorrow's solution. The current implementation was read-only, which significantly reduced risk. However, future enhancements could include creating tickets, updating records, modifying cloud resources, running automation or executing operational tasks. These changes would dramatically alter the risk profile.

For that reason, we concluded that governance processes are just as important as technical controls. Every new capability, integration, tool or data source should be reviewed before it is introduced into production.

Building a repeatable review process

One of the most valuable outcomes of the review was creating a lightweight AI security and governance review process that can be applied to future initiatives.

The key areas of review include identity and authentication, authorisation and access control, data classification and handling, customer and tenant segregation, service identity management, AI-specific security risks, logging and auditability, and governance and change management.

The objective is not to slow innovation, but to ensure AI-enabled solutions are deployed securely, responsibly and with strong governance.

Final thoughts

AI-powered solutions are rapidly moving from experimentation into day-to-day business operations. As a result, organisations need to expand their security thinking beyond traditional application and infrastructure risks.

Our review found that the MCP solution demonstrated a solid security foundation and a manageable risk profile. The main lessons were less about technical vulnerabilities and more about governance, visibility, auditability and understanding how AI changes the way information is accessed and consumed.

For organisations beginning their AI journey, one of the best investments is establishing a repeatable review process early. The technologies will change rapidly, but the principles of security, accountability and governance remain constant.

If you’re working through what AI governance should look like in practice, our team can help you make sense of the technology, risks and operational considerations involved.  Talk to us about where to start  >