Security model and OAuth standards

This section explains how Weldall secures access to company systems. At its core is one simple rule: The agent never gets to see any credentials. All tokens are managed inside the CLI, are short-lived, and are bound to a device.

This security model builds on open OAuth specifications. Specifically, it combines an Identity Assertion JWT Authorization Grant (ID-JAG) with a DPoP-bound JWT Authorization Grant. The specifications are openly documented and can be reviewed by independent parties.

The problem: long-lived credentials

Anyone building an application to be used by agents might, without special guidance, hand out API tokens or comparable passwords. Whoever holds such credentials once can use them over and over, even from another device. Lost or compromised keys must be revoked, and permissions are hard to trace because they are not tied to a user.

Weldall avoids this by designing access as short-lived, sender-bound, and centrally controlled.

The trust chain at a glance

The diagram above shows the full flow between the employee, the Weldall CLI, the Weldall Authorization Server (AS), the company IdP, and the downstream service. In detail:

1. Generate a device key – On first start, the CLI generates a key pair and stores it in the protected operating system storage.
2. Sign in through the company SSO – The CLI opens the sign-in in the browser. The employee authenticates with their existing company identity.
3. Exchange the authorization code – The CLI exchanges the code for access, ID, and refresh tokens using PKCE and DPoP. The tokens are bound to the device key.
4. Rotate the refresh token – On every renewal, the CLI sends the refresh token together with a DPoP proof and receives a new access token plus a rotated refresh token. A refresh token that has already been used becomes worthless.
5. Resolve the service – The CLI queries the AS resource registry to learn which resources and scopes are granted for this employee.
6. Chain the identity (ID-JAG) – For the requested service, the CLI exchanges the refresh token for a signed ID-JAG.
7. Obtain a downstream token – The CLI presents the ID-JAG to the downstream AS using the JWT DPoP grant (urn:ietf:params:oauth:grant-type:jwt-dpop). The AS verifies that the DPoP proof matches the assertion’s cnf.jkt and issues an access token bound to the same device key for this service.
8. Send the request – The CLI sends the request with the token and DPoP proof directly to the service and returns only the business response to the agent.

Why the agent never sees a token

The agent runs weldall request and receives only the service’s response. It knows neither the tokens in use nor the device key. This rules out two ways in which credentials could otherwise leak:

• No leak through the context. If a token entered the agent’s context, it could escape through logs, transmission, or a prompt token dump. Because the agent never sees the token, it cannot enter its context in the first place.
• No forwarding through the chat. An agent cannot send a token in a chat response because it does not hold it at all. Even an otherwise intercepted access token would be worthless: it is bound to the CLI’s device key via DPoP and cannot be used on another device.

Even if something did leak, it would not last long: tokens are short-lived, and DPoP replay protection makes them valid for exactly one request. An intercepted token therefore loses its value quickly.

Central access control

Whether and for what an employee is authorized is decided by the authorization server. Before each request, the CLI checks:

1. whether the target URL belongs to a registered service,
2. whether the requested scope is supported for this service and granted to the employee.

Weldall logs granted and denied access. Administrators can trace who requested access to which resource and can adjust permissions centrally.

OAuth specifications in use

Specification	Purpose
Identity Assertion JWT Authorization Grant (ID-JAG)	Chain the identity through the trust chain down to the downstream service
JWT Authorization Grant with DPoP	Exchange a device-bound ID-JAG assertion for an access token bound to the same key
Native OAuth clients (RFC 8252)	Sign in through the browser with a loopback callback
PKCE (RFC 7636)	Exchange an authorization code for a client-verified code
OAuth security best practices (RFC 9700)	Current best practices for secure OAuth flows
Sender-constrained tokens with DPoP (RFC 9449)	Bind access and refresh tokens to the device key

Further reading

• How the components work together is shown in A complete agent run.
• Secure backend services with their own identities under Machine-to-machine authentication.
• Fetch metadata and signing keys through a trusted proxy: Discovery proxy.