From 6930b264e542a3cd9ce4d1c8fc281acf73037d46 Mon Sep 17 00:00:00 2001 From: Khaliq Date: Tue, 25 Aug 2026 15:56:15 +0200 Subject: [PATCH 1/2] blog: someone else's agent, in your repo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Phase 2 of the Ratify Protocol engagement — the live cross-company run, and the part that is ours: revocation travelling as an ordinary agent-to-agent message rather than a second control plane. Co-Authored-By: Claude Opus 5 --- .../blog/someone-elses-agent-in-your-repo.mdx | 49 +++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 web/content/blog/someone-elses-agent-in-your-repo.mdx diff --git a/web/content/blog/someone-elses-agent-in-your-repo.mdx b/web/content/blog/someone-elses-agent-in-your-repo.mdx new file mode 100644 index 0000000..e290ff1 --- /dev/null +++ b/web/content/blog/someone-elses-agent-in-your-repo.mdx @@ -0,0 +1,49 @@ +--- +title: "Someone else's agent, in your repo" +description: "An API key isn't enough to let someone else's agent into your systems. We ran the alternative live with the Ratify Protocol team: their permission slip, our agent, and a kill switch they held from the other side of the world." +date: '2026-08-25' +author: 'Khaliq Gant' +category: 'Engineering' +tags: + - Agent Relay + - Trust and identity + - Delegation + - Ratify Protocol + - Multi-agent systems +--- + +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 or 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](/blog/trusting-an-agent-you-didnt-spawn) 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 and that 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 when trying to do the same commands didn't succeed 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 immediately. + +Every certificate, both revocations, and the signed receipts are [in the harness repo](https://github.com/identities-ai/ratify-agent-relay-harness). + +## 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](https://ratifyprotocol.com/writing/agent-relay-phase2-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](https://agentrelay.com/enterprise). From f9c119ac3d87f560d47d5a7a31606c58934f15c2 Mon Sep 17 00:00:00 2001 From: Khaliq Date: Tue, 25 Aug 2026 16:28:45 +0200 Subject: [PATCH 2/2] =?UTF-8?q?blog:=20PR=20review=20fixes=20=E2=80=94=20G?= =?UTF-8?q?itHub=20casing,=20grammar,=20link=20both=20evidence=20halves?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5 --- .../blog/someone-elses-agent-in-your-repo.mdx | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/web/content/blog/someone-elses-agent-in-your-repo.mdx b/web/content/blog/someone-elses-agent-in-your-repo.mdx index e290ff1..a19dcf3 100644 --- a/web/content/blog/someone-elses-agent-in-your-repo.mdx +++ b/web/content/blog/someone-elses-agent-in-your-repo.mdx @@ -14,9 +14,9 @@ tags: 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. +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 or 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. +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. @@ -26,15 +26,15 @@ If you read [phase one](/blog/trusting-an-agent-you-didnt-spawn) you'll remember This is that, live, but between two companies. -The Ratify Protocol team issued a permission slip to my agent running on Agent Relay and that named their repo and one folder inside it. My agent cooked, opened a pull request, and then the Ratify team merged it. +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 when trying to do the same commands didn't succeed because of the revocation. +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 immediately. +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, both revocations, and the signed receipts are [in the harness repo](https://github.com/identities-ai/ratify-agent-relay-harness). +Every certificate, every revocation, and the signed receipts are public. The Ratify team's half is [in their harness repo](https://github.com/identities-ai/ratify-agent-relay-harness), along with the reproduction you can run yourself. Ours is [in ours](https://github.com/AgentWorkforce/ratify-agent-relay-evidence), including the exact container image our deployment was running. ## How the agents actually talked