AI agents can now request a likeness with no human reviewing it. See why consent must be enforced server-side, and how LikeWard's MCP server does it.
Photo via Unsplash
Somewhere in the last eighteen months, the assumption that a human reviews every request to generate an image of a real person quietly stopped being true. Not because anyone decided it should — because agents started making requests on their own, chained inside longer tasks, with nobody reading the prompt before it went out.
That shift is not hypothetical. Gartner's own forecast, presented at its October 2025 IT Symposium, puts 90% of B2B purchasing under AI-agent intermediation by 2028, routing more than $15 trillion through automated exchanges with minimal human intervention by design. The infrastructure carrying that traffic is growing at a similar pace: the Model Context Protocol, the open standard most agents now use to call external tools, passed 97 million monthly SDK downloads by March 2026 and now connects to more than 10,000 public servers from inside ChatGPT, Claude, Gemini, Microsoft Copilot and Visual Studio Code. An API that only thinks about the human sitting at a browser is now designing for a shrinking share of its own traffic.
Key takeaways
- Consent obligations don't change when the requester is an agent rather than a person — but the human who might have caught a bad request often isn't there to catch it.
- A rule enforced in a system prompt or client-side code can be argued around, skipped, or simply not run. It is advice, not a boundary.
- MCP is a transport, not a permission layer — wiring consent into the underlying API means nothing if the agent-facing surface doesn't call the same gate.
- A dry-run check that costs nothing lets an agent iterate on a prompt without spending, and without ever producing something that shouldn't exist.
- Provenance still matters for agent-originated content — arguably more, because there is no human to ask "did you mean to generate that?" after the fact.
Picture a fairly ordinary automation: a marketing agent tasked with drafting a week of campaign assets. It has a content calendar, a brand style guide, and access to a handful of tools — a stock-image search, a copy generator, and an image API that can produce photoreal creative featuring a licensed creator's face for an endorsement post. Nobody sits between the agent and that image tool for hours at a stretch, because the entire point of delegating the task was to not have to.
That's the shape of demand the licensed-likeness marketplace increasingly serves alongside the direct web traffic it was originally built for. It is also the shape of demand that most consent architectures were never actually tested against, because they were designed and reviewed by people clicking through a form, one request at a time, with a human able to stop and think before submitting.
None of the underlying law changes because the requester is software. A right-of-publicity claim, a platform's takedown duty, a card network's consent-audit requirement — all of it attaches to the output and who authorised it, not to whether a person or a script assembled the request. What changes is the failure mode. A person who was about to submit a request outside a creator's boundary set might pause, reconsider, or read an error message and adjust. An agent mid-task, unless something actively stops it, keeps going.
The instinctive fix — tell the agent what it isn't allowed to do — is also the weakest one, and it's worth being specific about why, because "just add it to the system prompt" is the first thing most teams try.
A system prompt is an instruction to a model, evaluated the same way every other piece of context in the conversation is: probabilistically, and subject to being outweighed by whatever else is in that context window. It can be pushed against by a long enough conversation, misapplied on an edge case nobody anticipated, or simply omitted if the agent framework building the request doesn't forward it faithfully to whichever tool call actually does the generating. None of that requires anyone to be acting maliciously. It just requires the enforcement to live somewhere that isn't mechanically guaranteed to run.
The tell is what happens when you ask "can I prove which rule this specific output was checked against, and that the check actually ran?" A rule living in a prompt has no artifact — no log entry, no version, nothing to show a card network's compliance auditor or cite in a takedown response. A rule enforced server-side, on every request regardless of which client sent it, produces exactly that: a decision object with the rule that fired, and — for anything that passed — a signed manifest recording it did.
This is the practical difference between an enforcement point that holds under agent traffic and one that only ever worked because the traffic was slow enough for a human to catch mistakes.
| Enforcement point | Can an agent route around it? | What a breach produces | Evidence it leaves behind |
|---|---|---|---|
| System prompt / agent instructions | Yes — a longer context, a misconfigured framework, or a prompt that simply isn't forwarded | An image that shouldn't exist, generated | None; there is no record the instruction was even in effect |
| Client-side validation in the agent's own code | Yes — the agent (or whoever built it) controls that code and can skip the check | Same as above, plus inconsistent behaviour between integrations | A log only if that specific integration chose to keep one |
| UI-only moderation (checked on the website, not the API) | Yes — trivially, since API and MCP traffic never touches the UI at all | A clean bypass, not an edge case | Nothing; the request never passed through the checked path |
| Server-side gate on the generation endpoint itself | No — every client, including MCP, calls the same endpoint | Refusal before any model runs, with the specific rule named | A decision object naming the rule, and a signed manifest for anything authorised |
Table: where a consent check runs determines whether it survives contact with an agent that has no reason to route around it deliberately — it just has no reason to route through it either, unless every path leads to the same gate.
LikeWard's answer is architectural rather than procedural: the web app, the REST API and the MCP server all call the identical runGeneration function, evaluated against the creator's live boundary set before any image model is invoked. The MCP server holds no rules of its own — it's a thin client of the hosted API, which is what makes "the MCP path is weaker" structurally false rather than merely untested. A full walkthrough of the endpoints themselves, including refusal handling and credit semantics, is in the licensed-likeness API tutorial.
"In this new ecosystem, verifiable operational data becomes a currency, fuelling a data feed economy where digital trust frameworks and verifiability are prerequisites for participation." — Gartner, on the shift toward AI-agent-intermediated B2B commerce
Back to the marketing agent drafting campaign assets. Its first move, correctly, is list_creators — no API key required — followed by get_boundary_set for the creator the brief names, which returns the permitted contexts, the excluded-brand list and the realism ceiling as structured JSON rather than a paragraph the agent has to interpret.
The brief calls for a brand-endorsement context at photoreal realism. The creator's boundary set permits both — but their excluded-brand list, set two years earlier under a still-active exclusivity clause, names a direct competitor of the brand in the brief. The agent doesn't know that yet; it composes the request and calls check_request, the dry-run tool that costs no credit and produces no image.
The response comes back refuse, with rule: "excluded_brand" and the matched brand quoted directly. No image was generated, no credit was spent, and — this is the part a client-side check can't replicate — the refusal is enforceable rather than advisory: there is no configuration on the agent's side that would have produced a different answer, because the agent never held the rule in the first place. It reports the conflict back into the task, the human running the campaign swaps the creator, and the second check_request comes back allow. Only then does generate run, and the resulting image carries a manifest naming the creator, the boundary-set version, and the requesting key — the artifact that answers "who authorised this" without anyone needing to remember the answer six months later.
Assuming low agent volume means low agent risk. A handful of automated requests a day looks negligible against thousands of human ones — until one of them is the request that generates something that shouldn't exist, at which point volume was never the variable that mattered.
Treating the agent's own framework as the trust boundary. If the enforcement lives in code the agent (or its developer) controls, it isn't enforcement — it's a default the requester is free to change. The trust boundary has to sit on infrastructure the requester doesn't control, which for a hosted API means the server, not the client library calling it.
Letting a long-running agent cache a "licensed" answer. A boundary set or a licence can be revoked mid-session. An agent that checked once at the start of a multi-hour task and never checked again is operating on state that may no longer be true — and the fix isn't a longer cache TTL, it's re-checking at the point of generation rather than at the point of planning.
Building the agent-facing surface as a separate implementation. The moment MCP tools, a REST client and a web form each contain their own copy of "what's allowed," they will drift, and the drift is invisible until an audit or an incident finds it. One enforcement function, called from every surface, is the only version of this that stays true by construction rather than by discipline.
Skipping the dry run because it "feels like" extra latency. It's a call that costs nothing and never touches a model — the actual cost saved by skipping it is one round trip, and the actual cost incurred is a live generation call that gets refused anyway, after the more expensive step already ran.
If your product exposes generation capability to agents — through MCP, a plain API, or both — the short version of this piece is five questions:
A "no" to the first two is the gap that matters most, because it's the one an increasingly agent-mediated internet will find on its own, without anyone deliberately looking for it.
This piece sits alongside LikeWard's developer cluster. The rest of it:
This article describes LikeWard's own architecture and cites third-party research on agentic commerce and MCP adoption; it isn't a compliance guide to any specific regulatory regime. For that, see the TAKE IT DOWN Act compliance guide and the UK Online Safety Act piece.
Sources: Anthropic — Donating the Model Context Protocol and establishing the Agentic AI Foundation · Model Context Protocol blog — MCP joins the Agentic AI Foundation · Gartner — Top Predictions for IT Organizations and Users in 2026 and Beyond · Digital Commerce 360 — Gartner: AI agents will command $15 trillion in B2B purchases by 2028