Restrict agents to the authenticated customer and relevant accounts.
The session defines the boundary: the agent serves the customer in front of it and cannot browse the broader book.
Control agents across accounts, lending, payments, branch operations, and customer service.
Banking agents may retrieve account information, investigate transactions, collect loan documents, recommend products, or initiate operational changes. These workflows require precise distinctions between viewing, recommending, initiating, and approving.
Initiating and approving are separate acts. The second one belongs to a person.
Is the account the one in this session?
continues ↓An unrelated customer’s account
The session sets the boundary. Stopped inside Fabriq — the core is never called.Reading, or moving money?
continues ↓Read this customer’s balances and recent transactions
Inside the amount, destination and channel limits?
continues ↓A transfer past the ceiling set for this manager
Limits are read per transaction, so the payment is never prepared, let alone sent.Initiation ends here. Release belongs to a second person with the authority to give it — four eyes, kept by the grant rather than by habit.
RELEASED BYExample instruction. The sessions, ceilings and release rights are the ones you set.
The session defines the boundary: the agent serves the customer in front of it and cannot browse the broader book.
Reach is an action-and-resource grant, so an agent can prepare a payment on an allow-listed account and have no route to any other.
The release action is left out of every agent’s grant, so the four-eyes principle automation tends to erode holds by construction.
Lending agents gather, validate, and summarize; credit decisions stay with authorized underwriters and approved models.
An action adverse to a customer is granted to the staff who hold that authority and to no agent, so it is not in the tool list an agent receives.
Every account action carries its full context, ready for supervisor review or a customer dispute.
Explore the context attached to every request.
banking-agent has a defined purpose and a bounded set of tools.
The request acts for account manager, using that person’s permissions.
The policy applies to the requested action within Account system, before the tool executes.
Access follows the authenticated session, so the agent reads the caller’s accounts and nothing else.
The agent accelerates the file; the credit decision remains with underwriters, enforced by role rather than convention.
Per-case access keeps investigations separate and clean, with no bleed between customers under review.
Payment preparation runs on the accounts the desk can reach, and the release action belongs to authorized staff rather than to the agent.
The branch employee’s own permissions cap what the assistant can do, teller to manager alike.
Yes. Fabriq sits between agents and the cores, CRMs, and payment rails you already operate. The systems themselves are untouched; every agent action against them is checked against the agent’s grant and the acting employee’s own authority first.
Access is tied to the authenticated customer session. The agent reads that customer’s accounts and history for the duration of the interaction, and its reach ends when the session does — there is no standing credential that spans the book.
One trail across every agent and system: who asked, which agent acted, what it touched, and the verdict — filterable and exportable for your review.
Yes — both at once. Reach resolves from the acting employee’s authority and the authenticated customer’s session together, so a branch assistant, a payment agent, and a service copilot each operate within exactly the boundaries that pairing allows.
Yes — Okta and OIDC-compatible providers plug straight in, so bankers use the access they already have and agents operate under those identities.
Yes — grant the reads and leave account changes and release out, per employee and per action. What an agent was not granted never appears in the tool list it is handed.