Checking AI Agent Actions Against the Law Before They Execute

Carver Agents works out what the law requires of an AI agent. Rippletide uses it to decide on each action before it reaches a business system.

Last month, the chair of the US Federal Trade Commission, Andrew Ferguson, pushed back on treating AI agents as independent actors. "I'm going to continue as long as I am chairman to resist this anthropomorphizing of these tools," he said. His remarks, as Reuters reported, suggested that the developers who instruct an agent are the ones liable for what it does, and that existing law already gives regulators the tools to act. For any company running agents in production, every action an agent takes is now a legal question.

A support agent receives a message from someone who says they are a customer's accountant. They want the customer's last twelve months of invoices and payment history, sent to an email address the company has never seen before.

The agent can do it. It has read access to the billing system and a tool that sends email. Its instructions tell it to resolve requests quickly. Nothing in its permissions says no.

Whether it should is a different question. The answer depends on who the requester really is, where the customer lives, what the records contain, and what the law in that jurisdiction requires before personal data goes to a third party. Permissions cannot answer that, and neither can a well-written system prompt.

Identity and access controls tell you who can act. They do not tell you whether a specific action is allowed, in this place, at this moment. That gap is what Rippletide and Carver Agents are closing together.

Two questions, two layers

Getting this right takes two different kinds of work.

What does the law require of this agent? This is Carver's domain. Carver ELI (Executable Legal Infrastructure) turns statutes, regulations and their exceptions into structured, traceable obligations: who is bound, what is required or prohibited, when it is triggered, which exceptions apply, and which source supports it. Starting from a description of the agent, Carver works out which obligations apply, which do not, and which remain unresolved because a fact is missing. Carver's companion post, From Legal Obligations to Safe Agent Actions, walks through that translation in detail, with a worked example from Illinois' biometric privacy law.

Should this action go through, right now? This is Rippletide's domain. Rippletide sits between the agent and the business systems it writes to. It turns the applicable obligations, the company's own policies and the current facts of the case into a decision model, and uses it to decide on each proposed action before it takes effect. Every decision comes back with its reason and the evidence behind it. (More on why the action boundary is where this decision belongs.)

Carver's output is the legal context: which obligations apply, under which conditions and exceptions, and which facts are still missing, each traced to its source. Rippletide turns that context into a decision on the actual action, with the facts of the case in view: allow, block, escalate, or ask for what is missing.

One request, four possible decisions

Back to the accountant. Without a decision layer, teams usually choose between two bad options: let the agent send the file, or block every outbound disclosure and route all of them to a human queue.

With Carver and Rippletide in the loop, the request is evaluated on its facts. Carver identifies the obligations that apply in the customer's jurisdiction, such as the conditions for disclosing personal data to a third party, and flags one fact as unresolved: has the customer authorized this person? Rippletide then decides on the proposed action, using a decision model built from those obligations, the company's verification policy, and what the systems of record actually show.

• Allow. The customer has an authorized representative on file who matches the requester. The agent sends the records, and the decision is logged with the reason and evidence behind it.

• Ask. No authorization is on file. Instead of a flat refusal, the agent is told exactly what is missing and asks the customer to confirm.

• Escalate. The requester claims a legal authority the agent cannot verify, such as a power of attorney. A person with the right authority takes over, with the context already assembled.

• Block. The customer has formally refused any sharing with third parties. There is no compliant path, so the action is blocked and the reason is recorded.

Same request, same decision model, different evidence, different decision. People step in where judgment is needed, not on every outbound email.

Other actions, same pattern

The accountant request is one case. The same pattern applies to any agent action with legal consequences: Carver supplies the legal context, and Rippletide decides. A few simplified examples:

Agent action	What Carver flags	What Rippletide decides
A finance agent releases a supplier payment	Sanctions rules: funds cannot go to a party on a current sanctions list.	Allow once screening against today's list is clear. Block on a match. Escalate a partial match to compliance.
A recruiting agent rejects a job applicant	Rules on automated hiring decisions, such as New York City's Local Law 144: candidates must be notified, and the tool needs a bias audit from the past year.	Allow when the notice was sent and the audit is current. Otherwise, escalate the rejection to a recruiter.
A support agent denies a refund request	Consumer withdrawal rights: in the EU, most online purchases can be cancelled within 14 days.	Block the denial while the customer is inside the window, so the refund goes through. Allow it once the window has passed or an exception applies.
A banking agent closes a customer's dispute over a debit card payment	Error-resolution rules (Regulation E in the US): the bank must investigate and report its findings within set deadlines.	Block the closure until the investigation and the customer notice are on record. Escalate cases close to the deadline.

Why a prompt is not enough

It is tempting to paste the relevant regulation into the agent's system prompt and trust the model. That gives the agent the text of the rule. It does not guarantee the rule is applied the same way every time, with every exception, on every request.

Carver's post explains why legal reasoning has to be neuro-symbolic. On the action side, it means deciding from an explicit decision model. Each obligation from Carver and each internal policy becomes part of that model, which the company's own team reviews and approves.

The decision model links every condition to the facts it depends on: who is asking, what is on file, what the record contains. The agent's language model still reads the request and proposes the action, but the decision is made against the decision model. The same facts produce the same decision every time, and each decision points to the conditions and evidence behind it (how Rippletide builds decision models).

The result is a decision a legal or compliance team can audit, rather than one it has to reconstruct from logs. And when a law or an internal policy changes, the decision model is updated once, then applied to every agent that depends on it.

What we are building together

The joint workflow we are putting together runs in four steps, from an agent's description to the moment it acts:

1. Describe the agent: what it does, which tools it uses, where it operates.

2. Map the obligations: Carver identifies which obligations apply, which facts are missing, and what evidence would establish compliance.

3. Build the decision model: for the agent's riskiest actions, Rippletide combines those obligations with the company's own policies into a decision model, documented in a Safety Case the enterprise can review.

4. Decide at runtime: each of those actions gets a decision (allow, block, escalate or ask) before it reaches a business system, and every decision keeps its reason and evidence.

Building those decision models used to be the slow part. Turning laws and internal policies into explicit conditions, then keeping them current as both change, took teams hours and hours of manual work. Rippletide now does it autonomously: it builds each decision model from Carver's obligations and the company's own policies, and when a source changes, it proposes the update and tests its impact. The team reviews and approves the result instead of writing every condition by hand.

The point is not another review step. It is letting compliant actions go through, and stopping the others before they reach a business system.

Permission is where it starts

An agent with access to production systems needs more than permission. It needs to know which obligations apply, and something has to decide before the action lands.

Agent proposes. Rippletide decides. With Carver, the law is part of the decision.

---

Read Carver's side: From Legal Obligations to Safe Agent Actions, on the Carver blog

Have an agent action your team still reviews by hand? Book a free risk review with Rippletide.