Your customers will ask who holds their keys.
If your product runs AI agents on your customers’ accounts, that question turns up in the first security review. AgentValet can be the answer underneath your product: agents that do the work without ever holding a key, a check on every call, and a record your customers can read.
Most products that put agents to work end up building their own answer, and it tends to look the same: one token per customer sitting in an environment variable, a log table nobody signs, and an approval step that lives in a chat thread. It holds up until a customer’s security team asks for evidence, or until an agent does something it was never meant to.
AgentValet does that job properly, underneath you. The governance is live today and it’s what every AgentValet account runs on: each call is checked against what that agent was granted, credentials sit in a vault under the organisation’s own key, and every decision gets a signed receipt. The partner layer, the API your product would use to run a tenant for each customer, is designed but not built yet. That’s why partnership is by application, and why this page tells you which parts are which.
Where the line sits
We stay out of your product’s business on purpose. Agreeing this early is what keeps a partner from turning into a competitor.
You own the product and the relationship
- Your interface, your brand, your pricing
- Which agents run and what they’re asked to do
- The commercial relationship with your customer
- Anything your implementation partners build on top
We own the governance underneath
- Checking every call, with nothing allowed until it’s granted
- Holding credentials, kept separate for each organisation
- The append-only audit trail
- Revocation, child agents and the circuit breaker
You can start before the partner API exists.
If your product exposes tools through an MCP server, the open-source MCP broker puts the same check inside it today. Wrap the server once, and every tool call is checked against a policy file and written to an audit log. The agent never sees the downstream secret. It’s MIT licensed and runs without an AgentValet account.
Point the same options at a hosted AgentValet account and the policy, the approvals and the audit move to us. Handing out short-lived credentials from our vault isn’t built yet, so for now the broker reads secrets from your side.
npm install @agentvalet/mcp-broker
import { broker } from "@agentvalet/mcp-broker";
// Wrap once. Every tool registered after this is checked and recorded.
broker(server, {
policy: "file:./policy.yaml",
secrets: "env:",
audit: "jsonl:./audit.log",
});What you’d be embedding
What runs in production today, and what’s still planned. We’d rather you knew the difference before you apply.
| Capability | Status |
|---|---|
| Per-call authorisation, deny by default, per agent and per scope. | Live |
| Credentials stored per organisation under that organisation’s own key, decrypted in memory only at call time. Never returned, never logged. | Live |
| An append-only audit trail of every call, with a signed receipt on every decision. | Live |
| Child agents with enforced scope attenuation following RFC 8693: a child only gets a subset of its parent’s access. One level deep today. | Live |
| Circuit breaker on repeated failures, plus cascading revocation. | Live |
| Dynamic client registration (RFC 7591), AuthZEN policy evaluation, ToIP TRQP v2 authorisation and recognition queries, and a W3C did:web document per agent. | Live |
| 25 live platforms, plus custom scopes where there’s no native OAuth. See the platforms | Live |
| A partner credential for your product, issued once through a single-use link. | Planned |
| Creating a tenant per customer from your product, over an API. | Planned |
| Reading each tenant’s audit trail back into your own interface, over an API. | Planned |
How partnership works
It’s by application, not signup. We set each partner up by hand, because the commercial terms, the data processing position and the volume are different every time.
Apply
Tell us what you’re building and roughly how many customers you expect. The form takes a couple of minutes.
We talk
A short call about where the boundary sits, what you’d be metered on, and what your customers’ contracts ask of a subprocessor.
Your partner credential Planned
Issued once through a single-use link, shown once, and never stored in a form anyone can read back.
A tenant per customer Planned
Your product creates a tenant for each customer, connects their accounts, and reads their audit trail back into your own interface.
Apply
I read every application myself. If what you’re building isn’t a fit, I’ll tell you so plainly rather than leave you waiting.
If it is a fit, you’ll be talking to the person who wrote the code, and you’ll hear exactly which parts of this page are running today.
Edwin Ashdown, founder, Brisbane
Application received
Thank you. Edwin reads every application rather than routing it to a queue, so you’ll hear back from a person.
Expect a reply within two business days. If it’s urgent, email [email protected] and say so.