Connect · Agent identity

Every agent action,attributed.

Give every AI agent a real identity. Sessions authenticate through your IdP, every tool call is authorized against grants you can read, agents run on short-lived task-scoped credentials, and every allow-or-deny decision is logged with a name attached.

Explore the platform Talk to us

Trusted by Verizon

01 · The problem

Agents multiply what one person can do. Accountability has to keep up.

Most gateways

Who's driving?: One shared service account for every agent
Allowed to make this call?: A server-level allowlist, the same for everyone
Who can answer later?: “The agent used the service account”

With agent identity

Who's driving?: A real user, signed in through your IdP
Allowed to make this call?: Policy scoped to the person, the system, and the action
Who can answer later?: The named user and the exact rule that allowed it

MoonPay — Thierry Dang
Security Operations

02 · How it works

From intent to action,
under a name.

Speakeasy resolves identity, evaluates policy, issues scoped credentials, and records the decision. The agent makes the call.

Identity resolves first

Every session binds to a composite identity: the person from your directory, the agent workload, the client, and the task at hand.

Everything that follows is scoped to that resolution.

Federated across Okta, Entra, and any SAML / OIDC

Every agent has an owner and named operators

Deprovisioned users lose agent access the same hour

Identity resolution

WHO

sarah@acme.org

Okta SSO

AGENT

forge.bot

owner: sarah@acme.org

CLIENT

Claude Code

OAuth 2.1 + PKCE

TASK

fix-rate-limit

session b9bc2922

Composite identity resolved

In the product

One roster. People and agents.

Workforce lists every identity that touched a tool: employees, their agents, and anything unattributed. Hover any actor and the attribution is right there, from the person and the agent to the grant and the scopes.

All · 164Employees · 127Agents · 34Unknown · 3

ActorTypeSessionsTool callsStatus

Sarah KimEmployee411,079active

forge.bot / Sarah KimAgent1282,410active

Tiago SilvaEmployee633,695active

releasebot / unattendedAgent22784active

unknown · 172.20.4.11Unknown217review

Anatomy

Anatomy of an attributed agent

Before: shared service account

SHARED ACCOUNT

AGENTS + USERS

someoneidentity unknown

svc-agent@acmeone key, every agent

INTENT

STATIC ALLOWLIST

SERVER CONFIG

allow github.*
allow slack.*
allow postgres.*
allow * # TODO tighten

RAW TOKEN

OVER-SCOPED

github MCP

slack MCP

postgres

datadog

NO TRAIL

14:32:07svc-agent@acme · 2,847 calls todayWHO?

14:31:58svc-agent@acme · refunds.createWHO?

With Speakeasy: attributed

1 · IDENTITY

AGENTS + USERS

Sarah Kimsarah@acme.org · Okta

forge.botattested workload

INTENT

2 · POLICY

SPEAKEASY GATEWAY

identityresolved

policy · billing-v3allow

credentialttl 23m

audit→ stream

3 · SCOPED

TOOLS + SERVICES

github MCP

slack MCP

postgres

datadog

4 · AUDITED

14:32:07sarah@acme.org · github.contents.writeALLOW

14:31:58forge.bot / Sarah Kim · postgres.query.readALLOW

Agents prove who they are

The person signs in through your IdP; the agent workload is attested. Together they form the composite identity.

Policy at the gateway

Every tool call is evaluated against rules scoped to the person, the system, and the action.

Short-lived, task-scoped credentials

Agents never see raw secrets. Credentials are identity-bound and expire with the task.

Every action attributed

Allow and deny both land in the audit stream under a real name from your directory.

The model

Identity lives in the control plane. Credentials never do.

Speakeasy holds the agent's name, its owner, and its grants, plus a rule saying that an assertion from a trusted issuer is that agent. It holds no secret for it and cannot reissue one.

PrincipalWhat an agent is

An agent is a first-class principal, organization-scoped, with an owner who is accountable and named operators allowed to drive it. Every existing permission applies to agents with no new machinery.

agent:7f3a… · owner: sarah@acme.org · operators: [role:platform]

AttestationHow it proves it is itself

Four attestation classes (platform identity, a registered key, your IdP, SPIFFE) all terminate in the same token exchange. The runtime never branches on which was used.

private_key_jwt · IdP assertion · SPIFFE JWT-SVID

DelegationOn whose authority, with which credential

A standard RFC 8693 exchange mints a session whose subject is the person and whose actor is the agent. That full tuple of tenant, subject, actor, and tool resolves to exactly one upstream credential, or an error. It fails closed, never into a fallback.

sub: user:sarah · act: agent:forge.bot → one credential | error

AttributionWhat gets recorded

Actor, delegator, grant, attestation class, and credential provenance land in audit as first-class dimensions, not log strings.

actor · delegator · grant · attestation · provenance

Where it lives

The principal: name, owner, operatorsSpeakeasy · durable

The authority: what it may do, for whomSpeakeasy · until revoked

The credential: proof it is that agentNever stored · minutes

The record: who did what, on whose authorityAudit · retained

Signs in through Okta

Any SAML / OIDC

03 · The results

Accountability you can measure

Putting identity in front of every agent moves the numbers security cares about.

100%

Agent actions attributed

Every action recorded under a named person from your directory.

Shared service accounts

Agents inherit identity from the person driving them.

2 days

To roll out org-wide

Sign-in through the IdP you already run, with nothing custom to build.

Questions

What is agent identity?

Agent identity ties every AI agent session to the real person driving it. Each session authenticates through your identity provider rather than a shared service account, every action is checked against that person's roles, and every decision is recorded under their name. When security asks who issued a refund, the answer is a named user and the rule that allowed it.

How do agents authenticate through our IdP?

Agent traffic stays anonymous until the person behind it signs in. The agent's client, whether Claude, Cursor, or a custom harness, starts a standard OAuth flow, and the person signs in through your identity provider. Speakeasy supports OAuth 2.1 with PKCE and dynamic client registration, so modern clients work without custom integration.

Which identity providers are supported?

Okta, Microsoft Entra ID, Auth0, WorkOS, Google Workspace, Ping Identity, and any SAML or OIDC provider. With Directory Sync connected, users, groups, and attributes stay current, and deprovisioned users lose their agent access immediately.

What does the audit trail capture?

Every authorization check records who made the call as a directory identity, what access was required against which system and tool, and whether the outcome was allow or deny. Each record carries the caller's directory snapshot from the moment of the call, so the answer holds up even after roles change. See the governance guide for the full authorization path.

AI everywhere.

Control here.