Portal Downstream Security And Secret Management

Purpose

This functional area configures how the Runtime securely connects to downstream APIs.

It covers target registration, downstream authentication strategies, credential orchestration, secret handling, and outbound call restrictions.

Main Capabilities

• manage target systems
• manage target authentication profiles
• manage tool endpoint authentication bindings
• manage credential workflow definitions
• manage secret stores and secret-store connections
• manage outbound host allowlists

Target Systems

Target systems represent the downstream APIs that the Runtime can call.

Administrators can define:

• system identity
• base URL
• descriptive metadata
• active or inactive status

This creates the execution destination layer for runtime tool calls.

Target Authentication Profiles

Authentication profiles define how a target system should be accessed.

Supported strategy types include:

• none
• passthrough bearer
• API key from secret store
• basic authentication from secret store
• static bearer from secret store
• client credentials template
• token exchange template, including delegated On-Behalf-Of access
• SOAP username token
• SOAP username token digest
• SOAP custom headers
• client certificate (mTLS)
• workflow-based authentication

This gives the platform the flexibility to work with a wide range of downstream security models, including SOAP services that require message-level credentials or custom SOAP header values, and downstream systems that require mutual TLS.

Delegated Token Exchange And On-Behalf-Of

The token exchange strategy lets the Runtime call a downstream system as the signed-in user instead of as a shared service account. Choosing it reveals a grant profile selector that adapts the exchange to the downstream identity provider:

• Standard token exchange (RFC 8693) — the default general-purpose option.
• Microsoft Entra ID (On-Behalf-Of) — for Microsoft Graph and other Entra-protected APIs.
• JWT bearer assertion (RFC 7523) — for identity providers implementing the plain assertion grant.

Alongside it the form offers:

• Token endpoint, client ID and client secret reference. For On-Behalf-Of these belong to the AI client application's registration — the platform registers no application of its own in the customer's directory. The secret is always chosen from the secret store, never typed inline.
• Scope. Prefer naming the specific delegated permissions the tools need over a .default scope; this is where the downstream token is meaningfully narrowed.
• Fall back to client credentials for application callers. When a caller authenticates as an application rather than a user there is nobody to act on behalf of. Leave this off to fail the invocation with an explanatory message, or turn it on to call the downstream system as the application instead.
• Validate assertion audience before exchanging. On by default for assertion-style grants. It confirms the caller's token was issued for the configured client ID before contacting the identity provider, turning the most common misconfiguration into a clear message rather than an opaque provider error code.

The audience field is hidden for Entra On-Behalf-Of, which ignores it and identifies the downstream resource by scope instead.

Delegated credentials are always isolated per caller, so one user can never be served another user's downstream token.

Credential Caching

The caching card on an auth profile decides whether resolved credentials are reused between invocations, so the Runtime doesn't have to re-acquire a downstream credential on every tool call. Administrators can enable caching and set a time-to-live for how long a resolved credential is kept.

Caching is isolation-aware: the platform automatically adapts what a cached credential may be shared with based on the authentication strategy in use, so a credential resolved on behalf of one signed-in user is never reused for another user. Strategies that resolve a shared, non-personal credential (such as an API key or a service-account-style client credentials grant) can share a cached entry across callers; strategies that resolve a credential tied to the signed-in user, such as delegated token exchange and On-Behalf-Of, are always cached per caller. Passthrough bearer authentication does not support caching at all, since it simply forwards the caller's own token rather than acquiring one. Workflow-based authentication is treated the same way: a workflow that reads the caller's token or identity is cached per caller, while one built only from static configuration is cached and shared like any other non-personal credential. The Portal only offers caching options that are safe for the selected strategy, and switching strategies adjusts the available options accordingly.

TTL seconds caps how long a cached entry is kept. A credential that expires sooner than the TTL is dropped at its own expiry — the TTL is a ceiling, never an extension.

One Secret Field Per Credential

Each strategy that needs a stored secret asks for it exactly once, in a field labelled for that strategy — API key secret reference, Password secret reference, SOAP password secret reference, Client secret reference, or Exchange client secret reference. There is no second "override" picker for the same value.

Client certificate (mTLS) authentication is the one strategy with two secret fields, because it needs two different secrets: the base64 PFX certificate and, separately, the password protecting its private key.

Username fields for Basic and SOAP UsernameToken accept either an inline value stored in the profile or a secret reference, since the username is a distinct value from the password.

Client Certificate (mTLS) Authentication

For downstream systems that authenticate callers by TLS client certificate, administrators can upload a client certificate (PFX/PKCS#12 file) directly in the auth profile form and select the secret holding its private key password. An optional certificate thumbprint can also be entered to confirm the correct certificate is configured. At runtime, the certificate is presented to the downstream API for both REST/OpenAPI/OData tools and SOAP tools.

Tool Endpoint Authentication Bindings

Bindings connect:

• an exposed tool endpoint
• a downstream target system
• an authentication profile

This is the functional point where publication logic meets execution security.

A binding belongs to whoever publishes the tool. It is created and edited from the toolset screen that publishes it, by an operator holding that area's authority, and it references the tool as a registered identity rather than as a text label. There is no separate Security screen for authoring bindings, and no tool identifier to type.

The Security area retains oversight: it can read every binding attached to every tool, across publishers, from the Tool Oversight screen — and can take a tool offline — but it does not author them. Governing a tool and owning it are deliberately separate.

Credential Workflow Definitions

The Portal supports step-based credential workflows for advanced downstream authentication scenarios.

These workflows can describe controlled sequences such as:

• reading input values
• reading secrets
• reading configuration values
• transforming values
• making HTTP requests
• parsing responses
• building a credential set

This makes the platform capable of handling more than static credential injection.

Request body types

An HTTP request step can send its body in one of three formats, chosen per step:

• JSON — the default format.
• Form (application/x-www-form-urlencoded) — required by the OAuth 2.0 token endpoint. Any client_credentials, password, refresh_token, or token-exchange call needs this format.
• Raw — the body is sent verbatim under a content type you declare. This covers SOAP and WS-Trust envelopes, plain text, and other vendor-specific formats.

A form body is edited as a list of named fields you add and remove individually. Each field's value comes from one of three places:

Choosing Secret adds a Read secret step above the request step and binds the field to it. That step is visible in the workflow like any other, and can be reordered or edited. This is deliberate: every secret a workflow touches is read by an explicit step, which is also what lets the platform redact it from audit records. Selecting the same secret for a second field reuses the existing step rather than adding a duplicate.

Secret and variable values are safely encoded into the request body, whether it is form-encoded or XML, so a secret's own content cannot alter the structure of the request being sent.

A worked client_credentials example:

Reading XML responses

A parse-response step reads either JSON or XML. In XML mode the path is an XPath expression, and any prefix it uses must be declared in the step's namespace list — an undeclared prefix never matches. You can extract either the element's text value or the whole element, the latter when the token is an XML fragment that must be forwarded unchanged.

Request and response sizes are capped per deployment, defaulting to 64 KB. Deployments handling large signed assertions can raise the limit in configuration.

Secret Management

The platform supports managed secret usage through:

• platform-managed database-backed secret storage
• Azure Key Vault-backed secret storage
• secret store connection administration
• enabled secret store configuration visibility
• managed-secret encryption rotation

From a functional standpoint, this allows operators to configure downstream access without embedding sensitive values in mappings or tool definitions.

Secret values are never returned through the Portal after creation or update. Operators work with secret metadata, backend selection, tenant scope, and connection references rather than retrieving plaintext values later.

Tenant scoping

A secret resolves inside the tenant that owns it. Logical names are unique per tenant rather than platform-wide, so two tenants may legitimately use the same name; each is served its own value, with a tenant's own secret taking precedence over a platform-shared one of the same name.

A secret belonging to another tenant is not reachable, and is not discoverable either: asking for a name you do not hold answers exactly as asking for a name that does not exist, so no Portal surface can be used to learn what secrets another tenant has.

Bound, not merely named

Where the platform binds a secret rather than referring to one — a target authentication profile, an ESRA source, an A2A push-notification configuration — it stores the secret's identity, not its label. That matters twice over:

• renaming a secret does not silently repoint every binding that referred to it by name
• a binding whose secret has been removed fails at the point of use, loudly, rather than falling back to some other value that happens to share the name

The binding is validated when it is created: a caller cannot bind a secret its tenant does not hold.

Outbound Host Governance

The Portal also manages outbound host allowlists.

This ensures the Runtime can only call approved downstream destinations, which is a key governance and security control for AI-driven execution.

Operational Importance

This area is essential for safe production use because it governs how live credentials and live downstream calls are controlled.