Move tool credentials out of agents without moving the risk out of sight

Suppose a support agent uses a backend API key stored alongside its application configuration. Several deployments share the key. Rotating it requires coordinated application changes, and investigating its use begins with the shared backend account.

You can move the backend key out of those deployments and onto a governed connection. The agent authenticates to Dome; Dome uses the connection's credential when making the upstream request.

Give the agent its own credential

Dome's data-plane credential model stores upstream secrets server-side and injects them on egress. Agents on that path do not receive the backend secret.

Before
  Agent runtime -- backend credential --> Tool service

After
  Agent runtime -- agent credential --> Dome gateway
  Dome gateway -- connection credential --> Tool service

That's the proposed setup. It doesn't remove old copies of the backend key: you still need to find those and retire the direct route.

Use the authorization decision map for the distinction between credentials and allowed actions. Here, the job is to change how the agent connects without breaking the service or leaving the old route open.

Prepare the cutover

First identify every deployment using the backend credential and the effects its backend account permits. Include scheduled jobs, old environments, and recovery configurations. Avoid copying secret values into the review document.

Then choose the connection's authority model. A shared credential represents one backend account across permitted callers. A per-user credential relationship preserves a different upstream identity for each verified person, where configured and supported. Dome documents both models; neither should be selected merely because it is quicker to demonstrate.

For a support workflow, ask whether the backend must independently evaluate each person's permissions. If so, a shared account may change the authority model even if the application response looks identical.

Switch over in stages

1. Create the governed connection. Store the intended backend credential on the connection and restrict its backend account to the required operations.
2. Prepare agent access. Establish the agent identity, agent-facing credential, gateway membership, admission, and rules for the intended tool.
3. Exercise a synthetic request. Confirm both a legitimate operation and a neighboring prohibited one. Inspect the call’s audit record and check what changed in the backend.
4. Change the deployed client. Point the actual workload at the returned gateway endpoint. Check any retry or recovery path as well.
5. Retire the old direct secret. Remove it from agent configuration and rotate or revoke the old backend credential after dependent workloads are accounted for.
6. Verify the old route. Confirm that the retired credential no longer works. Record any intentionally retained direct integration and its owner.
7. Close the change. Record the new credential owners, rotation procedure, and rollback route without including secret values.

If the old secret was shared with unrelated services, do not revoke it blindly. Either migrate those users together or issue appropriately separated credentials before retirement.

Plan a rollback that doesn't restore broad access

A failed cutover should not silently restore broad direct access. Decide in advance whether rollback means restoring the previous gateway connection configuration, repairing the agent credential, or pausing the workload.

If a temporary direct path is necessary, name the approving owner, scope, and expiry. Treat that as an explicit exception. Otherwise, the next recovery could put the old key straight back into the agent.

Which credential was exposed?

An exposed agent credential and an exposed upstream credential have different scopes.

For an agent-key incident, use the agent key management workflow and inspect which deployed copies need replacement. If trust in the whole workload identity is in question, key rotation alone may be insufficient.

For an upstream-secret incident, rotate or revoke the credential at the backend and update the affected connection. Inspect other services that may possess the same secret. Revoking one agent's key does not invalidate that backend credential.

Credential isolation reduces secret distribution and centralizes a rotation boundary. It does not automatically reduce the backend account's authority or remove credentials the application still holds elsewhere. Before closing the change, show that the new route works and that the retired credential no longer does.