How to give an AI agent safe access to your core banking system

Never connect the agent to the core directly. Put a service layer in front that exposes named capabilities, each with a depth, and scope every read to the customer in the current authenticated case. Protective holds can run; contact changes, transfers and fee refunds run within bounds; closures, product changes and manual postings stay with people.

What does safe access mean, and who owns it?

A core banking system is the bank's book of record: customers, accounts, balances, transactions, interest, fees. Many cores were built long before agents and grant permissions in coarse blocks: a user can see all customers or none, post to all ledgers or none. Giving an agent a core user profile hands it far more than any task needs.

The head of banking operations approves each capability. The core platform owner owns the service layer. Information security owns the agent's identity and grants. Fraud owns hold rules on changes that are known takeover routes. For the wider frame, see our guide to AI agents in banking.

Which permissions should you grant, and at what depth?

Changing customer records is covered in its own playbook: letting an AI agent update customer records in your core banking system. Access resets are a known takeover route, discussed in whether an AI agent can reset online banking access.

How do you set it up, step by step?

1. Person, head of banking operations: approves the capability list. Evidence: approved list with depths.
2. Core platform team: builds a service layer. One endpoint per capability, translating to the core's own transactions. The agent never calls the core directly. Evidence: endpoint list mapped to core transactions.
3. Information security: gives the agent its own identity. Not a teller's profile, not a batch user. The method is set out in giving an AI agent its own identity in your access management system. Evidence: identity and grants.
4. Core platform team: scopes reads to the case. Each call carries the case reference; the service layer returns data only for the customer linked to that case after authentication. Evidence: refused calls for other customers.
5. Person, fraud: sets hold rules for changes. Contact detail changes shortly after a new device login, changes followed by a payment to a new payee, changes to both phone and email in one session. Evidence: rules as versioned bounds.
6. Platform, on each call: checks the minimum chain. Evidence: verdict per call.
7. Core platform team: respects processing windows. During end-of-day or batch runs, changes queue or are refused, never half-applied. Evidence: verdicts naming the window.
8. Information security: wires revocation per capability and for the identity as a whole. Evidence: drill results.

Which controls matter, and what is recorded?

Case-scoped reads. The agent cannot browse. It sees one customer, for one case, after authentication. Evidence: the case reference on every read.

Protective actions are easy; reversing them is not. The agent may place a hold the moment it sees a reason; only a person lifts one. Evidence: refused verdicts on lift attempts.

Takeover patterns held. Most account takeovers involve changing contact details before moving money. Evidence: held verdicts naming the rule.

No ledger postings. Manual journals are how errors and frauds are hidden. Withhold them for every agent. Evidence: withheld verdicts on any attempt.

Running limits. Transfers and fee refunds count against daily and per-customer totals that include people's actions. Evidence: totals on each verdict.

Open banking is a separate route. Reading a customer's accounts at other banks with their consent is a different access path with its own rules; see whether an AI agent can access a customer's account through open banking. Evidence: separate capability and consent record.

What should you measure?

• Calls per capability and verdict mix.
• Reads refused for scope. Any is worth a look; many suggest the agent is reaching beyond its case.
• Held contact changes confirmed as takeover attempts.
• Protective holds placed by the agent and later confirmed or lifted.
• Queued or refused calls during processing windows.
• Transfers between own accounts by value, against the customer's limits, to check the bounds sit where customers need them.

Where does it usually go wrong?

A teller profile is cloned for the agent. It gets every customer and every transaction a branch user has.

Reads are treated as harmless. An agent with unscoped read access can be talked into describing another customer's account. Scope by case.

Contact changes run unchecked. They look routine and are the first step of most takeovers.

The service layer leaks. A generic "update customer" endpoint lets the agent change fields nobody approved. One field group per capability.

Batch windows are ignored. A change applied mid-batch leaves the record inconsistent.