Runtime Credential Resolution

Purpose

This functional area obtains the downstream credentials needed to execute a tool securely.

Main Capabilities

• bearer passthrough
• secret-backed credential lookup
• templated credential generation
• delegated token exchange, including On-Behalf-Of, so the Runtime can act on a downstream system as the signed-in user
• workflow-based credential assembly
• credential result caching when the selected strategy allows reuse
• runtime classification of delegated caller credentials versus application credentials
• propagation of redaction metadata for downstream audit logging

Supported Credential Sources

• platform-managed secrets
• Azure Key Vault-backed secrets
• configured environment, configuration, and file-based providers
• workflow-produced values carried across multi-step credential resolution

Supported Credential Material

Resolved execution material can include:

• HTTP headers
• query parameters
• cookies
• transport authentication material such as bearer, basic, or API-key values
• SOAP message security material such as UsernameToken, UsernameTokenDigest, and custom SOAP headers
• mTLS client certificate material presented on the TLS handshake, for downstream systems that authenticate by client certificate rather than headers
• target-system base URL information for relative endpoint execution

Delegated Access (On-Behalf-Of)

An AI client can call a downstream system as the signed-in user rather than as a shared service account. The client sends the Runtime a token it is able to validate, and the Runtime exchanges that token for a downstream token before making the call. The downstream token never transits the AI client, and the user's own permissions — not an application-wide credential — bound what the tool can do.

This is configured on a target authentication profile using the token exchange strategy together with a grant profile, which selects the shape of the exchange the downstream identity provider expects:

Behaviour that applies to every delegated profile:

• The caller must send a token addressed to the configured client application, not to the downstream API. For assertion-style grant profiles the Runtime checks this before contacting the identity provider and reports the mismatch in plain terms, naming both the audience it saw and the audience it expected.
• Application callers. When the caller authenticates as an application rather than a user there is no one to act on behalf of, and the invocation fails with an explanatory message. A profile can opt into calling the downstream system as the application instead.
• Failures are explained, not just reported. A rejection from the identity provider surfaces the returned error code together with an actionable hint — missing consent, wrong audience, expired assertion, invalid client secret — while the caller's own token is redacted out of the message.
• Cached credentials are never shared between users. A delegated credential is always cached per caller, whatever caching scope the profile declares. When no caller identity is available, the credential is not cached at all.
• The caller's token is treated as a live credential. It is never persisted and never appears in an audit record.

Microsoft Graph reference configuration

The exchange is performed as the AI client application; the platform registers no application of its own in the customer's directory. On the AI application's existing Entra registration:

1. Expose an API with an App ID URI of api://{ai-app-client-id} so the application can hold tokens addressed to itself.
2. Grant the delegated Graph permissions the tools need (for example User.Read, Mail.Read). In most cases these are already consented, because the application already calls Graph as the user.
3. Create a client secret and store it in the platform secret store. The profile references it; it is never entered inline.

The client sends the Runtime a token whose audience is the AI application itself. Applications with a backend already receive such a token and can forward it unchanged; single-process applications acquire one alongside the Graph token they already hold, which is a silent call on the same signed-in account rather than a second sign-in.

On the trusted identity provider entry, set the allowed audiences to both api://{ai-app-client-id} and the bare client id, and the allowed client ids to the same application. Because the platform is deliberately accepting a token minted for another party, those two pins are load-bearing controls rather than optional hardening.

Prefer naming the specific delegated permissions in the profile's scope over a .default scope: this is the point at which the downstream token is meaningfully narrowed relative to simply forwarding the caller's token.

Credential Caching

Resolved credentials can be cached so a tool invocation does not re-acquire one on every call. Who a cached credential may be shared with is decided by the authentication strategy, not by the caching configuration — the two must never disagree, because sharing a credential that belongs to a user leaks it, while isolating one that every caller shares acquires an identical credential per user and isolates nothing.

Each strategy therefore falls into one of three groups, and the Portal offers only the cache scopes that group supports:

Passthrough bearer is excluded deliberately: it forwards the caller's own token and acquires nothing, so caching would store a live user credential without saving any work.

Credential workflows are classified by what they do. A workflow that reads the caller's token or identity produces a per-user credential and is isolated per caller; one built only from configuration and the secret store is shared. This is determined from the workflow's own steps, so two workflow-based profiles can sit on opposite sides of it. A workflow that cannot be analysed is treated as per-user — the safe direction.

TTL is a ceiling, not an extension. A cached entry is kept for the configured TTL or until the credential's own expiry, whichever comes first. A credential that declares no expiry of its own is kept for the TTL.

Changing a workflow's steps changes the classification of every profile that uses it, and the Runtime re-derives it on every resolution rather than trusting stored configuration — so isolation cannot fall out of date.

Functional Value

This area separates AI-facing tool use from raw credential handling, which is essential for secure enterprise execution.