You would not hand a new hire your master password on day one. But that is effectively what many products do when they connect an AI agent: one API key, broad access, and no declared boundary between a harmless read and an irreversible action.
When a human makes a mistake, you can ask why. When an agent makes one, most products cannot answer the questions that matter: who approved it, which rule allowed it, and what happened after the request reached the API.
The difference is not the model. It is the infrastructure around the model.
The layer products are rebuilding
Login became a product category. Payments became a product category. Agent actions are still something each team assembles for itself: a middleware check here, an approval button there, a log table added after the first incident. Then the product changes and the control layer changes with it.
Duct is the missing layer. It sits between a product and every caller. You define what is allowed once. Risky actions pause for approval. Permissions are explicit. Every execution leaves an evidence trail.
It is not a chatbot, an MCP server, or an API wrapper. It is the permissioned action layer between your product and everyone trying to act in it: a human, an agent, or eventually another product.
Dogfooding it on a live product
We put that premise on Whistler, against real product activity rather than a fresh demo database. The product already had real surfaces, real state, and consequences worth protecting.
Two callers went through the same Duct integration: a person using an embedded Shell, and a third-party AI agent. Neither received a master API key. Both could do useful work within the same declared boundary.
A Shell is not just a chat box
We call the conversational surface a Shell. It understands intent, plans the work, renders product UI when more information is needed, and knows when it must stop and ask a person to approve an action. Duct is the enforcement layer behind it.
That matters because the interface is shifting. Instead of learning every product's navigation, people will increasingly ask for an outcome: “invite the new intern,” “file this feedback,” or “show me last month's invoices.” The Shell can work out the sequence. Governance decides whether that sequence is permitted.
One manifest. Separate decisions.
Before either demo runs, a Duct manifest declares the product surface: which actions exist, who may call them, and what proof is required. It turns one vague question (“does this agent have access?”) into several precise ones:
- Is the action declared? Off-manifest calls do not become product capabilities simply because an agent guessed an endpoint. See action exposure.
- Is this caller allowed? An agent identity proves who is asking; it does not automatically grant authority to act for a user. See third-party identity.
- Does this action need a person now? Side effects can pause for explicit confirmation at the time of execution. See human in the loop.
These are enforcement decisions, not prompt instructions. A model cannot talk its way around a confirmation gate, retry its way into authority, or rephrase an undeclared action into existence.