Govern agents behind your corporate IdP

Your security team has already standardised on an identity provider such as Microsoft Entra or Okta, and they are not going to hand that authority to a new system. Yet agents need a verifiable identity of their own, consistent policy, and an audit trail that ties every action back to a known principal, none of which a plain OIDC token provides on its own.

What you can do

• Verify every request against your OIDC provider so that only tokens your IdP issued are accepted, with no second identity store to maintain.
• Derive a portable agent DID from the verified token so that each agent carries a stable, cross-organisation identity keyed to its IdP object id.
• Keep that DID stable across token rotation and across gateways so that rotating credentials never changes an agent’s identity.
• Gate access on the token’s claims so that group or tenant membership decides what an agent may reach.
• Attribute every interaction in one audit trail so that agents, tools, and services share a single record tied to the caller.

How it works

A surface authenticates each request with JWT bearer validation: it checks the token’s signature, issuer, and audience against a verification strategy that points at your OIDC provider’s JWKS, so Entra, Okta, Auth0, or any standard OIDC issuer stays the source of truth. Once the token is verified, the surface derives the agent’s identity from a claim, by default the Entra oid object identifier, and mints one stable did:webvh for that value. Extra claims such as iss and tid namespace the DID across tenants and issuers, and a shared identity-hash pepper makes the same agent resolve to the same DID on every gateway in the fabric, so token rotation never changes it.

From there, an OPA policy on the surface can allow or deny using the token’s claims, for example requiring a group or tenant, and every request is written to the audit log with the caller identity, the agent DID, the policy decision, and a trace id. That gives one attributable record across agents, tools, and services.

A request whose token is missing or invalid is recorded as a failed authentication and denied by policy before it reaches the target, so an unverified caller never receives an agent identity.

Related

• Validate bearer tokens on a surface: Point a verification strategy at your OIDC provider’s issuer and signing keys.
• Use JWT claims to control access to a surface: Write policy that gates access on group, tenant, or other token claims.
• Agent identity and DIDs: How a stable agent DID is derived and verified across organisations.
• Audit log: The single, attributable record of identity and policy decisions per request.