Oracle Integration MCP Gateway 26.10 Explained

Quick answer

Oracle Integration MCP Gateway, delivered in the 26.10 release (September 2026), is one governed endpoint between MCP clients (your AI agents) and MCP servers. Instead of every agent holding its own credentials and seeing every tool, the gateway centralises identity, tool filtering, policy checks, credential resolution, routing and audit. Oracle positions this as the first iteration, so pilot it deliberately rather than switching it on for production agents on day one.

Key facts

• Released in Oracle Integration 26.10 (September 2026). Oracle describes it as the first iteration of the gateway.
• It is part of Oracle Integration, not a separate product.
• MCP clients connect to a single gateway endpoint. The gateway routes approved requests to OIC MCP servers or approved third-party MCP servers.
• Tool filters control which tools a client can discover and invoke.
• Policies can be applied at the gateway, MCP server or individual tool level. Oracle’s demo covers tool filter, PII and business rule policies.
• Agents do not need direct access to downstream credentials. The gateway resolves them through controlled stores.
• Request activity, tool usage, outcomes, policy decisions and health signals can be captured for audit and troubleshooting.
• Existing OIC integrations can be converted into MCP tools and exposed through an OIC MCP server.

The problem the gateway is solving

If you have wired an AI agent to an enterprise system in the last year, you have probably made the same shortcut everyone makes: give the agent a connection to the MCP server, hand it a credential, and let it discover whatever tools the server exposes. That works in a demo. It does not survive a security review.

Once you have three agents and five MCP servers, the problems stack up quickly:

• Every MCP server has its own identity and authorisation approach.
• Credentials end up spread across agent implementations.
• Agents can see more tools than they need.
• Security and business rules are applied inconsistently, or not at all.
• Nobody can answer the question: which agent called which tool, with what outcome?

The MCP Gateway is Oracle’s answer: one control point in front of all of it.

What the gateway does on every request

When an MCP client sends a request through the gateway, the interaction is governed end to end:

• Authenticate and authorise: establish who or what is calling (agent, user or service) and decide whether access is permitted.
• Expose only approved tools: tool filters ensure clients discover and invoke only explicitly approved tools.
• Apply policies: security and business policies can be evaluated before the request reaches the downstream server and, where applicable, on the response coming back.
• Resolve credentials: the gateway fetches the downstream credentials from controlled stores, so the agent never holds them.
• Route: approved requests go to the right OIC MCP server or approved third-party MCP server.
• Record: request activity, tool usage, outcomes, policy decisions and health signals are captured for operations and audit.

The practical value is least privilege. Oracle’s own example: an operations agent may use diagnostic tools but not tools that change production, and a customer-service agent may read customer information but route sensitive actions to a person for review.

The setup flow, step by step

Oracle’s demo shows the sequence below. Treat it as the order of work for a pilot:

• Convert integrations to MCP tools and enable the OIC MCP server.
• Register MCP servers: your OIC-enabled server and any third-party MCP server. Multiple servers can sit behind one gateway.
• Create a tool filter policy so only approved tools are exposed.
• Create a PII policy to protect sensitive data on the request and response path.
• Create a business policy using business rules, to protect downstream systems from malformed, incomplete, hallucinated or non-compliant requests.
• Create the MCP gateway.
• Configure the gateway endpoint in the MCP client, so the client discovers approved tools through that one endpoint.
• Test with sample queries that cross domains, for example CRM lookup plus ERP check.
• Review audit and monitoring output for client requests, policy evaluation, tool invocation, response handling and downstream outcomes.

The business policy step is the one I would spend the most time on. A tool filter tells you what an agent can call. A business rule tells you whether this specific call, with these specific values, should be allowed. That is where hallucinated customer IDs and half-formed payloads get stopped.

Where it fits in the wider 26.10 release

The gateway is the headline, but 26.10 has other changes that matter for agent-driven work:

• Knowledge Base custom metadata: you can restrict retrieval by customer, account, document type, date, region, product or access segment before chunks are retrieved, which reduces irrelevant candidates and improves answer accuracy.
• Human in the Loop: 26.10 adds the ability to publish Human in the Loop logs to Oracle Log Analytics, which helps with audit of approval steps.
• Move to project: when you move an integration from the global space into a project, the existing global space endpoint is preserved, so consumers do not break.
• File Server: AES-128-GCM and AES-256-GCM ciphers are now supported for SFTP transfers, useful where partners are moving away from AES-CTR.
• Adapters: new security policies across several adapters, and expanded private endpoint support.

What to validate before you expose it to real agents

Because this is a first iteration, the right posture is verify, then trust. These are the questions I would answer in a non-production tenant first. They are not claims about the product. They are the gaps between the announcement and a production design:

• Which authentication mechanisms are supported for the MCP clients calling the gateway, and how do they map to your IdP?
• When policies exist at gateway, server and tool level, what is the evaluation order and what wins on conflict?
• Do PII and business policies apply on both request and response paths for every server type, including third-party servers?
• Where does the audit data live, how long is it retained, and can it be exported to your SIEM or Log Analytics?
• What happens to an agent call when a downstream MCP server is unhealthy or slow?
• Which regions, editions and OIC instance types have the feature enabled today?

Check the 26.10 release notes and the Using Agentic AI in Oracle Integration 3 documentation for the current answers, because this area will move fast.

Common mistakes to avoid

Exposing a whole MCP server instead of selected tools

• Why it hurts: the agent can discover and call tools it was never meant to use.
• Fix: start from an empty allow list and add tools one by one with a tool filter policy.

Leaving credentials inside the agent

• Why it hurts: credentials spread across agent code and configuration, and rotation becomes a project.
• Fix: let the gateway resolve downstream credentials from controlled stores.

Only applying policy at the gateway level

• Why it hurts: a read tool and a write tool on the same server need different rules.
• Fix: apply stricter policies at the individual tool level for anything that changes data.

Skipping a human step for write actions

• Why it hurts: an agent that is wrong 2 percent of the time is still wrong on real invoices.
• Fix: route sensitive or irreversible actions through Human in the Loop approval.

Never reviewing the audit trail

• Why it hurts: policy decisions and failed calls are your early warning system, and nobody is reading them.
• Fix: schedule a weekly review of denied requests and policy hits during the pilot.

Best practices for a first rollout

• Pilot with one low-risk, read-only use case before any write tools.
• Keep one gateway per trust boundary, not one gateway for everything.
• Write business rules from real failure cases, not from imagination.
• Convert existing, well-tested integrations to MCP tools rather than building new ones for agents.
• Document who owns each tool, each policy and each credential store.
• Plan for iteration: this is a first release, so pin down your test cases and re-run them after every OIC release.

What this means for OIC consultants

My view as a practitioner: the integration skill set is moving from connecting systems to governing how automated callers reach them. Consultants who can design tool exposure, write policy, reason about credentials and explain audit trails to a security team will be the ones leading agent projects, because those are the questions every client asks after the demo.

If you are building this skill set, pair your OIC fundamentals (integrations, projects, adapters, fault handling) with identity and API security basics. For market context, see the OIC consultant salary data and interview experiences on Lanverse. [LINK: OIC salary page] [LINK: OIC interview experiences]

Interview questions you may now be asked

1. What problem does an MCP gateway solve that direct MCP server access does not? It centralises identity, tool access, policy, credentials and audit in one place, instead of repeating them in every agent and every server.

2. How would you stop an agent from calling a tool it should not use? Use a tool filter policy so only explicitly approved tools are discoverable and callable, and apply stricter policies at the individual tool level for anything that modifies data.

3. Why should an agent not hold downstream credentials? Because credentials spread across agent implementations are hard to rotate and audit. The gateway can resolve them through controlled stores instead.

4. How do business policies differ from PII policies? PII policies protect sensitive data on the request and response path. Business policies use rules to reject malformed, incomplete, hallucinated or non-compliant requests before they reach a downstream system.

5. How would you take an existing OIC integration and make it available to an agent? Convert the integration into an MCP tool, enable the OIC MCP server, register it behind the gateway, then expose it through a tool filter and policies.

FAQ

What is Oracle Integration MCP Gateway? It is a feature of Oracle Integration that gives MCP clients, such as AI agents, one governed endpoint to reach OIC MCP servers and approved third-party MCP servers, with centralised identity, policy, credential, enforcement and observability controls.

Which release introduced it? Oracle Integration 26.10, September 2026.

Does it only work with Oracle-hosted MCP servers? No. Oracle describes routing to both OIC MCP servers and approved third-party MCP servers.

Do agents need the credentials of downstream systems? No. The gateway can resolve downstream credentials through controlled stores.

Can I limit which tools an agent sees? Yes. Tool filter policies expose only approved tools to MCP clients.

Is it ready for production? Oracle presents this as the first iteration of the gateway. Pilot it in a non-production environment, validate the behaviours listed above, and then expand.

Closing

Agents are only as safe as the access you give them. The MCP Gateway does not make an agent smarter, but it makes the access around it explainable, restrictable and auditable, which is what enterprises need before they let agents near ERP and CRM data. If you work on OIC, get a pilot running now. The consultants who understand this layer early will be the ones answering the client’s hardest question: how do we keep this under control?