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:

spiffe://meetloyd.com/tenant/{tenantId}/agent/{agentId}

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:

GET /api/v1/identity/agents/{agentId}/client-metadata.json

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 (see below) 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.

Issuing an SVID:

POST /api/v1/identity/agents/{agentId}/svid
Authorization: Bearer {your-jwt}
Content-Type: application/json

{
  "audience": "spiffe://meetloyd.com/tenant/{tenantId}/agent/{targetAgentId}",
  "ttlSeconds": 3600
}

Verifying SVIDs externally:

External systems verify SVIDs by fetching the SPIFFE Trust Bundle:

GET /.well-known/spiffe/trust-bundle

This returns MeetLoyd's public signing keys. Verify the SVID's signature against these keys, check the issuer is https://meetloyd.com, 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

1. Agent A has an SVID (proving its identity)
2. Agent A calls MeetLoyd's token exchange endpoint:
   - "I want to use get_payments and list_accounts on Agent B"
3. MeetLoyd checks:
   - Is Agent A's SVID valid? ✅
   - Is Agent B in the same tenant? ✅
   - Does Agent A have permission to use these tools? ✅ (via authorization policies)
4. MeetLoyd issues a scoped access token:
   - Signed by the platform key
   - Contains only the tools Agent A is allowed to delegate
   - Includes a delegation chain (act claim) for audit
5. Agent A presents this token to Agent B
6. Agent B verifies the token and checks the tool scopes

The Exchange Request

POST /api/v1/identity/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token={agent-a-svid}
&subject_token_type=urn:ietf:params:oauth:token-type:jwt
&audience=spiffe://meetloyd.com/tenant/t1/agent/agent-b
&scope=tools:get_payments tools:list_accounts

The response contains a signed access token:

{
  "access_token": "eyJhbGciOiJFUzI1NiIs...",
  "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "tools:get_payments tools:list_accounts"
}

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 with insufficient_scope.

This is enforced via MeetLoyd's authorization policies.

Token Introspection

To check if an exchanged token is still valid:

POST /api/v1/identity/oauth/introspect
Authorization: Bearer {your-jwt}
Content-Type: application/json

{
  "token": "eyJhbGciOiJFUzI1NiIs..."
}

Returns { "active": true, "sub": "...", "tools": [...], ... } or { "active": false }.

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 you've granted Agent A the Contributor template on a CRM integration, it can delegate CRM read/write tools — but not delete or export tools it doesn't have.

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:

GET /.well-known/spiffe/trust-bundle

This endpoint is public with no authentication required. It returns MeetLoyd's signing keys in JWKS format, cached for 5 minutes.

Token Types at a Glance

MeetLoyd issues three types of signed tokens, distinguished by the typ header:

Token	Header typ	Purpose	Default TTL
SVID	JWT	Identity proof	1 hour
Badge	vc+jwt	Capability proof	180 days
Access Token	at+jwt	Delegation proof	1 hour

All signed with ES256 (ECDSA P-256) using the platform key.

Security Properties

• Same-tenant only — Cross-tenant delegation is not supported. Agents can only delegate to agents in the same tenant.
• 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 verified against the trust bundle.
• Full audit trail — Every token exchange is logged in the authorization decisions audit log.
• Fail-closed — If the signing key is unavailable, exchanges fail. If the authorization store is down, delegation is denied. If TBAC encounters an internal error in enforce mode, the call is denied.
• Cryptographic key IDs — All key identifiers use crypto.randomUUID() (not Math.random()).
• Runtime claims validation — Exchanged tokens are validated for required claim types at runtime, not just JWT signature verification.
• Bounded caches — All in-memory caches have size limits and TTLs to prevent unbounded memory growth.
• Trust domain enforcement — SPIFFE IDs must belong to the meetloyd.com trust domain. Foreign trust domains are rejected.
• Token type guards — Subject token validation rejects vc+jwt and at+jwt tokens — 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

1. Agent A exchanges its SVID for an access token scoped to specific tools (P3)
2. Agent A sends the access token to Agent B
3. Agent B calls the ExtAuthZ endpoint:
   POST /api/v1/identity/authorize
   { "token": "eyJ...", "tool": "get_payments", "callee": "agent-b" }
4. MeetLoyd performs a triple-check:
   - Is the token valid? (signature, expiry, claims)
   - Is the tool in the token's scope?
   - Does a TBAC policy allow this?
5. Returns allowed (200) or denied (403)

TBAC Policies

Policies control which agents can invoke which tools on which callees. They support wildcards (*) for flexible rules:

Rule	Meaning
(agent-a, agent-b, get_payments) → allow	Agent A can call get_payments on Agent B
(agent-a, *, get_payments) → allow	Agent A can call get_payments on any agent
(*, *, delete_records) → deny	No agent can delegate delete_records to any agent

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.

Enterprise

Combined with governance packs and authorization policies, agent identity gives enterprise customers cryptographic proof of agent behavior for compliance audits.

---

Next: Learn about authorization policies to control what each agent can access, or see the API reference for all identity endpoints.