Your AI Agent Just Became a Compliance Artifact

Written By Curtis Wadsworth

In July, Singapore's central bank published a document most American business owners scrolled past. That was a mistake.

The paper is called Safeguards for Agentic Finance at Runtime — SAFR. It was written by the Monetary Authority of Singapore (MAS) with Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC, and Visa. 

It is not a regulation, but look at who signed it: Visa, Mastercard, JPMorgan, and HSBC. These companies are the buyers. When they co-author a technical specification, that specification becomes a purchasing requirement. 

If you are building anything that lets an AI agent take an action — move money, submit a filing, sign a document, close a ticket, send a customer communication — SAFR describes the shape of the questions your enterprise buyer is going to ask you next quarter.

One definition before we go further. An “agent” here is not a chatbot that answers questions. It is software that pursues a goal by planning steps, choosing tools, and initiating actions on its own, without a human approving each step. 

How SAFR works

The core insight is simple and it lands hard: approving the model is not approving what it does.

Model risk review evaluates the system before it goes live. Audit evaluates the transaction after it executes. Neither one catches a bad decision in the seconds before it executes. By the time the problem shows up in an audit log, the money has moved.

So SAFR inserts a checkpoint between the agent's decision and its execution. Every proposed action is evaluated against the institution's own rules before it is allowed to happen. Here is the sequence:

  1. The agent packages the request. Before acting, the agent produces a governance envelope containing the proposed action, the action trace (the actual steps it took to get there — the tools it called, the data it pulled, the checks it ran), and context about the agent and the account it is acting on. The envelope is checked for completeness before it goes anywhere. It is the record that carries through every step that follows.

  2. Agent Identity confirms who is asking. The envelope names an agent; this step verifies that the agent is registered and is who it claims to be. — a recognized agent and not an impostor. Fail the check and the action is rejected on the spot, with the failure logged. In a closed system, the registry is the institution's own. Where the agent transacts with outside parties, this step also has to determine which registry governs.

  3. The Controls Repository pulls the applicable rules. This is the institution's rulebook — regulatory requirements, product rules, internal policy, and mandates. A mandate is delegated authority written so software can read it: what this agent may do, up to what limit, under what conditions. The hard constraint lives here: an agent cannot expand its own mandate through reasoning or inference. Authority is granted. It cannot be derived.

  4. The Disposition Engine decides. It evaluates the action against those rules deterministically — fixed thresholds and categorical logic, not a judgment call by another model — and returns exactly one of four outcomes: Deny, Escalate (hold for a human), Auto-Execute, or Observe (let it run, but flag it). Which outcome an action gets is calibrated to five factors: whether the action can be undone, how much money is at stake, how badly a customer could be harmed, how regulated the action type is, and whether the action departs from established patterns. Those thresholds are set at design time and reviewed before deployment, not adjusted on the fly.

  5. The Audit Log records all of it — at every step, not just the end. A record written at the moment of each decision that cannot afterward be altered. The rejection at step 2 is logged. So is the approval at step 4. Every outcome, including the ones where nothing went wrong.

Two things about this flow are easy to miss.

The envelope is a claim, not a fact. The agent writes its own action trace, which means the agent is describing its own work. A sophisticated prompt injection — hostile instructions smuggled into data the agent reads, causing it to do something it was never asked to do — can fabricate the trace and the action details together, consistent with each other and both wrong. Nothing inside the envelope would reveal it, because the compromised agent wrote all of it. The check has to come from outside: tie the envelope back to the instruction that actually started the task, rather than trusting the agent's account of what it did.

Approval does not carry forward. Each action is evaluated on its own. An approved step one grants nothing to step two, because the agent adapts as it goes — intermediate results change, conditions change, and what was reasonable at step one may not be at step four. If your system authorizes a workflow rather than an action, you are outside the model.

The American picture has an agentic AI gap

There is currently no US federal supervisory framework written for agents that act.

On April 17, 2026, the OCC, Federal Reserve, and FDIC rewrote the model risk rulebook that had governed banks since 2011. The old framework, known as SR 11-7, was replaced by revised guidance issued as OCC Bulletin 2026-13 and designated SR 26-2 by the Federal Reserve. It explicitly states that generative AI and agentic AI models are "not within the scope of this guidance." The agencies said a request for public input on banks' use of AI would follow.

The fifteen-year-old rulebook got rewritten, and agents were carved out of it.

That is not permission. Reporting indicates examiners at the Fed and OCC have made AI a standing topic in routine bank examinations regardless — asking about governance, vendor risk, and kill switches. The OCC's Spring 2026 Semiannual Risk Perspective supports responsible use of generative and agentic AI while flagging the governance challenges. Fed Vice Chair for Supervision Michelle Bowman has publicly questioned whether existing AI supervisory guidance is fit for purpose.

Translation for anyone selling into a regulated buyer: there is no rule you can point to, and no rule you can hide behind. Your customer's examiner will ask your customer how the agent is governed. Your customer will ask you. You will answer it in a security questionnaire, under deal pressure, and the answer is either already built or it isn't.

Singapore is running the opposite play. On August 5, 2026, MAS told Parliament that its forthcoming AI risk management guidelines apply to all AI use cases by financial institutions, agentic AI included, and would be finalized soon. Industry reference today, supervisory expectation later, is a sequence Singapore has run before.

Before you publish the diagram

Did you already talk about it?

A conference talk, a customer demo, a detailed architecture post — any one of them can start a clock you cannot stop. The Patent Disclosure Exposure Check takes a few minutes and tells you where you stand.

Check your exposure →

Learn more about Patent + Defensibility Counsel

Europe has three regimes, and none were built for this

Two vocabulary items first, because the EU rules turn on them. A provider is whoever develops an AI system and puts it on the market. A deployer is whoever uses it, the customer. Different obligations attach to each, and the label can move.

The transparency rules are live now. If your agent interacts with a person, that person has to be told they are dealing with a machine. These obligations sit in Article 50 of the EU AI Act and took effect August 2, 2026. A related marking-and-detection requirement in Article 50(2) reaches systems that were already on the market before that date starting December 2, 2026 — a deadline still ahead of you, not behind.

The heavy obligations were delayed, not canceled. The EU AI Act designates certain uses as "high risk" and attaches a demanding compliance regime to them. In July 2026, the Digital Omnibus on AI (Regulation (EU) 2026/1744) pushed the compliance date for standalone high-risk systems from August 2, 2026 to December 2, 2027, and to August 2, 2028 for AI embedded in products already covered by EU product-safety law. The rules themselves are enacted law. Only the date moved.

Finance is the densest sector on that high-risk list. AI used to evaluate the creditworthiness of individuals or set their credit score is high risk, with one express carve-out for systems used to detect financial fraud. So is AI used for risk assessment and pricing of individuals in life and health insurance — life and health specifically, not property and casualty. There is a narrow escape hatch for a listed system that a provider can document poses no significant risk, but for a model that materially informs a lending decision, that door is not wide.

Your customer can become a provider by using your product. Under Article 25, a deployer who repurposes an AI system into a high-risk use can be treated as that system's provider and picks up the obligations that come with it. Point a general-purpose customer-service agent at creditworthiness evaluation and the classification follows the use, not your design intent. If your product is deliberately built to be configured by the customer, you have a decision to make: document permitted uses, restrict them technically, or address them in the contract. The customer who trips into provider status will come back to you about it.

Article 99 sets the stakes across the whole regime — up to €35 million or 7% of worldwide annual revenue for prohibited practices, €15 million or 3% for high-risk and transparency breaches. Startups and smaller companies pay the lower of the two figures rather than the higher.

The regime already binding is the one nobody wrote a headline about. DORA — the Digital Operational Resilience Act, Regulation (EU) 2022/2554 — has applied since January 17, 2025. It requires EU banks, insurers, investment firms, and payment institutions to maintain a register of every technology vendor they depend on, and to report it to their regulator annually. Sell an AI agent to one of them and you are on that register. If your agent touches a function the institution considers critical or important, your contract has to carry a specified set of provisions, including audit and access rights, exit planning, and cooperation on incidents. Your customer stays responsible for DORA compliance no matter how good your own posture is. So they push the obligations down to you, in writing, as a condition of the deal.

Three regimes, three different clocks, none of them designed for software that acts on its own. That gap is why a document like SAFR exists at all.

What builders should actually do

The items that will cost you a deal or a claim.

  1. Build the envelope now, not later. SAFR describes two ways to integrate. In the first, the agent itself is built to emit a governance envelope before each action. In the second, a gateway — a piece of infrastructure that sits in front of the agent and intercepts its outbound calls — wraps each call in an envelope without anyone touching the agent's code. The gateway exists because retrofitting is painful. If you are pre-launch, build it into the agent. The gateway is the path for code you can no longer change.

  2. Assume your reviewer's authority will be tested. The paper's sharpest line describes escalation that gives "the appearance of human oversight without the substance of it." Escalation is not a control unless there is a deadline for the human to respond, a defined default if that deadline passes, and a reviewer who can actually approve or decline. In litigation, a process you documented and did not follow is worse than no process. Bar guidance lands in the same place on lawyer supervision.

  3. Your audit log is evidence, and the other side can get it. A permanent record of every decision your agent made and every rule it was checked against is a governance asset and a plaintiff's exhibit at the same time. That is not a reason to skip it — the absence of a log is far worse and increasingly indefensible. It is a reason to decide retention periods, access controls, and whether any of it can be kept confidential under attorney-client privilege before the first entry is written. Involve counsel at design time, not after the demand letter.

  4. Contracts written for software that answers do not cover software that acts. If your master services agreement was drafted for a product that returns outputs, it does not allocate liability for a product that takes actions. Look hard at the warranty section, the limitation of liability, the indemnity, and whether anything in the document defines the scope of what your agent is authorized to do on the customer's behalf. Then check your insurance. Coverage for AI-caused loss is usually not where founders assume it is.

  5. Every agent needs its own identity. Enterprise security reviews now ask whether each agent has a distinct identity separate from any human's login, how its credentials are stored and rotated, whether there is a documented emergency-access procedure, and whether audit logs can be exported. Vendors who cannot answer these in the first call get cut before anyone evaluates the product.

The real shift

For a decade, AI governance meant governing a model. Documentation, validation, testing, sign-off before deployment.

That framing is finished. When the system acts, the unit of governance is the action, and assurance has to attach at the moment of the action. Everything else is a post-mortem.

The companies that figure this out early will not just move through diligence faster. They will close enterprise deals their competitors cannot, because the buyer's compliance team will be the one blocking those competitors.

Building an AI product that takes actions on behalf of customers? The governance architecture, the contract terms, and the IP position are one problem, not three — and they all get examined at the same table when a buyer or an investor runs diligence.

Explore Patent + Defensibility Counsel →

Sources

Curtis Wadsworth
Next

After the Pile-Up: What Your Series A Lead's Lawyer Actually Sees