Agent Identity
Every MeetLoyd agent gets a cryptographically verifiable identity -- not just an API key, but a full identity stack based on open standards that any external system can independently verify.
Why Agent Identity?
When agents collaborate across teams, apps, or organizations, the fundamental question is: how does Agent B know that Agent A is who it claims to be, and is allowed to do what it's asking?
Traditional approaches (shared API keys, bearer tokens) don't work for agent-to-agent interactions because:
- Static secrets can be leaked -- a compromised key grants permanent access
- No delegation model -- how do you prove "Agent A is acting on behalf of Agent B"?
- No capability proof -- how does an external system verify what an agent can do?
MeetLoyd solves this with four layers of standards-based identity.
The Identity Stack
| Layer | What It Proves | Standard |
|---|---|---|
| Client Metadata | "Here's who I am" | IETF Client ID Metadata |
| Badge | "Here's what I can do" | W3C Verifiable Credentials 2.0 |
| SVID | "Prove my identity right now" | SPIFFE JWT-SVID |
| Access Token | "Act on my behalf, with these tools" | OAuth 2.0 Token Exchange (RFC 8693) |
Each layer builds on the previous one. Client metadata is the discovery document, badges prove capabilities, SVIDs are short-lived identity proofs, and access tokens enable delegation.
SPIFFE Identity
Every agent automatically gets a SPIFFE identity -- the same standard used by Google, Netflix, and Uber for workload identity. The SPIFFE ID encodes the tenant boundary, ensuring multi-tenant isolation is built into the identity itself.
Client ID Metadata
Each agent has a publicly accessible identity document at a stable URL. This document describes the agent's OAuth identity -- its name, capabilities endpoint, supported grant types, and public keys for verification. External systems fetch this URL to learn about your agent.
The document also includes a signed Badge that cryptographically proves the agent's capabilities.
Badges (Verifiable Credentials)
A Badge is a W3C Verifiable Credential 2.0 signed by MeetLoyd that proves what an agent is authorized to do -- its tools, permissions, and capabilities.
Think of it as your agent's professional certificate, but cryptographically signed and machine-verifiable.
What's in a Badge:
- Agent name and SPIFFE ID
- List of tools the agent can use
- MeetLoyd permissions granted to the agent
- Issuance and expiration dates (180-day validity)
External systems verify badges by fetching MeetLoyd's public keys from the platform JWKS endpoint.
JWT-SVIDs (Short-Lived Identity Tokens)
When an agent needs to prove its identity to another agent or service, it obtains a JWT-SVID -- a short-lived signed token (1 hour default, 24 hours max).
SVIDs are stateless and ephemeral. Agents request new ones as needed. This eliminates the risk of long-lived credential compromise.
External verification: External systems verify SVIDs by fetching the SPIFFE Trust Bundle (a publicly accessible endpoint that returns MeetLoyd's signing keys in JWKS format). Verify the signature, check the issuer, and validate the audience claim.
Token Exchange (Delegation)
Token exchange is how agents delegate -- when Agent A needs to call tools on Agent B, it exchanges its SVID for a scoped access token that proves the delegation.
How It Works
- Agent A has an SVID (proving its identity)
- Agent A requests delegation to specific tools on Agent B
- MeetLoyd checks: Is the SVID valid? Is Agent B in the same tenant? Does Agent A have permission for these tools?
- MeetLoyd issues a scoped access token containing only the tools Agent A is allowed to delegate, with a delegation chain for audit
- Agent A presents this token to Agent B
- Agent B verifies the token and checks the tool scopes
Scope Narrowing
An agent can never delegate more tools than it has access to. If Agent A requests 5 tools but only has permission for 3, the token is issued with only those 3 tools. If Agent A has none of the requested tools, the exchange fails.
This is enforced via MeetLoyd's authorization policies.
Integration with Authorization
Token exchange integrates with MeetLoyd's agent authorization system. When an agent requests delegation, MeetLoyd checks each requested tool against the authorization policies configured for that agent.
If no authorization policies are configured yet (new tenant), all tools are granted by default for backward compatibility. However, if policies are configured but the authorization store is temporarily unavailable, the tool is denied -- this ensures infrastructure failures don't silently grant access.
Trust Bundle
External systems verify all MeetLoyd-signed tokens (SVIDs, Badges, access tokens) using the public trust bundle. This endpoint is public with no authentication required and returns MeetLoyd's signing keys in JWKS format, cached for 5 minutes.
Token Types at a Glance
| Token | Purpose | Default TTL | Signing |
|---|---|---|---|
| SVID | Identity proof | 1 hour | ES256 (ECDSA P-256) |
| Badge | Capability proof | 180 days | ES256 (ECDSA P-256) |
| Access Token | Delegation proof | 1 hour | ES256 (ECDSA P-256) |
Security Properties
- Same-tenant only -- Cross-tenant delegation is not supported
- Scope narrowing -- Can never delegate more than you have
- Short-lived tokens -- SVIDs and access tokens expire in 1 hour by default (24 hours max)
- Stateless -- No token database; tokens are self-contained signed JWTs
- Full audit trail -- Every token exchange is logged
- Fail-closed -- If signing key is unavailable, exchanges fail; if authorization store is down, delegation is denied
- Trust domain enforcement -- SPIFFE IDs must belong to the MeetLoyd trust domain; foreign domains are rejected
- Token type guards -- Only identity tokens (SVIDs) and user JWTs are accepted as subject tokens for exchange
Tool-Based Access Control (TBAC)
TBAC is the enforcement layer for delegated tool calls. When Agent B receives a delegated call from Agent A (via a token exchange), TBAC verifies the full chain before allowing execution.
How It Works
- Agent A exchanges its SVID for an access token scoped to specific tools
- Agent A sends the access token to Agent B
- Agent B calls the authorization endpoint for a triple-check: Is the token valid? Is the tool in the token's scope? Does a TBAC policy allow this?
- Returns allowed or denied
TBAC Policies
Policies control which agents can invoke which tools on which callees, with support for wildcards:
| Rule | Meaning |
|---|---|
| Agent A can call get_payments on Agent B | Specific agent-to-agent-to-tool rule |
| Agent A can call get_payments on any agent | Wildcard callee |
| No agent can delegate delete_records | Global tool deny |
The most specific matching policy wins. At the same specificity level, deny overrides allow.
Default Behavior
When no policy matches, the behavior depends on the tenant's enforcement mode:
| Mode | Default | Use Case |
|---|---|---|
| Audit | Allow (log only) | Rolling out TBAC, observing patterns |
| Warn | Allow (log + alert) | Transitioning to enforcement |
| Enforce | Deny (fail-closed) | Production enforcement |
This is the same rollout pattern as authorization policies, letting you adopt TBAC gradually.
Combined with governance packs and authorization policies, agent identity gives enterprise customers cryptographic proof of agent behavior for compliance audits.