I contributed to MandateFlow with team Cache Me If You Can for TikTok TechJam. We built on the supplied Agent Launchpad starter, adding a provenance-sensitive gateway between an agent and protected tools. My public contributions include the Go gateway and demo hardening. The interesting case was a request that looked reasonable on its own but depended on information the agent was not allowed to use that way.
A permission check can ask who is calling, which tool they want, and what arguments they supplied. Our demo adds another question: where did those arguments come from? Once an agent carries information between tools, its final request can hide a history that matters to the decision. Renaming a value or passing it through an intermediate object should not erase that history.
Two paths into the same destination
- Support → Case → CRM: the support-derived path is allowed in the protected demo.
- Payment failure → Case → CRM: the payment-derived path is denied before the protected tool executes.
- An aggregate recovery path offers a narrower way forward when the specific action is denied.
The intermediate Case is what makes the example useful. If the gateway only inspected the final CRM call, the two paths could look equivalent. Tracking lineage lets the policy distinguish them. This is a property of the demo’s mandate and fixtures, rather than a universal rule about support or payment data. The rule needs to be explicit enough that someone reviewing a receipt can understand why the outcome changed.
The React/Fastify playground gives the agent a disposable runtime, while the Go MCP gateway owns the policy and lineage checks. That division places the enforcement point outside the agent’s conversational explanation. Redacted receipts expose the decision without requiring the viewer to reconstruct the whole conversation or disclose the underlying protected content. The interface becomes a way to inspect enforcement, rather than the place where permission is merely promised.
A recovery path needs its own evidence
One of my demo-hardening changes dealt with incomplete proof. If a live run stopped after aggregate recovery without recording the required fresh support path, it could not publish a completed proof or an unsupported assistant result. Missing rows were labelled as not recorded. That detail matters: a neat-looking answer should not make an unfinished authorization sequence appear complete.
MandateFlow remains a team proof of concept built around protected fixtures. Its useful contribution is a concrete distinction: permission attaches to the history of information as well as the shape of an action. Making that history inspectable also makes failures easier to discuss. A denial, an allowed alternative, and an incomplete proof should each have a recognisable place in the record.