examples/

Legant examples

Runnable demonstrations of what makes Legant an agent-identity layer, not just another OIDC server. None of these require a database or Docker.

conductor — one agent, many MCP servers, a verifiable receipt for every call ⭐

go run ./examples/conductor
# or
make demo-conductor

The flagship. One AI agent (agent:conductor) is wired to a fleet of four MCP servers — repo, analytics, payments, deploy — behind one Legant gateway. Alice grants it a single delegation: the tools read_file, create_comment, query, status, and nothing else. Each upstream independently verifies its downstream token with the public sdk — no callback to Legant.

What the run shows, end to end:

This is the per-tool MCP gateway (internal/mcpgw) — Legant's most differentiated primitive — turning "connect an agent to 20 MCP servers" from "hand out god-mode keys" into "every tool call individually authorized and provable."

honeytool — catch prompt injection by the tools an agent reaches for

go run ./examples/honeytool
# or
make demo-honeytool

Intrusion detection for the agent era. Front an MCP server with the gateway and salt it with honeytools — tools the agent was never delegated, left visible in tools/list as bait. A well-behaved agent never touches them; a prompt-injected one that reaches for exfiltrate_secrets is denied and leaves a tamper-evident, provenance-stamped forensic record (user:alice → agent:summarizer → (attempted) exfiltrate_secrets) — without ever touching real data. The run feeds the agent a poisoned document and watches the wire trip.

leash — give your AI your accounts for one hour, then yank it

go run ./examples/leash
# or
make demo-leash

The consumer kill-switch. Alice leashes her assistant for one hour: ≤ $400, travel/rideshare only, enforced offline at each merchant via the sdk — no callback to Legant. A prompt injection ("buy a $400 gift card, book a $900 suite") is declined at the merchant (wrong category / over the cap), because the limit is a signed constraint, not a prompt rule. A sub-agent inherits an even shorter leash ($50, rideshare-only). Then Alice revokes — and not only can no new token be minted, but the tokens the assistant and its sub-agent are already holding are refused at the merchant, offline, because each merchant polls Legant's signed revocation feed (/.well-known/revoked). The kill-switch bites in-flight tokens within the poll interval — never longer than the short token TTL, and with no per-call callback to Legant.

charter — an agent-run company where the org chart IS the authority graph

go run ./examples/charter
# or
make demo-charter

A founder grants a CEO agent a weekly budget; the CEO re-delegates thinner slices to Growth and Ops, which re-delegate again — rendered as a live authority tree. Every dollar is bounded by a delegation no agent can exceed, and re-delegation can only ever attenuate. Drop Growth's budget from $500 to $50 and the whole subtree shrinks: the same $150 Bid spend that was approved now bounces offline at the ad platform with the full founder → CEO → Growth → Bid provenance — because a child can never out-spend its parent.

agent-obo — an AI agent acting on behalf of a user

go run ./examples/agent-obo
# or
make demo

The scenario

Alice uses a finance SaaS. She delegates a narrow, constrained slice of her authority to her Expense Assistant AI agent:

The agent exchanges that delegation (RFC 8693 token exchange) for a short-lived composite token and calls a Finance API — a separate resource server that holds only Legant's public key and never talks to Legant or a database at request time.

{
  "sub": "user:alice",                         // the resource owner
  "act": { "sub": "agent:expense-assistant" }, // who is actually acting (RFC 8693)
  "scope": "expenses:read expenses:submit",    // attenuated to what was delegated
  "aud": ["finance-api"],                       // bound to one resource (RFC 8707)
  "cnst": { "max_amount": 500, "categories": ["travel","meals"] }
}

What it proves

Every decision is enforced offline by signature + scope + constraints, and the resource server can prove exactly who acted for whom down the whole chain.

Why this is the differentiator

A plain OIDC/OAuth server (Keycloak, Ory, Zitadel) can authenticate an agent and issue it a token. It cannot express "this agent may act for Alice, but only to submit travel/meal expenses under $500 for the next hour, and any sub-agent it spawns can only ever do less." That delegation + constraint + provenance model is the part of the AI-agent identity problem the incumbents are still racing to standardize — and it's the wedge Legant is built around.

The logic lives in internal/delegation (unit-tested, no I/O dependencies) so the same code backs both this demo and the real /oauth2/token token-exchange grant.

mcp-gateway — an agent calling an MCP server through Legant

go run ./examples/mcp-gateway
# or
make demo-gateway

Three roles in one process — the agent (holding a delegated token), the Legant gateway, and an upstream MCP "weather" server:

The key move is in step 1: the gateway never forwards the agent's token. It mints a fresh, minimally-scoped token bound to the upstream's audience (confused-deputy protection), narrowed to exactly the one tool — while preserving the sub/act provenance so the upstream still knows who it ultimately acts for. The production gateway is internal/mcpgw (legant gateway), which adds DB-backed revocation and per-call audit on top of this flow.

What these demos map to

Built and tested in the platform: the RFC 8693 token-exchange endpoint (/oauth2/token) backed by delegation_chains + consent + revocation, multi-hop re-delegation, RFC 8707/9728/7591 + CIMD, and the legant gateway MCP auth-gateway.