The Short Answer
AWS open-sourced TOLAP — the Tool-Object Level Access Protocol — on 22 September 2026 under Apache-2.0, enforcing row filtering and column masking inside agent tools before data reaches the model. NVIDIA's 2026 survey of more than 800 financial professionals found 21% have already deployed AI agents. Authorization, not capability, is what makes a money-moving agent shippable in a regulated firm. With ibl.ai you own all the code and the data.
An agent that can call a tool is a demo. An agent that can call a tool and see only the rows its caller is entitled to is a production system.
What did AWS actually open-source on 22 September 2026?
A protocol and three reference implementations for object-level access control inside agent tools, published on the AWS Open Source Blog.
TOLAP — Tool-Object Level Access Protocol is released under Apache-2.0 at github.com/awslabs/tolap.
It ships SDKs in .NET, Python and TypeScript, a reference policy server with an authoring console, and fourteen integrations across agent frameworks including the MCP SDK, LangChain, Bedrock Agents and Semantic Kernel.
The policy model is one schema over four source categories — databases, APIs, knowledge bases and object storage — in three layers: the policy definition, the assignment binding it to a user or group with scope and expiry, and the merged effective policy.
What it enforces is deliberately mundane: row filtering, hidden columns, per-field masking, result limits, tag filters on knowledge bases, endpoint restriction on APIs, and prefix allow or deny on object storage.
The important word is where. AWS puts it this way: "Policy is applied where the data originates, not in a layer above it." So restricted data never enters the agent's context at all.
Why can't IAM roles give an AI agent row-level permissions?
Because role-based access control grants a connection, and the agent composes the query behind it.
AWS states the gap plainly: role-based access control cannot specify which columns or rows are visible; attribute-based access control needs centralized routing that agents bypass when a tool holds a direct database connection.
That is the structural problem. A tool authenticates once with a service credential, then answers whatever the model asks. Ask for a column the application layer never anticipated, and the column comes back.
Content guardrails are the usual patch, and they run too late. Once unrestricted data is in the context window it is, in AWS's wording, "fair game for summarization, reasoning, follow-up questions, and extraction by prompt injection."
This is why the defense has to be architectural rather than behavioral. A model instructed not to reveal a field is being asked to decline; a tool that never returns the field has nothing to decline.
For a firm that moves money, the distinction is the whole compliance argument. Least privilege scoped to a service account is not least privilege scoped to the person who asked.
Did ex-Stripe engineers launch a money-moving AI agent the same week?
Not on the record, and the correction is worth making because the pairing is what gave the story its force.
The claim circulating alongside the AWS release was that ex-Stripe engineers had just shipped an agent that actually moves money. Searching for the launch turns up two real companies, neither of them launched that week.
Circuit & Chisel was founded by Stripe's former head of crypto and AI partnerships Louis Amira and its former head of crypto engineering David Noël-Romas.
It raised $19.2 million on 22 September 2025 for ATXP, which Amira described to Fortune as the HTTP for agentic payments — a year to the day before the TOLAP post, which is likely where the "same week" came from.
Natural raised $30 million in July 2026 to let agents move and store funds, but its founders are not from Stripe.
So the "same week" coincidence does not hold. What survives is the part that was never about timing: capital is flowing into agent payment rails, and the authorization layer underneath them is being built separately, by other people, later.
How fast are financial institutions actually deploying AI agents?
Faster than the pilot narrative suggests, and slower than the record-speed framing claims.
NVIDIA's sixth annual State of AI in Financial Services survey, published 22 January 2026 and based on more than 800 industry professionals, found 42% using or assessing agentic AI and 21% with AI agents already deployed, with a further 22% planning deployment within the next year and beyond.
One in five in production is a real number, not a record. It is also what makes authorization urgent rather than theoretical, because those deployments sit inside institutions with examiners.
A read-only agent that over-returns leaks. A write-capable agent that over-returns leaks and then acts on what it read.
This is the same ownership question that arrives when a software vendor applies for a bank charter: whoever controls the layer that reads your records controls what can be done with them.
Is post-quantum cryptography a real dependency for financial AI, or a distraction?
Real, documented, and on a slower and less certain clock than the alarm version implies.
NIST finalized its first three post-quantum encryption standards on 13 August 2024: FIPS 203 (ML-KEM) for general encryption, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures.
NIST's own framing of the timeline is a report of expert opinion, not a forecast: "some experts predict that a device with the capability to break current encryption methods could appear within a decade." Nobody can name a cracking date, and a post that gives you one is guessing.
The near-term concern is harvest now, decrypt later — encrypted traffic captured today and decrypted whenever the capability arrives.
That is why the G7 Cyber Expert Group, co-chaired by the U.S. Department of the Treasury and the Bank of England, published a roadmap for the financial sector's transition.
NIST's draft migration guidance, IR 8547, is Transition to Post-Quantum Cryptography Standards, an initial public draft released 12 November 2024, describing its expected approach to moving off quantum-vulnerable algorithms.
The practical link to agents is simpler than the cryptography. Both problems are about where enforcement lives. If your agent stack runs on someone else's infrastructure, you do not schedule its cipher migration either.
Can an AI agent actually move money out of a bank account in 2026?
It can initiate the transfer and it cannot complete one alone, and in October 2026 two institutions answered this question in opposite directions in the same week.
On 15 October 2026 Mercury added actions to its MCP server. The bank had shipped the MCP integration in March 2026 as read-only; the October release let an agent in ChatGPT, Claude or another client do things rather than only report them.
Mercury's API page describes the scope: agents can "query balances, transaction history, and account data in natural language" and "transfer funds, pay recipients, categorize transactions, and more."
Then the constraint, in Mercury's own words: "You're always in control — money movement requires a quick tap for approval in the Mercury app."
That is a precise and well-chosen boundary, and it is worth stating accurately. The agent is not blocked from money movement. It drafts and queues the transfer, and a human commits it. Categorizing a transaction, which is reversible and low-stakes, needs no tap.
Two days earlier the largest bank in the United States went the other way.
On 13 October 2026, on its third-quarter earnings call, JPMorgan Chase said it blocks outside AI agents from directly accessing customer accounts, naming Meta's Muse and the startup Instinct.
Jamie Dimon's framing was "You don't want rogue agents," and "We're not going to allow just any outside agent to come inside the company, because that's just too risky for clients and for JPMorgan."
Agents can still reach some data at JPMorgan through approved connectors such as Plaid, which is how a customer links accounts for guidance on balances, transactions, investment holdings and mortgage information.
What the bank blocks is a third-party agent reaching an account through the customer's own banking credentials.
Read the two decisions together and they are not actually a disagreement about whether agents should touch money.
They are a disagreement about where the authorization boundary sits. Mercury put it at the moment of commitment, exposed to the customer as an approval tap. JPMorgan put it at the perimeter, and reserved money movement for an agent it operates itself.
Both are the same underlying move: refusing to let an external model hold unsupervised authority over an irreversible action.
And both are blunt compared with what TOLAP describes, because an approval tap is a single gate on the whole action rather than a filter on which rows the agent could ever have seen.
The gate and the filter solve different problems. A human tap catches the transfer that should not happen. It does nothing about the agent that read 40,000 customer records to decide which transfer to propose.
An institution that ships only the tap has governed the write path and left the read path open. That is the harder half, and it is the half row-level authorization exists for.
How does ibl.ai enforce row-level permissions on agents that move money?
By making authorization a property of the platform you run, not a request made of the model.
With ibl.ai you own all the code and the data.
The platform is self-hosted with full source code access — including the connectors, the policy engine and the agent interfaces — so the components that gate a financial record are ones your team can read and change.
Connectors expose each system in place, scoped to the caller's role. A connector resolves a question by querying the system of record at request time and stores nothing, so there is no second copy to govern and no extract to over-return.
Above them, one MCP broker acts as a single control plane over many MCP servers, with deny-by-default RBAC, credential injection and audit logging. Every agent interaction is logged and auditable, and trails are exportable for SEC, FINRA, SOX and PCI DSS review.
Credentials go further than scoping. As of the 18 September 2026 platform release, an agent sandbox can use a bound secret whose value never enters the guest.
The control plane substitutes it host-side, only for that secret's allow-listed hosts, and no endpoint ever returns the value.
It is model-agnostic across any LLM, usage-based with no per-seat pricing, and you can deploy anywhere: your own cloud, on-premise, GovCloud, or a fully air-gapped network.
1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. More on the deployment pattern for regulated firms is on the financial services solutions page.
ibl.ai is family-owned and operated from New York, NY.
Related reading: when your software vendor applies for a bank charter — why the data layer, not the licence, is what locks a finance team in; and financial AI agents ship as SKUs, integration doesn't — why the connection, not the agent, is the hard part.
Sources: TOLAP's licence, SDKs, policy layers and the IAM-gap argument from the AWS Open Source Blog and awslabs/tolap; deployment figures from NVIDIA; Circuit & Chisel from Fortune; Natural from TechCrunch; the standards and the "within a decade" prediction from NIST; the initial public draft from NIST IR 8547; the roadmap from the G7 Cyber Expert Group.
Related: Apollo Asked If an Agentic Bank Run Is Coming. The Question Is Who Runs the Agent. — the deposit-flight scenario that makes row-level authorization a funding question.