Legacy Modernization Should Decide Which Functions AI Agents Call

AI agents need access to business systems to be useful. A customer service agent needs order status and account details. A claims agent needs policy data and claims history. A finance agent needs ledger balances and invoice records. In many organizations, that information lives in legacy systems: mainframes, older ERP platforms, and custom applications built decades ago. 

Rewriting those systems before agents can use them would take years. So a faster pattern has emerged. Teams wrap existing legacy functions as tools, often using the Model Context Protocol, and let agents call them directly. The approach is practical and increasingly standard advice. 

It also carries risks that are easy to overlook. Legacy functions were designed for trained staff working through screens, or for scheduled batch jobs with predictable volumes. AI agents behave differently. They may call functions far more often, in unusual sequences, with unexpected inputs, and with less human judgment in the loop. Legacy modernization services should decide which functions agents may call, and how, before exposing any of them. 

MCP Has Made Exposure Easy 

In December 2025, Anthropic donated the Model Context Protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation. This move places the protocol under neutral, community governance. MCP standardizes how AI applications connect to tools and data, so a single connector can serve many agents and models. 

Neutral governance and broad support make MCP an attractive way to expose legacy functions. A team can build an MCP server that wraps a mainframe transaction, a stored procedure, or a legacy API, and any compliant agent can use it. That ease is exactly why governance matters. Exposure that takes days to build can create risk that takes months to discover. 

Why Legacy Functions Need Special Care 

Legacy systems carry assumptions that agents can break: 

• Human pacing: Screens and transactions were designed for people entering a few requests per minute, not machines issuing hundreds per second. 

• Implicit validation: Operators knew which inputs made sense; functions may accept values that a trained user would never enter. 

• Side effects: A function that looks like a lookup may update a timestamp, lock a record, or trigger a downstream job. 

• Batch windows: Some functions are safe only outside nightly processing, or compete with batch jobs for resources. 

• Capacity limits: Mainframe capacity is often priced by usage, so unexpected volume raises costs directly. 

• Coarse permissions: Older systems may grant broad access through a single service account. 

• Limited logging: Records may show that a transaction ran, but not which agent or user requested it. 

Exposing such functions without analysis can lead to performance problems, data integrity issues, security gaps, and unexpected bills. Documentation for older functions is often incomplete, so the safest assumption is that any function may have behavior nobody has written down until analysis or testing proves otherwise. 

What OWASP Recommends 

The OWASP Gen AI Security Project lists excessive agency among the top risks for LLM applications. It recommends limiting the extensions that agents are allowed to call to the minimum necessary, limiting the permissions those extensions hold in other systems, and using human-in-the-loop control to require approval for high-impact actions. 

Those principles map directly onto legacy functions. Every function exposed to an agent is an extension. Every service account behind it is a permission. Every update, payment, or account change is a potentially high-impact action. 

A Classification Framework for Legacy Modernization Services 

Legacy modernization services should classify each candidate function before it becomes an agent tool: 

1. Read-only, low sensitivity: Lookups of non-sensitive reference data, such as product catalogs or branch hours. Suitable for agent access with rate limit

2. Read-only, sensitive: Lookups of personal, financial, or health data. Agent access only with user-level authorization, data minimization, and logging. 

3. Low-impact writes: Updates that are easily reversed, such as adding a note or setting a preference. Agent access with validation, limits, and audit trails. 

4. High-impact writes: Payments, account changes, policy changes, orders, or anything hard to reverse. Human approval required, or no agent access. 

5. Unsafe for agents: Functions with hidden side effects, batch conflicts, or no reliable validation. Not exposed until modernized. 

The default should be the most restrictive category that still meets the use case. Most early agent use cases need only read access. Starting there lets teams learn how agents behave against real systems before granting any ability to change data. 

Controls for Every Exposed Function 

Each function exposed to agents should have: 

• Scoped identity: Calls made on behalf of a specific user or agent identity, not a shared super-user account 

• Rate limits and quotas: Caps per agent, per user, and in total, tuned to the legacy system's capacity 

• Input validation: Checks in the wrapper that enforce valid formats, ranges, and combinations 

• Timeouts and circuit breakers: Protection against slow responses and cascading failures 

• Audit trails: Logs recording which agent, which user, which function, which inputs, and which result 

• Monitoring: Alerts on unusual volume, error rates, or access patterns 

• Kill switch: The ability to disable agent access to a function quickly 

These controls sit in the wrapper or gateway layer, so the legacy system itself does not need to change. Centralizing them in one gateway also gives security teams a single place to review policies, adjust limits, and investigate incidents. 

A Worked Example 

Consider an insurer wanting a service agent to answer policyholder questions and handle simple changes. Its policy administration system runs on a mainframe with hundreds of transactions. 

The legacy modernization team reviews 40 candidate transactions. Policy lookups, coverage summaries, and payment history are classified as read-only sensitive data and exposed through MCP with user-level authorization and rate limits. Address changes are classified as low-impact writes, exposed with validation and confirmation messages to the customer. Coverage changes and cancellations are classified as high-impact; the agent can prepare a request, but a human approves it. Two transactions that appear to be lookups are found to lock policy records during processing; they are marked unsafe for agents and scheduled for modernization. 

The agent launches with clear limits. Mainframe usage stays within forecast, audit logs satisfy compliance review, and the team expands agent access over time as each function proves stable. 

Legacy Application Modernization With Agents in Mind 

Exposing functions to agents also informs broader legacy application modernization. Usage data from agent calls shows which functions matter most. Functions marked unsafe for agents become priority candidates for rebuilding. Wrappers designed with clean interfaces and validation can become the foundation of future services, so that legacy software modernization proceeds function by function rather than as one large replacement. 

Legacy modernization solutions that combine agent enablement with modernization planning avoid two extremes: blocking agents until a full rewrite is complete, or exposing everything without understanding the consequences. 

Choosing Legacy Modernization Solutions and Providers 

When evaluating legacy software modernization services or legacy application modernization services for agent enablement, ask: 

• How do you classify legacy functions before exposing them to agents? 

• How do you detect hidden side effects and batch conflicts? 

• What identity, rate limiting, and logging controls do your wrappers include? 

• How do you protect mainframe capacity and cost? 

• Which actions require human approval? 

• How does agent usage data feed into the modernization roadmap? 

Providers that answer with a classification process and specific controls are protecting core systems. Providers that offer only fast connector development may be creating risk the client inherits. 

Mainframe Cost and Capacity Planning 

Agent traffic changes the cost profile of legacy platforms. Many mainframe environments are billed on consumption, so a popular agent that calls a policy lookup thousands of times an hour can raise monthly costs noticeably. Before launch, estimate expected calls per function, peak rates, and the processing cost of each transaction. Where volumes are high, consider caching read-only results for short periods, replicating frequently used data to a modern store, or offering summarized data instead of raw transactions. These choices protect both performance for human users and the budget. 

Capacity planning should also account for batch schedules. Agent calls that compete with nightly processing can delay critical jobs. Wrappers can enforce time windows, returning a polite "try again later" message or a cached result during batch periods. 

Governance Over Time 

Classification is not a one-time exercise. New agent use cases will request access to more functions, and legacy systems will change. Establish a review board, including system owners, security, and business representatives, that approves new tool exposures and reviews usage reports. Re-classify functions when their behavior or the data they touch changes. Retire tool access that agents no longer use, since unused exposure adds risk without value. Legacy modernization solutions that include this governance keep agent access aligned with risk as adoption grows. 

Testing Before Agents Go Live 

Before agents call legacy functions in production, test with realistic agent behavior: high volumes, retries, unusual inputs, and sequences that combine several functions. Load test the wrappers and the legacy system together. Run red team exercises in which testers try to make the agent misuse functions through prompt injection or confusing requests. Confirm that rate limits, validation, and approval steps work as intended. Tests should run in an environment that mirrors production capacity and batch schedules, since many legacy problems appear only under real timing. 

AI agents can draw value from legacy systems quickly, but those systems were never designed for unpredictable machine callers. Legacy modernization services should classify every function before exposing it, default to read-only access, and apply identity, rate limits, validation, audit trails, and human approval where needed. Find legacy modernization services that enable AI agents on core systems with controls built into every exposed function. Agents should reach the data they need, and nothing they should not.