Next film, 2 min 14 s
A partner outside our control runs its own agents under its own root. What do we hold about them, and who can withdraw it?
- Film
- Across the boundary
- Use case
- Across the boundary. With trust.
Films · Journey 4
Our agents run in different places. What should each place be allowed to do?
Chapters 8
Transcript, read from the captions
Hello
Hi, I'm Ralph from Raidiam. Your agents run in the cloud, on laptops and in other people's services. Let me show you one way to trust them all.
Where agents run
Your agents run in more than one place. So do you need a trust model for each? One runs as a workload in your cloud. Another sits on a laptop. A third runs inside a service a vendor operates. Each one is a running copy. A running copy is not an identity. Wherever the agent runs, you govern its identity once. That identity outlasts every copy. What does that look like on a real system?
Your own systems, running
Let me show you. This is a reference implementation of an enterprise catalogue, not Raidiam Connect. Its runtime screen lists the copies running now. Each one holds its own key, generated where it runs. The attester tells copies apart by that key. Stop a copy and its row reads stopped. The identity stays active, and the other copies keep running. So where is that identity governed?
Where the identity is governed
The enterprise governs it here in Raidiam Connect. One governed record for the agent. One set of signed statements, back to the one entity your platform already trusts. Which running names count as this agent? The authority signs them into the record. Is this copy one of ours? The chain answers that, not the machine.
What the ground can prove
So what differs between places? Not the identity. Not the chain. What changes is what the ground can prove about the copy. That decides what its client instance attestation says. A cloud workload domain proves the machine and the workload. A service somebody else operates offers no instance evidence, so the token leaves the claim out. And a laptop? It gives a key and an enrolled person, and nothing about the machine or the binary. So the attester holds that copy to reading records and says why. Same chain. Different assurance.
The chain walk for a runtime
Now the real system again. Here is the same walk for the agent that may run on a laptop. Same authority. Same signed statements. The record says where this identity may run, and it names the attester the enterprise trusts. A platform needs to know nothing about the laptop. It reads what was signed and asks the attester that record names.
One model
Back to where I started. Four runtimes. Do you need a trust model for each? You do not. You need one governed identity. One chain, back to the one entity your platform already trusts. And an assurance that is stated rather than assumed, including when there is none to state. Govern the agent once. Every boundary it crosses gets the same signed answer.
Thanks for watching
One identity, wherever it runs, with policies set by what the ground underneath it can prove. Thanks for watching.
The use case
Wherever it runs, proof sets the ceiling.
Where an agent runs decides what it can prove, and what it can prove decides what it keeps. The attester runs the same fourteen checks for every copy, and the evidence the runtime can present sets the ceiling.