Your Customer's Agent is Untrusted by Definition
As customers bring their own AI agents to services, security models must shift from trusting the model to governing runtime execution and verifiable logs.
Stock photo for illustration only, not from the actual event
- Ali Spittel highlighted the growing trend of users bringing their own AI agents
- Customer-owned AI models are considered untrusted by definition
- Security must shift from controlling agent behavior to governing actionable boundaries
- Audit logs must be independently verifiable to prevent compliance disputes
In August, Ali Spittel captured a major shift with a simple line that has surpassed 700,000 views: users want to use their own agent to interact with your product rather than using your built-in assistant. While the industry's initial response focused on reach—such as shipping MCP servers and designing for agent experience—that represents only the easy half of the equation.
This discussion moves past protocols like MCP, A2A, or REST to examine how security and compliance models change the moment an unfamiliar model calls your product. When shipping your own assistant, you control the model, system prompt, and tools. When a customer brings their own agent, every lever shifts across the wire, leaving you without visibility into the model version, its instructions, or its background connections.
Stock photo for illustration only, not from the actual event
Treating model output as untrusted input is no longer just a design stance; it is the baseline reality when dealing with customer-brought agents. Existing safety tooling—including system prompts, output filters, and evaluation suites—assumes you operate the model. Because you cannot modify a prompt you never see or fine-tune a customer's model, probabilistic filters fall short of compliance demands in regulated industries.
When you cannot govern the model itself, you must govern its boundaries: what the agent can reach, under what conditions, and what proof remains behind. Domain-specific applications like GarageManager demonstrate control designs via MCP or REST that operate independently of whatever model resides on the client side, though every company opening its APIs will face similar implementation workloads.
"i really don't want to use your agent, i want to use my agent to use your thing."
Ali Spittel
This architectural pivot mirrors the rise of Open Finance, where regulated third parties initiate payments with customer consent—exemplified by Brazil's Pix payment initiation framework. However, customer-brought AI agents introduce an unregistered, unpredictable third-party layer. Organizations that rush to integrate external agents without robust compliance controls will eventually face regulatory roadblocks and security incidents.
Furthermore, vendor-controlled logs are insufficient for resolving factual disputes when an external agent causes harm. A robust architecture requires independently verifiable records where each decision is cryptographically chained, allowing customers or regulators to verify integrity without blindly trusting the vendor. Contract-driven runtimes like Zarel aim to solve this by ensuring models only propose actions that predefined, versioned contracts authorize.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment