Compliance as an AI Agent Constraint

Most of what we ask coding agents to do is reversible. A bad refactor gets caught by tests, a bad migration gets caught by a safety checker, and a bad guess gets caught in review. A small set of product boundaries is different: they define what kind of company we are, and an agent that drifts across one does not produce a bug, it produces a different product. For those boundaries we use ai agent compliance guardrails that live in the repository as an engineering pattern, not as a hope that the model will remember.

This is part of our Govern series on running an AI software factory safely. One caution first: this is engineering process, not legal advice. The pattern describes our internal policy for how agents behave. It does not state what any regulator requires, and nothing in this post should be read that way.

The boundary we protect

Our stance is short and sits in the always-on agent instructions. TradersPost is plumbing for self-directed traders. We are not a registered investment adviser, a broker-dealer, or a managed-account service. Agents must never introduce leader/follower fill mirroring, credential sharing, or remote operation of another person's account. We prefer Strategy Templates, where a recipient clones a strategy into their own account and runs it independently. Strategy Subscribing is allowed only behind plan gates and broker allowlists. Ambiguous cases get escalated.

That is an easy paragraph to agree with and a hard one to preserve. Nobody asks an agent to build copy trading. They ask for a feature that keeps customer clones in sync with a master template, or a vault so a provider can reconnect brokers for people, or a leaderboard. Each one sounds like ordinary product work, and each one moves the product toward a model we intentionally do not support. An agent optimizing for the ticket in front of it has no reason to notice.

So the failure we design against is not malice or incompetence. It is an agent making a locally reasonable change that is globally outside the boundary, with nothing in its context saying so.

What triggers loading the pattern

Rules an agent never loads do nothing, and we learned in earlier work that stuffing everything into always-on context is the wrong fix. The root instruction file therefore carries only the universal invariant and a routing row, and the detail lives in a pattern the agent pulls on demand. The routing row says that compliance-sensitive strategy, subscription, webhook, broker-connect, partner, template or cloning, performance, or marketing work loads the compliance pattern and its review checklist before coding or reviewing.

The pattern itself starts with a list of triggers. An agent loads it before designing or changing:

• Strategies, subscriptions, webhooks, signal routing, and template or cloning flows.
• Broker connection, OAuth, ownership attestation, and login limits.
• Onboarding, partner or provider features, and community or group features.
• Marketing, UI, help docs, disclosures, and legal-adjacent copy.
• Anything that could let one party control or execute trading for another.
• Performance claims, win rates, testimonials, or outcome guarantees.
• Features that resemble copy trading, social trading, mirroring, or managed accounts.

Note how wide the list is. It covers copy and documentation, not just code, because a help article can describe a banned model as easily as a controller can implement one. It also says to load the pattern during pull request review when those surfaces changed, so a reviewing agent gets the same context as the authoring agent.

Four status labels

The core of the pattern is a small vocabulary. Every statement of policy carries one of four labels, and each label tells the agent what to do.

We deliberately do not publish the contents of the per-broker matrix or the open questions behind the Pending labels here. The point for this post is that those labels exist and that an agent knows how to behave around each one. Pending is the important one for an agent to internalize: an unanswered question is not permission, and the agent may not build a capability whose legality or acceptability depends on a Pending answer.

The pattern also has a quick triage table that sorts a request into Allow, Block, or Escalate, with a tie-break rule: when a request mixes categories, the stricter outcome wins. Block beats Escalate, and Escalate beats Allow. A request that is mostly fine and partly banned is banned.

Escalate, do not rationalize

One line in the pattern does more work than the rest: default when uncertain: escalate. Do not rationalize.

Agents are good at constructing a plausible argument for whatever they were already inclined to do. If the instruction were only "do not violate the model," an agent could reason its way to "this is technically a template, so it is fine." The second sentence is aimed at that behavior. It tells the agent that a persuasive internal argument is not a substitute for an answer.

Two related rules close the common escape hatches. The first is that renaming something does not change what it is: changing terminology alone does not make a banned behavior acceptable, and "separate accounts" is not by itself treated as proof that a design is fine. The pattern asks the agent to look at architecture, control, operating behavior, and what the UI and marketing say, together. The second is a design gate of sixteen questions an agent walks before shipping, such as who owns the account, whether credentials or sessions are shared, and whether a provider can change something once and alter trading for many unrelated users. If any answer is uncertain, or touches an open Pending or Per-broker item, the instruction is to stop and escalate.

Escalation goes to the human who requested the work, then to compliance or counsel as they direct. The pattern is explicit that agents do not make final legal determinations. That is the line between an engineering interpretation layer and the authority it interprets: for anything contractual or regulatory, the pattern points at the current source document or a person.

Why labels beat a boolean

We considered encoding this as a flag on each feature: compliant or not. We did not, for three reasons.

First, a boolean cannot express "we do not know yet," and that is the state that matters most. A false flag reads as a decision when it is really an open question, and a true flag set on an assumption is worse. Pending as a first-class label keeps the uncertainty visible and attaches a behavior to it.

Second, the four labels need four different actions. Enforce, stop and ask, check a matrix, and read a document are not the same operation, and collapsing them into allowed and blocked loses the instruction an agent needs.

Third, prose is what an agent actually reads. A label plus one sentence of required behavior fits the retrieval model we already use for patterns and checklists, and a human reviewer can read the same text and see the same rule the agent saw. A flag buried in a config file serves neither reader.

The checklist and the golden test

The pattern says what the policy is. The compliance review checklist makes an agent check itself against it. It covers scope, the independent trader model, the hard bans, substance over labels, copy and disclosures, broker diligence, the design gate, adjacent use cases, and the pull request itself. The last section asks the author to note compliance-relevant behavior and any escalations in the description, and to ask the reviewer to apply the checklist.

A policy that is not tested drifts, so we also keep a golden test, the same mechanism we describe in regression tests for agent instructions. It is a small expected answer for a compliance-shaped prompt. It checks that the agent loads the compliance pattern and checklist first, that it blocks a master-to-many future sync because a provider would be remotely changing unrelated users' live trading after setup, and that it escalates a "Top Strategy" returns badge. It also checks that the agent can describe the acceptable shape: a one-time template clone into a user-owned account, followed by independent, user-controlled operation with no future provider propagation.

The test is cheap and it catches the failure that matters most here, which is an agent that stops routing to the pattern at all. When an instruction edit or a context trim quietly breaks that routing, the golden answer changes and we see it. It does not prove the agent will classify every new request correctly. It proves the door to the policy is still open.

Humans stay in the loop

The last piece is not in the compliance pattern at all. It is in our review policy. We route review by risk, as described in risk-proportional review for AI agents, and compliance-sensitive behavior sits in the high-risk tier. The policy lists changes to trading execution, broker abstraction, auth and security, billing, migrations, and compliance-sensitive behavior as requiring human review regardless of how an automated loop exits. It also says not to tell an auto-merge-candidate story about them without human approval.

That matters because of how the author and reviewer loops work. We cap them so they cannot argue forever (see stopping AI agents from arguing forever), and a loop can exit cleanly with green checks and no open threads. For most changes, that exit plus a risk tier is enough. For compliance paths, a clean exit is explicitly not enough. An agent can add context in prose, but it may not clear the trigger by lowering the risk rating or resolving a thread on its own.

The two mechanisms cover different failures. The pattern tries to stop an agent from building the wrong thing. The human review requirement assumes the pattern sometimes fails and puts a person with authority in front of the merge.

What this cannot do

This raises the floor. It does not make a violation impossible. An agent can misread a request, a new feature can fall in a gap the pattern never anticipated, and a prompt can be phrased so that nothing in it looks like a trigger. A golden test checks the cases we thought of. A checklist is only as good as the agent's honesty in filling it in.

We do not treat the pattern as the authority either. It is an engineering interpretation layer, and where something depends on an agreement, a disclosure, or a legal opinion, the answer comes from the source document or from a human with the right authority. The goal is narrower than correctness: make the careful path the default one, make uncertainty stop the work instead of passing through it, and make sure a person decides when it matters.

Lessons

1. Write boundaries as a loadable pattern. A rule the agent never retrieves is not a constraint, so route to it from the always-on file and list the triggers explicitly, including copy and docs.
2. Use labels that name a behavior. Settled, Pending, Per-broker, and Consult source each tell the agent what to do, and Pending keeps "we do not know yet" from being mistaken for a yes.
3. Make escalation the default. Tell agents not to rationalize, and let the stricter outcome win when a request mixes categories.
4. Test that routing still works. A small golden answer catches the quiet failure where the agent stops loading the pattern.
5. Keep human review mandatory on these paths. No loop exit, green check, or risk argument from the agent replaces a person, and the humans own the outcome.
6. Be honest about the limit. This lowers the chance of an accidental drift into a model we do not support. It does not remove the need for people with authority to make the hard calls.

If you are adopting coding agents where a few product boundaries really matter, start by listing the surfaces that could cross them and the behavior you want when an agent is unsure. Then put that in the repository, test that it is found, and keep a human on the merge. The same shape works for any boundary you cannot afford to have an agent redraw by accident.