Machine Identity for the AI Era: Building Doppel API V2 With OAuth 2.0

At Doppel, our API (opens in new tab) enables customers to bring the investigation and disruption workflows available in Doppel Vision into their own systems. With it, they can submit suspicious URLs, check alerts, and request takedowns programmatically.

The nature of API integrations is changing, however. Scheduled scripts are becoming complex production services, often with multiple autonomous agents that act on behalf of an organization, not a specific user. These systems need their own form of identity and guardrails around their automated use.

Our customers commonly have policies for non-human accounts, credential rotation, and auditability, so when we thought about how automated authentication should function in the AI era, we wanted to treat machine identity as first-class to ensure the best security practices. In API V2, authentication keys now rotate automatically and can give customers the capability to limit the scopes of a particular workload.

We adopted the OAuth 2.0 Client Credentials (opens in new tab) flow to create that machine identity layer without forcing customers to rewrite their integrations. Existing V1 traffic continues to work unchanged, while V2 introduces organization-level machine authentication behind the same resource contracts.

OAuth limits where durable secrets can be used, and that limitation is why it's perfect for agentic use cases. Normal API traffic uses an expiring access token associated with a dedicated service account and organization, reducing the blast radius of a leaked LLM tool call.

Machine identity in the AI era

Static API keys work well for straightforward automation. The difficulty grows when a workload is no longer one script running in one predictable environment. An agent may decide when to call an API, run in ephemeral infrastructure, or invoke several tools.

Permanently embedding an API key into every runtime makes the credential, the permissions, and the workload difficult to separate. For Doppel and our customers, agents need auditable access guardrails and expiring authentication windows just like logins for human users.

OAuth Client Credentials gives machine identity this clear boundary by design. Each V2 client ID is associated with its own dedicated Doppel service account. Unlike CLIs and scripts which authenticate on behalf of a user's credentials, Doppel authenticates the machine itself. Every access token identifies both the service account and its organization, so an automated integration has an explicit per-client identity every time it calls Doppel.

A conventional backend can obtain and refresh its own token using the client credentials, but an agentic integration with the Doppel V2 API can designate a separate process as responsible for retrieving the OAuth credentials on its behalf. The important distinction is that application code manages credentials, but the agent does not need read access to a client secret.

We're not alone in this move to machine-level OAuth; this pattern is showing up across the industry. Databricks documents OAuth M2M (opens in new tab) for service principals running automated tools and CI/CD workflows. Similarly, Microsoft describes Client Credentials (opens in new tab) as a common pattern for daemons and service accounts. The Model Context Protocol authorization specification (opens in new tab) also builds on OAuth for remote HTTP servers. The pattern is consistent: use explicit identities and expiring access tokens instead of placing permanent API keys in every agent runtime.

What OAuth means for Doppel

OAuth 2.0 is a framework for issuing access tokens to clients. In Doppel's case, there is no user login or browser redirect. A customer's backend uses the Client Credentials grant, which is intended for machine-to-machine communication.

A customer configures a client ID and client secret for its organization. The customer service sends those credentials to Doppel's token endpoint and receives a bearer access token, which is only valid until the exp in the token. The service caches the token, attaches it to API requests, and obtains a replacement before it expires.

Each client ID maps to a dedicated Doppel service-account user. When the client obtains an access token, the signed JWT contains both that service account's user ID and its organization ID:

{

  "doppel_org_id": "{REDACTED}",
  "doppel_user_id": "{REDACTED}",
  "iat": 1784124771,
  "exp": 1784211171,
  "gty": "client-credentials"
}

V2 derives its user and organization context from those signed claims. Customers no longer need to combine credentials with a separate organization-selection header, and every integration receives a dedicated identity instead of relying on either a human user's key or a shared organization-wide key.

The Client Secret remains sensitive. It still needs secure storage and customer-defined rotation. The improvement is separation: the durable secret is used to obtain tokens, while normal API traffic uses an automatically expiring credential.

From machine identity to scoped access

Tenant-bound service accounts are the first layer, not necessarily the last. Once every integration has an explicit machine identity, the same OAuth model gives us room to introduce finer-grained authorization scopes without replacing the authentication system again.

For example, a future integration might be allowed to read alerts but not request takedowns, or submit new alerts without accessing the organization's wider investigation history. An agent built for triage should not automatically receive every capability available to a takedown workflow simply because both belong to the same organization.

V2 gives us somewhere to add these permissions transparently; scopes can be associated with a machine client, represented in its token, and enforced by the API. This matters for both traditional automation and agents. As agents become more capable of deciding which actions to take, least-privilege access becomes more valuable, not less. Explicit identity tells us which workload is acting; scopes can eventually define what that workload is allowed to do.

Why this required V2

Doppel's V1 API already handles significant customer traffic. Changing its authentication contract in place would have forced every customer to update on our schedule. Adding OAuth as a second authentication scheme to the same version would avoid an immediate cutover, but it would leave every V1 endpoint with two identity models and two sets of organization semantics.

V2 provides a clean boundary:

• /v1/ uses static API-key authentication.
• /v2/ uses OAuth bearer-token authentication.

Customers can migrate one integration at a time while existing V1 traffic continues to use the contract it was built against. Every V2 resource request enters through the new authentication layer, so the version itself communicates which identity model applies.

We kept the rest of the migration intentionally small. Across the customer-facing API, V2 preserves V1 request bodies, query parameters, response shapes, and pagination. Migration means obtaining a token, replacing the authentication headers, and changing /v1/ to /v2/.

We also enforce that compatibility in our CI by comparing the V1 and V2 OpenAPI specifications operation by operation. The check allows authentication-related differences but fails when client-visible request or response structures drift unexpectedly.

The new machine-to-machine flow

The complete flow adds one token exchange before normal API requests:

V1

static API key(s) + optional organization header

|

v

/v1/resource

V2

client ID + client secret --> /oauth/token --> expiring access token

|

v

Authorization: Bearer <token>

|

v

/v2/resource

For a resource request, the visible change is small:

# V1

curl "https://api.doppel.com/v1/alerts" \
  --header "x-api-key: <ORG_API_KEY>" \
  --header "x-user-api-key: <USER_API_KEY>"

# V2

curl "https://api.doppel.com/v2/alerts" \
  --header "Authorization: Bearer <ACCESS_TOKEN>"

Token acquisition and refresh should be automatic. A trusted customer service caches the token and renews it before expiration rather than requesting a new token before every API call. For an agent integration, that trusted service may be the agent runtime itself or the tool layer through which the agent reaches Doppel.

Owning the authentication boundary

We use a managed identity provider to issue and sign tokens, but customers call https://api.doppel.com/oauth/token (opens in new tab) rather than a vendor-specific hostname.

That layer keeps identity-provider details out of customer code. Doppel can change the infrastructure behind the endpoint without changing the public token contract and forcing another customer migration.

It also gives us one place to apply policy around token issuance. We can rate-limit abusive minting independently of ordinary API traffic and measure outcomes without recording client secrets or access tokens. We get managed signing infrastructure without making its deployment details part of every integration.

Conclusion

API V2 is more than a new header. It gives every automated integration a dedicated machine identity, binds that identity to the correct organization, and replaces permanent credentials on normal API requests with expiring access tokens.

That model fits the integrations customers run today and the agent-driven workflows they are increasingly using in production. It also creates a path toward finer-grained API scopes as those workloads become more autonomous. We introduced this foundation without breaking V1 traffic or asking customers to rewrite the API logic they already depend on.