How to test permission boundaries in banking AI agents

Banking AI agent permission boundary testing checks that an AI agent can access only the customers, accounts, data and operations authorised for its current identity and task. It verifies that permissions are enforced across the agent, its tools and connected banking services, including when requests are ambiguous, malicious or outside the user's authority.

What the permission boundary covers

An agent may interpret a request, retrieve information and call tools such as account lookup, payment initiation or beneficiary management. Each step can cross a different security boundary. Testing should establish which identity the agent acts for, which resources it can access, which actions it may perform and what conditions apply.

Conditions can include account ownership, customer consent, transaction limits, channel, purpose and approval status. A business banking user, for example, may be allowed to prepare a payment while a second authorised user must approve it. A permission check limited to the initial chat request would miss failures in a downstream tool call.

Authentication establishes who is using the service. Authorisation determines what that identity may do. Permission boundary tests focus on authorisation, while also checking that the authenticated identity and its context reach every relevant tool and service accurately.

Define the expected boundary before testing

Start with the bank's approved access rules and map them to agent actions and backend resources. Record the permitted and prohibited combinations, including any maker-checker or approval requirements. Treat the policy service or banking system that owns the permission decision as the authority; the language model's interpretation is not an access control.

Prepare isolated test identities and accounts with known entitlements. Include an entitled user, a user with similar but insufficient rights, and a user with no access to the target resource. Use synthetic or approved masked data, and keep payment execution disabled or routed to a controlled test service.

For each scenario, specify the expected result at the tool boundary as well as in the conversation. A polite refusal is insufficient if the agent has already retrieved restricted account details or submitted a transaction. Check for both unauthorised effects and information disclosure.

Exercise direct and indirect access paths

Test ordinary requests first, then vary the identity, resource and requested action. Include attempts to view another customer's balance, change a beneficiary, initiate a payment above a limit, or bypass a required approval. Verify that a denied request causes no backend state change and returns no protected data in the response, tool output, logs exposed to the user or later conversation context.

Test indirect paths as well as explicit requests. An agent might retrieve restricted information through a search tool, infer it from an error response, reuse another session's cached result or call a broader tool after a narrow tool denies access. Check that conversation memory, retrieval indexes and intermediate agent steps remain scoped to the same customer and identity.

Include hostile or misleading content in controlled tests, such as a document that instructs the agent to ignore access rules. This checks whether untrusted content can influence tool use. The expected control is server-side authorisation on each sensitive operation, even if the agent follows the instruction.

Practical example: payment preparation and approval

Suppose a corporate user can prepare payments up to the organisation's configured limit but cannot approve their own payment. Test the same agent workflow with a permitted payment and with a payment that exceeds the user's authority.

For the permitted case, verify that the payment is created in a pending state, is associated with the correct company and maker, and is routed to an eligible approver. For the denied case, verify that the payment tool rejects the action, no payment instruction or ledger effect is created, and the agent does not claim that the payment was submitted. Repeat with a second user who has approval rights, then verify that the required separation of duties still applies.

An assertion can express the central invariant: if the acting identity lacks permission for the requested operation, the operation has no effect and returns no unauthorised data. Check this against authoritative backend state, not solely the agent's final message.

Verify enforcement and evidence

Inspect tool requests and responses, authorisation decisions, audit events and relevant backend records. Confirm that each sensitive call carries the expected user, customer or organisation context. Review failures for fail-open behaviour, such as proceeding when an entitlement service times out, and for stale permissions after a role change or consent revocation.

Run scenarios across relevant channels and integrations where they share agent sessions or services. Record the identity, entitlement setup, prompt, tool call, policy decision, resulting state and evidence for each test. When prompts or models change, rerun boundary cases because agent behaviour can vary; backend access controls should continue to enforce the same policy independently of that variation.