Lanyard

Identity and access control for AI agents. Every agent gets a badge, every tool call is checked and you can revoke an agent mid-task so its very next call is blocked.

Comment

Inspiration

AI agents now read company files, change data and deploy code on their own. Most of them do it with a bearer token. A bearer token can't be taken back. If an agent reads a poisoned document halfway through a task, it keeps every permission it started with until the token expires, often hours later.

This track asks a question most agent setups can't answer: once an agent is authenticated, how do you stop it mid-task? A VentureBeat survey from September 2026 found that only 14 of about 100 enterprises had someone who could revoke an agent's access within minutes. Lanyard does it on the agent's next call.

What it does

Lanyard is a gateway between AI agents and their MCP tool servers. Every tool call passes through it.

  • Identity. Enterprise agents sign in with Auth0 (OAuth 2.0 client credentials). Agents running on AWS prove who they are with their IAM role and no stored secret; Lanyard issues them a 10-minute token signed by an AWS KMS key that never leaves AWS.
  • Least privilege on every call. Each tool call is checked against Cedar policies in Amazon Verified Permissions. Agents only see the tools they may use, tools with no policy are denied by default and production deploys wait for a human to approve.
  • Revocation mid-task. 1 click revokes an agent's identity. Its next call gets a 403 even though its token is still valid. Lanyard also removes the agent's grant in Auth0 so it can't get a new token. Revoking a parent agent cuts off every sub-agent it created.
  • Protection from poisoned content. Bedrock Guardrails scans every tool response before the model reads it. A prompt injection is withheld and the agent is marked tainted, so anything risky it tries next needs human approval. Emails and phone numbers are masked.
  • Proof. Every decision is streamed to S3 with Object Lock in compliance mode, so nobody can edit or delete the record. The Attack lab runs 9 real attacks against the live gateway. All 9 are blocked.

In the demo, Claude Opus 5.5 on Amazon Bedrock triages support tickets under Lanyard's control. It reads a ticket hiding an instruction to export customer data and deploy to production. Guardrails blocks it before Claude sees it, the agent is tainted and its next write waits for a human.

How we built it

The gateway is a Python FastAPI app speaking MCP, running on AWS Lambda behind a function URL. Every tools/call goes through 6 steps:

  1. Verify the JWT. Each issuer is pinned to 1 algorithm and 1 key set (Auth0's JWKS or Lanyard's KMS public key).
  2. Check revocation in DynamoDB with a strongly consistent read, for the agent and every ancestor.
  3. Ask Amazon Verified Permissions, with the agent, tool and call context as Cedar entities.
  4. Hold the call for a human if an approval policy requires it, re-checking revocation while it waits.
  5. Invoke the tool, a private Lambda with no public URL. Company files live in S3.
  6. Scan the response with Bedrock Guardrails.

Workload identity follows the pattern HashiCorp Vault uses for AWS auth. The agent signs an sts:GetCallerIdentity request with SigV4, with an audience header inside the signature. Lanyard forwards it to STS to learn the caller's role, so the agent never hands over a credential. The gateway reads its own secrets from AWS Secrets Manager. 5 simulated agents with their own IAM roles, triggered by EventBridge, send traffic through the real checks against a fictional company's file share. Locally the same code runs with SQLite behind the same store interface.

Challenges we ran into

  • Revoking something stateless. A JWT can't be recalled, so revocation had to be keyed on the agent's identity and checked first on every call, on every Lambda instance. A consistent read in DynamoDB makes that hold across instances.
  • Approvals nobody could grant. A read-only agent asking for a production deploy was being sent to the approval queue, where approving it still wouldn't allow it. Lanyard now re-evaluates with humanApproved = true before holding a call and denies it right away if approval wouldn't help.
  • Failing closed. If Verified Permissions times out or Guardrails is down, the call is denied. We tested this by pointing the gateway at a policy store that doesn't exist.
  • 2 layers of revocation. Blocking at the gateway stops every call, but an Auth0 agent could still mint fresh tokens. Revoke now also removes the agent's grant through the Auth0 Management API. The demo reset restores it.
  • Replayable identity proofs. A signed STS request works for anyone who holds it. Lanyard only accepts a proof whose audience header is covered by the SigV4 signature, only for roles in its own AWS account, so a proof made for another service can't be used to sign in.

Accomplishments that we're proud of

  • Revocation takes effect on the agent's next call, on every instance, while its token is still valid.
  • A real AI agent runs under Lanyard with an IAM role that can invoke the model and nothing else. Every action it takes on company data goes through Lanyard.
  • All 9 attacks in the Attack lab are blocked on the live deployment, including algorithm confusion, replaying a revoked token and a sub-agent asking for more access than its parent.
  • The audit log can't be deleted during its retention period, even by the AWS account root user.

What we learned

  • Cedar and Verified Permissions make authorization rules readable and changeable without a deploy. Writing approval gates as policies made the human-approval logic much simpler.
  • How to give agents on AWS an identity without handing them a secret, using signed STS requests.
  • How to sign tokens with an asymmetric KMS key and serve its public key as a JWKS endpoint.
  • Revocation has to be built around identity from the start. Short token lifetimes alone don't stop an agent mid-task.

Who it's for

Target users: security and platform teams at companies giving AI agents access to real data and tools, such as fintech, healthcare and SaaS companies running agents on internal systems.

What they get:

  • Revocation that takes effect on the agent's next call, instead of the hours or days most teams in the VentureBeat survey reported
  • Least privilege on every tool call, with policies their security team can read and change
  • No long-lived secrets on agents running in AWS
  • A tamper-proof audit trail for compliance reviews

How it's sold: Lanyard deploys into the customer's own AWS account as serverless infrastructure, so cost scales with usage. Pricing would be per governed agent per month, with a free tier for small teams. In production it would sit behind A10's DDoS and API protection: A10 guards the traffic and Lanyard decides who the agent is and what it may do.

What's next for Lanyard

  • Acting for a user. An agent working for a signed-in user gets the intersection of its own and the user's permissions, through OAuth 2.0 Token Exchange (RFC 8693).
  • Automatic containment. Rate limits per identity and automatic revocation when an agent's denial rate spikes.

Built With

Share this project:

Updates

Submission history