Sometime sooner than we probably all think, someone is going to ask you to let their agent into your systems. Maybe a vendor, or a contractor or some new product that you want to use.
What would that look like with the technical capabilities that exist today? Likely an API key, GitHub App, or service account.
That type of access for an agent isn't actually sufficient. An agent with an API key for example doesn't know where it should and shouldn't be in a codebase, by default doesn't leave an auditable trail of what it did and if you want to stop it midway and rotate the credentials it is very difficult. At scale this will become a blocker.
We think there is a better way to accomplish this so we set out to build and then run it in the wild.
What we ran
If you read phase one you'll remember the bike analogy: a kid you've never met says your mom said he can borrow your bike. A permission slip you can check yourself beats calling mom, as long as the slip is trusted and verifies that random kid's claim.
This is that, live, but between two companies.
The Ratify Protocol team issued a permission slip to my agent running on Agent Relay. The slip named their repo and one folder inside it. My agent cooked, opened a pull request, and then the Ratify team merged it.
There are a few things from that which are different from an API key. Our side couldn't overclaim what was stated on the permission slip. When my agent passed authority down to a worker of its own, the worker was under even tighter reins and less time to accomplish what it needed to do.
Then the Ratify team revoked the certificate mid-run from their machine in Seattle while my agent still had over three hours on it. Seconds later my agent tried the same commands again and they didn't go through, because of the revocation.
This is the way it should be: a foreign agent when allowed can cook in your repo but if you suddenly want to revoke permission that same agent is blocked within seconds.
Every certificate, every revocation, and the signed receipts are public. The Ratify team's half is in their harness repo, along with the reproduction you can run yourself. Ours is in ours, including the exact container image our deployment was running.
How the agents actually talked
The other difference from an API key is how the revocation worked. The Ratify team didn't call an API to shut my agent off but rather their agent was on the relay and sent a message. A normal agent-to-agent DM on Agent Relay, with the signed revocation tucked into the metadata.
Our agent reads the message but doesn't trust it from the jump. It instead looks at the issuer and the key that we exchanged with the Ratify team on initial setup to verify it.
Which is what makes this easy: one wire, rather than a separate integration with every company you work with. It doesn't even need to be a trusted wire, because the signature does that for us. Just give agents a way to talk to each other and you have what you need.
The Ratify team wrote up the protocol side — the proof format, the SDKs, how to run the reproduction — in their technical note. Go break it and tell us what you find.
If you want to let an outside agent into your systems and can't, we'd like to hear about it. Get in touch.