Corey James- ~350vendor operations visible to managed agents, each rebuilt as my own tool
- 0credentials held by any agent
- 2 hostsattribution and webhook delivery proven end to end
I wanted AI agent teams to run small experimental businesses: take payments, send email, publish to social platforms. The moment you hand an agent a vendor API key you have three problems. The key leaks into logs. You cannot say afterwards which assignment created which customer or post. And the vendor's events, a payment, a reply, a bounce, have no way back to the team that caused them. I built one governed gateway between agents and vendors that solves all three. It exposes several hundred vendor operations to managed agents, every one attributed, with no agent ever holding a key.
The challenge
Each provider publishes an API for exactly these services. Handing an agent a client for it is easy and wrong: a raw key in an agent's context is a key in a transcript, and a crash between "called the provider" and "wrote down that I did" either double-charges a customer or loses track of a charge. Several businesses had to run at once, isolated from one another, with a human keeping authority over launch, money and concept.
Constraints
Three provider APIs with hundreds of operations between them, only some of which accept the metadata attribution needs. Crash safety across a network boundary. Isolation, so agents for one business cannot act for another. And human authority over financial actions and launches.
My approach
One gateway, and identity from the caller. The gateway knows which governed assignment an agent is working under because the agent authenticated as that assignment, so no tool argument can claim to be someone else. Attribution is written into a vendor payload only where that exact operation, under that exact API version, has been shown to round-trip it; everywhere else attribution is kept on my side. Each business is one long-running governed work order with its own repository, subdomain, provider namespace and mailbox.
What I built
Every provider operation rebuilt from the provider's API as a tool contract of my own, under stable namespaces, so agents see one steady surface across providers.
Durable accounting around every call, so a restart does not repeat a provider call.
Per-provider capability tables listing which operations round-trip attribution and which do not.
- Operation shown to round-trip attribution under this API versionstamped in the vendor payload
- Operation that accepts metadata but has not been checkedmutation left off
- Operation the table has not classified yetkept on my side, still accounted
Returned-object extraction, so the customer, price or post a vendor created is captured and tied to the assignment that created it.
A signed, durable webhook return path that delivers the vendor's events, in frozen batches, to the mailbox of the team lead whose assignment caused them.
Three binding tools for agents that derive their assignment identity on the server side, so an agent cannot bind a website or mailbox for a business that is not its own.
A public site with provenance-tracked generated media and a readiness checklist.
Difficult decisions
Leaving a mutation disabled. The email and customer-relationship provider accepts metadata on some operations. Until I had checked which ones round-tripped it correctly, the gateway left that mutation off.
Attribution that might be silently dropped is worse than none.
Leaving an unclassified operation unattributed. When a provider adds an operation the capability table has not classified, the tool still works and the call is still accounted, and attribution waits until that operation's contract has been checked.
Replacing the first version. The initial design put shared key files on agent seats. It worked and it was wrong. The second version holds credentials server-side only.
Keeping the money with a human. Financial authority stays with me.
Results
Attribution and webhook delivery were proven end to end on two hosts, with no credential on any agent seat.
Technologies used
Rust · Model Context Protocol · OAuth 2.0 and JWT identity · PostgreSQL · Webhook signature verification · TypeScript · Tunnelled ingress · AgentOS governance
What this demonstrates
Security-first integration architecture. I remove the confused-deputy problem by design, keep accounting that a restart cannot duplicate across a network boundary, and own both the tools, rebuilt from each provider's API, and the governance layer that makes it safe for agents to use.