In August, Ali Spittel put the shift in one line: "i really don't want to use your agent, i want to use my agent to use your thing." The post has passed 700,000 views. The industry's answer so far has been about reach: ship an MCP server, design for "agent experience" (AX), make your actions discoverable.
That is necessary, and it is the easy half. This piece is not about protocols (MCP, A2A, REST) or about making tools agent-friendly. It is about what changes in your security and compliance model the moment the thing calling your product is a model you have never seen.
The model is no longer yours
When you ship your own assistant, you choose the model, write the system prompt, pick the tools and tune the refusals. Whatever you think of that stack, you own it, and you can reason about it.
When the customer brings the agent, every one of those levers moves to the other side of the wire. You don't know which model it is, which version, what it was told, what else it is connected to, or whether the person behind it is who the API key says they are. Tomorrow it may be a different model entirely.
Treating model output as untrusted input used to be a design stance some teams adopted. In a bring-your-own-agent world it is simply a description of the situation. The model calling your product is untrusted by definition.
Guardrails on a model you don't run
Most of today's agent safety tooling sits on the model side: system prompts that say what not to do, output filters, classifiers, fine-tuned refusals, evaluation suites that check how the assistant behaves.
All of it assumes you run the model. You can't add a line to a system prompt you never see. You can't fine-tune a customer's model, or rerun your evals every time they switch providers. A filter on their output is something they apply, or don't.
Even where those tools apply, they are probabilistic. They lower the odds of a bad action; they don't make it impossible. For a regulated business the control has to be demonstrable, and "our assistant is very unlikely to move money without authorization" is hard to demonstrate. Behind a customer's agent, you can't even claim the "very unlikely" part.
What's left to control: what the agent can reach
If you can't govern the model, govern what it can reach. The question changes from "how do I make the agent behave?" to "what is this agent able to do, under which conditions, and what proof is left behind?"
Tunelo, a South African team, documents a clean example for its workshop software, GarageManager. The product supplies no AI of its own: a workshop connects its own agent, which GarageManager calls an AI Apprentice, over MCP or REST, with a token the workshop creates. Read as a control design, it has six parts:
- Scoped identity (who is this, and over what?): a token the workshop creates, set to expire after 30 or 90 days or never, and revocable at any time.
- Declared actions (what can it do at all?): more than thirty named actions in three cumulative access levels, the widest of which adds the library.
- Forbidden verbs (what can it never do?): it cannot issue or send anything to a customer, record or refund a payment, sign off a draft (its own included), or delete a customer, vehicle, job card, quote or invoice.
- Human sign-off (which steps stop for a person?): a person signs off every draft it prepares, and only a person issues or sends anything to a customer.
- Data boundary (what can it not see?): cost prices and suppliers stay hidden unless the agent has library access.
- Record (what happened, including what was refused?): every action it runs or tries is recorded, refused ones included.
None of this depends on which model is on the other end.
It also shows the cost. This is one product's domain, designed and hand-built action by action. Every company that opens its product to customer agents will have to do the same work, for its own actions, preconditions and approvals.
The record is written by the party being audited
One control in that list is weaker than it looks: the record.
A log that the vendor writes, stores and can edit is evidence for the vendor. It answers "what does our system say happened?" It doesn't answer the question the customer, or the customer's regulator, will eventually ask: "how do I know this log is complete and unchanged, without taking your word for it?"
That question gets sharper with outside agents, not softer. When a customer's agent does something harmful through your product, the first dispute is factual. Did the agent request it? Did your rules allow it? Which version of the rules? Was a human asked? If the only answer is a database table under your control, you are both the operator and the auditor of your own governance.
What answers it is a record the other party can verify on its own: each decision chained when it is made, so that a deletion or edit is detectable, with signed checkpoints anyone can check offline and, where the customer holds the signing key, without trusting the vendor. A refusal belongs in that record as much as an approval, because in a dispute the blocked request is often the fact that matters most.
Why regulated LatAm will feel it first
A workshop that loses a draft quote has a bad afternoon. A fintech whose API lets an unknown agent move money, change a beneficiary or file a claim has an incident, and possibly a regulator on the phone.
Latin American fintech and insurance are unusually exposed to this shift. Open finance has already normalised regulated third parties initiating payments from a customer's account, with the customer's consent; Brazil's payment initiation under Open Finance, defined in 2020 by the Central Bank's Joint Resolution No. 1 and now live with Pix, is the clearest case. Customer agents are the next third party, except they are not registered, not certified and not predictable.
The demand will show up as a customer asking why their assistant can't pay a bill through your app, followed a few months later by a compliance question about what happened when one did. The companies that answer the first without having designed for the second will end up shutting the door again.
The controls belong in a declaration
The six controls above are the same in every domain. Only the content changes: which actions exist, what each requires, which ones stop for a human, what is out of bounds. That is a strong hint they belong in a declaration, not in code scattered across endpoints.
Declared, the rules can be reviewed by compliance before anything runs, versioned, and diffed when they change. Every write, whether it comes from your own assistant, a customer's agent or a plain API client, passes through the same deterministic gate. The model only ever proposes; the contract decides and the runtime enforces. And because the rules are versioned, a decision can name the version of the rules that made it.
This is the problem we build Zarel for: a runtime where an agent can only write what a contract declares, and where every verdict at that gate, a refusal included, is chained with the version of the contract that decided it, under signed checkpoints that can be verified offline. Verifying it without trusting us takes the deployment where the customer holds the signing key, which has not yet run in production.
The record half of this argument is in A signed receipt is three claims, not one; the gate half is in A gate is three claims too.
Nicolás Moreno builds Zarel: governed AI operations, where the AI proposes and the contract decides.