MCP for Enterprise AI: Building Secure Access to ERP Systems for AI Agents

 

A lot of companies want AI agents on day one.

We believe there is a more important step to solve first: how do you let an AI system safely interact with the software that actually runs your business?

An AI assistant that only answers questions is relatively easy to isolate. An AI agent is different. It may need to search projects, retrieve tickets, access customer information, log time, create records, or eventually execute entire business workflows.

At that point, the challenge is no longer just about LLMs or prompts.

It becomes an enterprise architecture, identity, and security problem.

At Onix, we faced exactly this challenge with Hydra Projects, our internal ERP. We wanted AI assistants such as Cursor and Claude — and eventually more autonomous AI agents — to interact with Hydra without creating a parallel AI infrastructure or bypassing the security model we had spent years building.

We solved it with the Model Context Protocol (MCP).

Today, Hydra MCP is running in production with 16 typed tools, existing JWT/OAuth authentication, automated tests, and access to both read and controlled write operations.

But the most important part of the architecture is not the number of tools.

It is this:

The AI acts with the identity and permissions of the person using it.

That design decision changes how we think about enterprise AI security.

 

Why Enterprise AI Agents Need More Than API Access

Enterprise systems already have APIs.

So why introduce MCP?

Because APIs and MCP solve related but different problems.

An API exposes application capabilities to software. MCP provides a standardized way for AI applications and agents to discover and use those capabilities as tools.

In our case, the architecture looks roughly like this:

Cursor / Claude / AI Agent → MCP → Existing Hydra API → Business Services → ERP

We did not replace our API.

We did not duplicate Hydra’s business logic.

And we did not build a separate “AI backend.”

Instead, we added MCP as a controlled interface on top of the architecture that already existed.

This distinction matters.

MCP doesn’t replace your API. It makes selected capabilities of your existing system usable by AI.

 

Why We Didn’t Build a Separate AI Backend

One possible approach was to create an independent MCP service — for example, in Node.js or Python — give it credentials, and let it communicate with Hydra through the API.

It would have worked.

But technically working and being a good production architecture are not the same thing.

A separate service would introduce another technology stack, another deployment pipeline, another authentication layer, and potentially another place where business rules could begin to diverge.

Instead, we integrated MCP directly into the existing Laravel API using the Laravel MCP package.

That allows MCP tools to reuse the same application services already used by the REST API.

If the rules for creating a worklog change, we don’t need to implement them twice.

REST and MCP use the same business layer.

The same principle applies to authentication, authorization, auditing, and permissions.

This gives us a much simpler architecture:

one product, one business layer, multiple interfaces.

 

The Most Important Security Decision: The Agent Inherits the User’s Identity

This was one of the most important architectural decisions we made.

A common shortcut when integrating AI with enterprise software is to give the AI system its own powerful API key or service account.

That is convenient.

It is also dangerous.

Imagine that an employee is allowed to view Project A but has no access to Project B.

If an AI assistant operates through a shared service account with access to both projects, the existing permission boundary has effectively disappeared.

We wanted the opposite behavior.

When a person uses an LLM or launches an AI agent, the request to Hydra is authenticated as that person.

The MCP layer preserves the user’s identity, and Hydra continues to apply its existing authorization rules.

In practical terms:

User → AI assistant/agent → MCP → user token → existing Hydra authorization → allowed operation

If the user can access something, their AI assistant can access it.

If the user cannot access it, their AI assistant cannot access it either.

And if an employee’s permissions change, the AI does not need a separate permission model to be updated.

The existing authorization layer remains the source of truth.

This is a much safer foundation for enterprise AI than giving an agent broad credentials and trying to recreate authorization rules somewhere else.

 

Authentication Is Not the Same as Authorization

This distinction becomes particularly important with AI agents.

Authentication answers:

Who is making this request?

Authorization answers:

What is this identity allowed to do?

Hydra already had both.

Our MCP implementation reuses the existing JwtGuard and Hydra Passport with the required hydra scope.

User tokens preserve the permissions of individual users.

Machine-to-machine tokens represent applications rather than people, so we deliberately treat them differently.

For example, write tools for worklogs are not registered for service tokens.

That means a machine identity cannot simply discover a sensitive tool and call it.

This implements the principle of least privilege at the tool level.

 

Read Access and Write Access Are Different Problems

Reading information through AI is useful.

Letting AI change production data requires another level of control.

Hydra MCP currently provides read operations for information such as:

• timesheet reports;
• clients and companies;
• products;
• departments and units;
• users;
• payment methods;
• projects;
• tickets.

But we also wanted AI to perform useful operations.

Hydra MCP therefore supports controlled write actions including:

• creating client agreements;
• creating product milestones;
• creating worklogs;
• updating worklogs;
• deleting worklogs.

For worklogs, the server still checks existing Hydra permissions such as timesheet and timesheet.own, overtime rules, and other business constraints.

The AI doesn’t bypass the application.

It uses the application.

 

We Designed MCP Tools for LLMs, Not for Swagger

There is another important difference between building an API and building tools for an AI agent.

An API endpoint is primarily designed for a developer.

An MCP tool is also being interpreted by a model.

That makes the tool description part of the product interface.

For write operations in Hydra, we describe the expected workflow directly to the model.

For example:

Search → Preview → User confirmation → Execute

If a developer says:

“HP20-4522, 3h today: feat + tests.”

the AI should not immediately write something into the ERP.

Instead, it can:

1. Find the appropriate project;
2. Find the ticket;
3. Prepare the proposed worklog;
4. Show a preview;
5. Ask the user to confirm;
6. Only then call the create-worklog tool.

The MCP server also provides server-level instructions describing the expected workflow.

This reduces ambiguity and makes incorrect production actions less likely.

We think of this as UX for AI.

Good MCP development is not just exposing functions.

It is designing an interface that helps a model understand how those functions should be used safely.

 

From One Read-Only Tool to 16 Production MCP Tools

We deliberately didn’t try to expose the entire ERP at once.

The first production MCP endpoint went live in February 2026.

It initially focused on timesheet reporting and OAuth discovery.

We then expanded the system iteratively.

CRM capabilities followed: searching clients, departments, and users, as well as creating agreements and milestones.

Timesheet analytics became more sophisticated.

Then we implemented a complete AI-assisted time-logging workflow:

search → preview → create/update/delete worklog

By June 2026, Hydra MCP had reached version 0.1.0 with:

16 typed MCP tools and 14 feature tests.

The important lesson was that enterprise MCP adoption doesn’t have to begin with an autonomous agent.

You can start with one high-value, low-risk operation and gradually increase what AI is allowed to do.

 

Why We Chose Streamable HTTP

Transport architecture also matters when an MCP proof of concept becomes a production service.

stdio is convenient for local development.

It was not the right architecture for our SaaS environment.

We chose Streamable HTTP using JSON-RPC 2.0 through the /mcp endpoint, hosted alongside the existing REST API.

That means MCP benefits from infrastructure we already operate:

• TLS;
• WAF;
• Rate limiting;
• Load balancing;
• Existing deployment and monitoring infrastructure.

An MCP client communicates with Hydra like another remote application rather than requiring a desktop-only bridge or separate infrastructure.

 

The Reality of MCP Authentication

MCP is developing quickly, and real clients do not always behave identically.

For example, during implementation we encountered differences in how clients such as Cursor handle OAuth registration.

Instead of designing exclusively for an idealized authentication flow, we implemented several practical connection paths.

Hydra supports:

Bearer token for a fast developer setup.

Static OAuth client with PKCE for persistent authenticated connections and refresh tokens.

And OAuth discovery endpoints for MCP clients that support OAuth-aware flows.

This is an important lesson from implementing MCP in production:

design for the protocol, but test against real clients.

A technically correct architecture isn’t enough if the actual AI tools your users rely on cannot connect to it reliably.

 

Production MCP Needs Production Engineering

We treat MCP code the same way we treat the rest of the application.

Hydra MCP currently has 14 dedicated feature tests.

The code passes the same PHPStan static analysis used by the production codebase.

And it goes through the same CI pipeline:

formatting → static analysis → parallel tests → deployment

This may sound obvious.

But there is a temptation to treat AI integrations as experiments indefinitely.

That becomes dangerous as soon as the AI can write to production systems.

Once an agent can change business data, the MCP layer should meet the same engineering standards as any other production interface.

 

What This Changes for Agentic AI

The broader lesson from Hydra is not really about MCP itself.

It is about the sequence in which enterprise AI should be built.

Many organizations start with the final vision:

“We need autonomous AI agents.”

We prefer to start with the infrastructure required to make autonomy safe.

Our sequence looks like this:

Controlled system access → reliable tools → identity and permissions → governed workflows → automation → agents

Each step makes the next one safer.

Once an AI system has reliable, permission-aware tools, you can begin combining them into workflows.

Those workflows can initially require human confirmation.

Later, selected operations can become more autonomous.

The important thing is that increasing autonomy does not require increasing privileges.

An agent should not become more powerful simply because it is an agent.

Its capabilities should remain bounded by identity, permissions, business rules, and explicit policies.

 

A Practical Framework for Enterprise MCP Integration

When we evaluate whether MCP makes sense for an existing product, we now ask several questions.

Do you already have a mature API and business layer?

If yes, we usually prefer integrating MCP with that architecture rather than creating a parallel AI backend.

How is identity managed today?

Whenever possible, we reuse the existing IdP, OAuth/OIDC/JWT infrastructure and permission system.

Who is performing the action?

If an agent acts on behalf of a person, preserving that person’s identity is preferable to hiding all users behind one powerful service account.

Which operations should AI be allowed to discover?

Read and write capabilities should not automatically receive the same treatment.

Where should human confirmation remain mandatory?

High-impact operations can use workflows such as preview → confirmation → execution.

Can the MCP layer meet the same engineering standards as the rest of the application?

That includes tests, observability, auditability, deployment processes, and security controls.

These questions are more important than the number of MCP tools you can expose.

 

MCP as a Foundation for Enterprise AI

Model Context Protocol is interesting because it helps solve one of the practical problems behind agentic AI:

How does an AI system interact with real software?

But MCP alone doesn’t make an enterprise integration secure.

The surrounding architecture does.

Our experience with Hydra led us to a relatively simple principle:

Don’t create a second security model for AI if your existing security model already works.

Reuse the API.

Reuse the business logic.

Reuse authentication.

Preserve the user’s identity.

Preserve permissions.

Expose only the tools the identity should be allowed to use.

And add autonomy gradually.

For Hydra, that means Cursor, Claude, and other MCP-compatible clients can interact with the ERP without receiving unrestricted access to it.

The LLM becomes another interface to the product — not a privileged shortcut around the product.

That, in our view, is the foundation for production-ready enterprise AI.

 

Building MCP for Your Product

If your company already operates an ERP, CRM, SaaS platform, healthcare system, financial application, or another API-driven product, you may not need to rebuild it to become AI-native.

The better architecture may be to make selected capabilities of the system safely available to AI assistants and agents through MCP.

At Onix, this is the approach we used with Hydra Projects:

existing API + existing business logic + existing authorization + MCP tools designed for AI.

The result is not another AI demo.

It is a production layer on which increasingly capable AI workflows and agents can be built.