Agentic AI Is Coming to Your Core. Set the Terms Before It Arrives.

The core vendors have moved

On 14 May 2026 Fiserv announced agentOS, an agent operating system that runs natively across its core and payments platforms with governance and audit controls built in. First Interstate Bank and Boulder Dam Credit Union are piloting it, six institutions are co-developing, and four initial Fiserv agents were announced: Commercial Loan Onboarding, Deposit Intelligence, AML Triage and Daily Operations. Fiserv's announcement pointed to wider availability later in 2026. We have not independently confirmed general availability, so treat the timing as unsettled when you plan around it.

We read that release as validation. We run all six Fiserv cores in real time, Fiserv-certified, and Fiserv's direction (agents inside the platform, governance and audit as first-class features) is the one we took in June 2025 when our first three AI Growth Agents went into production. Whether agents belong near the core is no longer the question.

The question is terms. Within twelve months a CIO at a credit union or community bank will be weighing agents from a core provider, a digital banking vendor and several fintechs, each with its own access model, audit trail and assistant. Cornerstone Advisors found in February 2026 that agentic AI is already discussed at board level in more than half of institutions and that more than 80% will increase technology spend this year. The budget exists. The terms do not.

Why this lands on the CIO, not the vendor

The regulators have said, in writing, that they are not yet writing the rulebook. The revised interagency Model Risk Management guidance (OCC Bulletin 2026-13, 17 April 2026) states that "generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance." For now, the standard your examiner applies to agents is the one you wrote yourselves.

Most institutions have not written one. CSI's 2026 Banking Priorities survey (February 2026) found 63% of organizations had no AI governance policy while 97% reported an AI-related security incident. The data underneath is not ready either: America's Credit Unions and PYMNTS Intelligence–Velera reported in August 2026 that only 11% of credit union leaders rate their data strategy "very effective" and 83% cite integration as the major obstacle. Agents do not fix integration; they multiply the things that need integrating.

Cornerstone's GonzoBanker research puts 69% of banks "somewhat or extremely likely" to stay with their existing core, and community banks told the OCC in its core-provider request for information (Banking Dive, April 2026) that negotiating leverage with core providers is "very uneven". You are going to stay with your core, which is fine. It means the terms get set at renewal, in an addendum or in an architecture review, not by switching.

We have sat on thirteen cores and watched every platform shift arrive the same way: the vendor ships the capability, the institution inherits the governance. This time, write the governance first.

Term 1 — Read-only until proven otherwise

Separate asking from acting. An agent that answers "which applications stalled at document upload last week" is reading. An agent that reopens the application, changes a status or moves money is writing. Different risk classes, different permissions, granted separately.

In the contract: every agent connection to core, origination or accountholder data is read-only by default. Write access is a distinct grant per agent per function, with a named business owner, a test plan and a rollback path, and it expires unless renewed.

In the architecture review: ask to see the credential the agent uses. If one service account can both read and write, "read-only" is a promise, not a control. Require a separate write path you can revoke without breaking reads.

MCP Connect v1.0 is read-only access to origination data. Writes to the core happen through certified integrations under the institution's configured rules, never through the agent layer.

Term 2 — Every query logged, seven years, reconstructable

An audit trail that records "agent ran" is a log. One that records who asked, what they asked, which data came back, when, and under which permission set is evidence. Your board will eventually ask about a specific date, and the answer needs to be a report.

In the contract: every agent query and its result set are logged with requesting identity (human and assistant), timestamp, scope of data returned and policy version in force. Retention is seven years. Logs are exportable and belong to the institution.

In the architecture review: pick a date six months back and ask the vendor to reconstruct what a specific agent could see and did see that day. If the answer requires a support ticket, the audit trail is not yours yet.

Every MCP Connect query is audited with seven-year retention, the standard we already apply to decision rules: every configuration change logged with what, who and when, reconstructable for any date.

Term 3 — PII masked by default; unmasking is a role, not a setting

Most agent questions do not need a Social Security number, a full account number or a date of birth. Default to masked, with the fields an agent can see defined by data class rather than by whatever the underlying table exposes.

In the contract: PII is masked by default in every agent response. Unmasking is a role assigned to named individuals through your identity provider, logged on every use and reviewed on the same cadence as privileged access to the core. No agent or assistant holds an unmasked role of its own.

In the architecture review: ask where masking happens. If it is applied in the assistant's prompt or the vendor's user interface, a different client can bypass it. Masking belongs in the access layer, before data leaves your perimeter.

MCP Connect masks PII by default; unmasking is a role. No member or customer data goes to public models, and our SOC 2 Type 2 (Security, Availability, Confidentiality) control status is published continuously at trust.cotribute.com.

Term 4 — Agents recommend; people act

Human-in-the-loop should be an architecture decision, not a policy sentence, because a policy sentence cannot stop an agent from calling an API.

An agent that says "these 214 members with maturing certificates match the money market offer" is recommending. A staff member who approves the campaign, or an institution-configured deterministic rule that releases it, is acting. Credit decisions, underwriting, pricing and adverse action stay in your core or LOS.

In the contract: agents produce recommendations into a queue; actions require approval by a named role or an institution-owned rule with logged configuration. No agent approves, declines or refers an application, and no vendor agent acts on member or customer accounts autonomously. Use those words.

In the architecture review: trace one recommendation end to end and find the approval step. If it is a timeout that defaults to yes, that is automation wearing a human-in-the-loop label.

Our three AI Growth Agents (acquisition, cross-sell, relationship growth) have run in production on this model since June 2025: they recommend, staff approve and act.

Term 5 — Your data, your assistant

The quietest lock-in is each vendor's agents speaking only to that vendor's assistant: a dozen agents, a dozen audit trails, and data that works inside one interface at a time.

The alternative is an open protocol. Put one Model Context Protocol (MCP) server in front of your origination data and Copilot, Claude or ChatGPT can each query it with the same permissions, masking and audit trail, regardless of which assistant asks.

In the contract: agent access to institution data is exposed through an open, documented protocol; the institution may connect any assistant it has approved; the vendor neither charges for assistant choice nor restricts it to its own product.

In the architecture review: count the access layers. The target is one governed layer every assistant reaches, not one per vendor, so ask each vendor whether its agents can consume your MCP server rather than opening their own connection to the core.

This is why MCP Connect is built on MCP rather than a proprietary assistant: governed, read-only, audited, PII-masked access to origination data from Copilot, Claude or ChatGPT. The Starter tier is included with AI Growth Agents.

Frequently asked questions