Credential isolation

Credential isolation keeps a service credential out of the calling application's runtime. A separate trusted component uses that credential to connect to the service. An agent can authenticate to an intermediary without receiving the database password or provider key that the intermediary uses downstream.

The design changes where a secret is stored and exposed. It does not remove the downstream credential or automatically narrow the operations that credential permits. For Model Context Protocol (MCP) deployments, OWASP's security guidance recommends scoped credentials and careful token handling across services.

Explore Dome: Tool Gateway · Docs: Tools gateway.

Two credentials protect two different connections

Suppose a reporting agent retrieves sales figures through a gateway. The agent has a credential accepted by the gateway. The gateway has a credential accepted by the sales service.

Secret injection adds the backend credential when the trusted component sends the request, without returning the credential to the calling application.

The agent credential remains sensitive. If it is stolen, an attacker may be able to make the requests permitted to that agent. Isolation keeps the backend credential out of the workload, but the application still needs limits on what it can request.

Also inspect where credentials could be copied indirectly: logs, error messages, environment dumps, traces, or tool results. Moving a key out of source code is helpful, but insufficient if a debugging endpoint returns it.

Dome's Tool Gateway documentation describes backend credential injection without exposing those credentials to the agent.

Explore Dome: Tool Gateway · Docs: Agent identity.

Check which connections a credential change affects

Credential rotation replaces a credential with a new one. The replacement procedure also needs to define when the old credential stops working.

Rotating the agent's credential changes how it authenticates to the gateway. Rotating a shared backend credential can affect every connection that uses it. Revoking one does not necessarily revoke the other.

For the reporting agent, ask what happens under three conditions:

• Its gateway credential is exposed.
• The sales-service credential is exposed.
• The agent is retired but other jobs still need the sales service.

An exposed sales-service credential may require a rotation across every connection using it. An exposed agent credential may only require changes to that agent's access. Retiring the agent can leave the shared backend credential in place for other jobs.

Record who owns each credential, the order for replacing it, when the change takes effect, and how to check that the old credential no longer works. Do not infer revocation timing from a dashboard state change.

Explore Dome: Agent Registry · Docs: Manage agents.

Decide whether callers share a backend credential

A shared backend credential is simpler to manage, but several callers may appear to the backend as one identity. Separate credentials for each user or agent can let the backend distinguish them, but someone must issue, replace, and revoke those credentials. The right choice depends on the backend's access model and the application's requirements.

Delegation is a separate question from where a credential is held. Passing a verified user's identity in the request does not automatically make a shared backend credential act on that user's behalf. The backend needs to recognize that identity and enforce the appropriate access checks.

For model calls, trace the same two connections: application to broker, then broker to provider. Name the owner of each credential and test its replacement procedure. Dome's Model Broker documents this separation for routed model traffic.

Explore Dome: Model Broker · Docs: LLM gateway.