How it works · proof, not keys
Proof travels. Keys don’t.
No shared secrets. Every action authorized, or blocked. The application sends one message with no token, no key, no auth code. Underneath, Layr8 seals it, verifies it, and authorizes it, across any wall: a team, a subsidiary, a partner. The company boundary is just the biggest one.
Every call, decided and recorded.
deny by default · revocation in about fifteen seconds · audit as a byproduct
A copied key proves possession, not identity.
On Layr8A sealed message proves who is asking, and a grant decides what happens next.
Identity lives in the layer, not the app
One agent acts on another’s behalf, across a wall.
The application plane carries business intent only. Everything about who is asking, whether they may, and what was decided lives in the protocol layer underneath.
Layr8 : identity :: TLS : encryption
Illustrative. Org A and Org B could as easily be finance and engineering, or a parent and a subsidiary. The mechanics do not change with the size of the wall. Across a company boundary today: authenticated, audited, revocable invocation by a named counterparty, with signed attestations of each exchange that a third party can verify.
Three steps
Identity is checked. The action is authorized.
Every agent gets a real identity, every message is sealed to it, and every crossing is authorized against policy, or blocked.
Verifiable identity
Each agent carries a W3C DID plus a Verifiable Credential. A cryptographic passport, not a shared password. Minted and held by the node; the application signs nothing.
Identity-addressed message
Messages are encrypted to the recipient’s identity over DIDComm v2. Credentials the call needs stay in the Key Shield; the agent never holds the real key.
Authorized and audited
On arrival: verified, checked against its grant, and recorded in the Space’s decision ledger. Actions beyond an agent’s grant are blocked. Deny by default: a call with no grant behind it simply doesn’t run.
Key Shield
Keys never leave. Nobody ever had one to copy.
The Key Shield is identity-first credential custody. Your API credentials are stored in your tenant. Users and agents prove who they are; Layr8 checks the identity, checks the grant, and makes the call on their behalf. REST APIs, MCP servers, any HTTP endpoint: if it takes an API key, the Key Shield can front it, with no change to the service behind it.
Copy the key for everyone
API keys are house keys, and you are making copies for everyone who needs access. When someone leaves, you change the locks and hand out new keys to everyone else.
- Change the contractor? Change all the locks.
- Hope nobody made extra copies.
- No idea who came and went.
- Give new keys to everyone else.
Control the door
You keep the only key. When someone knocks, you decide whether to let them in. Revoke someone’s access? Stop opening the door for them.
- They just can’t get in anymore.
- Everyone else’s access unchanged.
- Nobody ever had a key to copy.
- Full log of every entry, by identity.
Keys never leave
Credentials stay in your tenant. Contractors, employees, and agents authenticate with identity and never see or touch the actual keys.
Instant revocation
Stop opening the door and access ends. No key rotation, no disruption to anyone else, no guessing.
Audit by identity
Every call logged against who or what made it. Who came through the door, when, and what they did.
Granular permissions
Per user, per agent, per endpoint. Some may enter the living room and not the bedroom.
The MCP gateway is the Key Shield applied to tool calls: every tool an agent reaches is a message whose grant the platform evaluates, and the agent never holds the credential. The same custody works for any API your workflows call.
The paradigm shift · from token to proof
Three ways to trust a workload. Only one needs no federation.
OAuth / OIDC
Honored only where that identity provider is trusted. Crossing orgs means federation: pre-registered clients, shared issuers, trust set up in advance.
SPIFFE / SPIRE
Workload identity, done well, but it cannot leave its domain. Crossing orgs means federation again: trust bundles to swap and keep in sync.
Layr8 · DID + DIDComm
An agent proves itself, across walls. No pre-registered client. No trust bundle to swap. A partner’s agent proves who it is on first contact, then your policy decides what it can do.
You’ve federated a handful of partners. Your agents will need hundreds.
What this gives the security team
Joiner, mover, leaver. For agents.
Joiner
An agent joins by receiving its own identity and explicit grants. No key is issued, because no key is needed. The directory becomes the census.
Mover
A role change is a grant change, per capability, per endpoint. Review means listing an agent’s grants, not archaeology through config files.
Leaver
Pull the grant. Stop opening the door. Access ends in about fifteen seconds, verifiably, and nothing else has to change.
And the evidence: every allow and deny lands in the decision ledger as it happens, recorded by the node, not by the application asking for permission. Audit evidence as a byproduct of operation. JML, explained →
Proof, not keys. Stop giving agents credentials you’d never give a human.
The Agent Identity Layer. W3C DIDs, Verifiable Credentials, DIDComm v2. Open standards, not a proprietary format. And not just for AI: the same layer works for anything that can hold an identity →