Skip to content

Identity and device security

Tie every agent action that passes through Vekri to a verified person or workload.

Employees' agents sign in through your identity provider, workloads prove who they are with Kubernetes or SPIFFE identities, and access follows directory groups provisioned with SCIM. Deactivate someone provisioned from your directory and their agents lose access on the next request.

The problem

Why it matters.

Agents often run on shared API keys or a developer's personal token. When something goes wrong, nobody can say who the agent acted for, and revoking access means rotating secrets everywhere.
  1. 01

    Sign in with SSO

    Vekri is the MCP authorization server: OAuth with PKCE and resource indicators, federated to your OpenID Connect provider.

  2. 02

    Provision from your directory

    Users and groups arrive with SCIM 2.0; assignments and administrative roles follow groups by their stable ids.

  3. 03

    Bind people to devices

    Bind a device to its user through SSO or an administrator, and require a verified binding for sensitive access.

  4. 04

    Revoke in one step

    Revoking an assignment, a profile or a person's sign-ins, or deactivating them in the directory, fails their next request.

See it work

Step by step.

Identity to resource access
Illustrative data

Your identity provider

OIDC sign-in · SCIM 2.0

ErinEngineering

Deactivated

ws-dev-07 · Claude Code

Signed in as Erin

Vekri Gateway

Identity · assignment · policy

Sign-ins revoked
Device bound to Erin
Assignment: GitHub for Engineering

GitHub

acme/payments-api

Read · executed by the broker

Next request refused

What happens

Capabilities

What Vekri does today.

Each item is in the current release and verified by tests in the product repository, with its limits beside it.
  • Vekri Protect

    Enterprise SSO for employees' agents

    Vekri is the MCP authorization server for Claude Code: OAuth with PKCE and resource indicators, federated to your OpenID Connect provider, so the agent acts as the employee.

    Vekri Gateway (remote MCP) · macOS, Linux

    Limit: Codex is verified against its configuration contract only. SAML sign-in is not available.

  • Enterprise

    Enterprise single sign-on (OpenID Connect)

    OpenID Connect providers per organization (for example Microsoft Entra ID or Okta) for the console, the management API and employees' agents.

    Vekri Control · Vekri Gateway (remote MCP)

    Limit: Verified with OpenID Connect test providers, not a live Entra ID or Okta tenant.

  • Enterprise

    SCIM 2.0 provisioning

    Users and groups provisioned with SCIM 2.0. Deactivating someone ends their sessions and agent sign-ins at once; history is kept.

    Vekri Control

    Limit: Verified with Entra ID and Okta request fixtures, not live tenants.

  • Vekri Protect

    Group-scoped access assignments

    Assign a governed service to a person or a SCIM-provisioned group: which operations, which resources, which policy and for how long. Group membership is read on every call.

    Vekri Gateway (remote MCP)

  • Vekri Protect

    User-device binding

    Bind devices to people through their SSO sign-in or an administrator, and require a verified binding for sensitive access.

    Vekri Gateway (remote MCP) · local MCP gateway · macOS, Linux

    Limit: A binding shows who uses a device; it does not prove that a request came from it. No MDM attestation.

  • Vekri Protect

    Revocation in one step

    Revoke an assignment, a profile or an employee's sign-ins; the next request fails. Deactivating someone in your directory does the same.

    Vekri Gateway (remote MCP) · local MCP gateway

  • Vekri Gateway

    Verified workload identity

    Agents running as workloads prove who they are with Kubernetes service-account tokens, checked with TokenReview, or SPIFFE X.509 certificates from a configured trust bundle.

    Vekri Gateway (remote MCP) · Kubernetes

    Limit: SPIFFE uses X.509-SVIDs from a trust bundle; the Workload API is not integrated.

  • Vekri Control

    Administrative roles

    Organization roles from org-owner to viewer, mapped from directory groups by their stable ids; every route checks its permission on the server, and no one can grant a role, or join a group carrying it, without holding its permissions.

    Vekri Control

Not yet available

  • PlannedSAML sign-in. Signing in with SAML.

Listed so you know where the edges are. Ask us before relying on anything here.

Contact Sales

See Vekri with your own AI applications, agents and systems.

Talk to us about the AI your organization uses, the systems agents reach and how you deploy: in Vekri's cloud, or inside your own Kubernetes cluster.