Banking AI Agents Need OAuth Identity to Stop Prompt Injection

A malicious prompt is hidden inside a customer email. The AI agent reads it, bypasses the intended workflow, and calls the core banking API directly, updating a corporate record without human approval. The audit log shows it happened. It does not show which agent did it, who authorized it, or that no one did. The core banking API doesn’t do any validation whether the request has required scope to call it, nor whether the token was even intended for it as the audience.

A practical fix with an existing standard, and likely, infrastructure most enterprises already have: use OAuth 2.0 to give each AI agent its own identity — so permissions are enforced at the API layer, and every action is auditable.

The Scenario: Corporate Name Change

To understand the gap, consider a scenario that many banks in Singapore handle regularly. A corporate customer wants to update their company name following a company name change. The customer emails the required documents — including the ACRA BizFile certificate — to their bank’s customer service representative.

The bank has deployed a Gen AI system to assist the customer service representative with such requests. When the email is forwarded to the system, three AI agents are involved:

1. A reasoning agent reads the email and detects the intent — “corporate name change request.” It decides which downstream agents to call. It doesn’t access customer records or documents; it only classifies and routes.
2. A document parsing agent extracts the key fields from the ACRA certificate — old name, new name, UEN, effective date — and produces a structured form for the officer to review against the original. No human approval needed here.
3. An account update agent applies the change to the corporate account in core banking. This one is different — it modifies a legal entity record, so the customer service officer must review the form, verify it against the ACRA certificate, and explicitly authorize the update before the agent can execute.

Let’s consider what happens when all three agents share a single service account, which is the default in most AI agent frameworks today. The reasoning agent, the document parser, and the account update agent all call backend APIs using the same credential. If the document parser is fed a forged ACRA certificate and produces incorrect values, and the officer approves the update based on the parser’s output without checking the original document, and the update agent executes the change — your audit log shows a single service account modified a corporate record. You cannot tell which agent made the decision, which agent parsed the document, and which human approved the update.

There is a more direct attack. A malicious prompt is injected into the incoming email — invisible to the customer service officer but interpreted by the reasoning agent. Instead of routing the request through the document parser and human review, the agent is instructed to call the account update API directly. Because all three agents share the same service account — and that account has permission to call every backend API — the request succeeds. The intended workflow is bypassed entirely, not because the attacker defeated a security control, but because no security control existed at the identity layer. The permission boundary between agents was enforced only in application logic, which prompt injection is designed to subvert.

With agent identity, this attack fails at the infrastructure level. The reasoning agent’s token only carries classification and routing scopes — it has no permission to call the account update API. Even if the prompt injection manipulates the agent’s behavior, the API gateway rejects the request. The permission boundary is enforced by OAuth, not by application code.

What MAS Is Saying About AI Agents

On 13 November 2025, the Monetary Authority of Singapore published its Consultation Paper on Guidelines on AI Risk Management (AIRG). In it, MAS explicitly names AI agents as a risk category:

“The use of AI agents that leverage Generative AI with greater autonomy and the ability to access tools could introduce significant risks. An AI agent granted access to an FI’s internal systems might autonomously execute actions misaligned with business objectives or customer interests, while compromised AI agents could exfiltrate sensitive data or execute malicious commands.”

The AIRG sets supervisory expectations that financial institutions must implement within 12 months of finalization, including:

• AI inventories: maintain an accurate, up-to-date registry of all AI systems in use
• Risk materiality assessments: factoring the level of autonomy and the degree of human oversight
• Auditability: the ability to trace AI-driven actions back to specific systems and authorization decisions
• Post-deployment monitoring: continuous oversight, not just pre-launch reviews

What Changes

Once each agent has its own identity, three things are different.

Permissions are enforced by infrastructure, not code. The reasoning agent’s token doesn’t carry the scope to call core banking — so even if prompt injection tells it to, the gateway says no.

Sensitive actions require a real person to approve. The resulting token carries both the officer’s identity and the agent’s identity. Not one or the other — both.

Logs tell you what actually happened. Not “a service account modified a record.” You get which agent, which human, which scope, which API. That’s the difference between a three-day investigation and a five-minute lookup.

The difference is visible in the token itself. Here’s what the core banking API sees today when the account update agent calls it:

{
  "sub": "svc-ai-platform",
  "aud": "core-banking-api",
  "scope": "read_documents update_corporate_records read_customer_data classify_requests"
}

One service account. All the scopes, for all the agents, bundled into one token. The reasoning agent carries this same token. So does the document parser. If any of them calls any API, the request goes through — the token is valid for everything.

Now here’s what the same API call looks like with agent identity and OBO (On-Behalf-Of):

{
  "sub": "951e42a5-...",          // Chris — the officer who approved
  "act": {
    "sub": "a83f2b01-..."        // account-update-agent
  },
  "aud": "7f2c4d91-...",         // core-banking-api
  "scope": "update_corporate_records"
}

sub is Chris — the officer who reviewed the ACRA certificate and approved the update. act.sub is the account update agent — the one that actually executed it. aud is the core banking API — this token doesn’t work anywhere else. scope is just update_corporate_records — nothing more.

If the reasoning agent gets compromised by prompt injection and tries to call the core banking API, it fails on three counts: wrong agent identity, no human authorization, wrong scope. The gateway doesn’t care what the LLM was told to do. It reads the token, and the token says no.

They also map directly to what the regulator already requires:

If your AI agents are calling APIs with a shared service account today, the gap is already there — and the 12-month AIRG compliance clock is already running.

In Part 2, I go deeper into the architecture — how the token delegation works across agents, where RFC 8693 falls short across Identity Providers, and how to work around it.