Credential Blast Radius Isolation

Every action that mutates state carries attribution to a specific identity. Identities are never shared across humans, machines, or agents. Attribution is captured at the time of action, never reconstructed after the fact.

A credential shared across runtimes is not a convenience — it is a shared blast radius. When one runtime gets compromised (and one of them will, eventually), every other runtime that shares that credential is also compromised. Revocation becomes a binary choice: revoke and take everything down, or leave the compromised credential active and bleed.

The architectural answer is per-runtime credentials with surgical revocation boundaries. If the MCP server is compromised, you revoke only the MCP server's credential. The Claude Code session, the scheduled exports, the API gateway — all continue operating.

Each credential is scoped to the minimum permissions required for its runtime to function. A credential that "could do more" but only needs to "do less" is a credential that gets exploited beyond its intended use.

Scope is enforced server-side, not by trust. The server validates each request against the credential's scope before executing. A credential that omits a required scope returns 403, not 200-with-side-effect.

Common scoping mistakes

• "Read all" instead of read-specific. Read access to all resources is not the same as read access to the resources the runtime needs.
• "Write" without targeted scope. A credential that can write anywhere can be exploited to write everywhere.
• "Owner-equivalent" service accounts. A service account with owner permissions is a permanent backdoor.
• Long-lived tokens for short-lived sessions. A 90-day PAT used for a 30-minute task creates 89 days of exposure surface.

Revocation is the test of isolation. Ask: "If credential X is compromised at noon, what runtimes are affected at 12:01?"

If the answer is "the one runtime that holds X," the isolation is correct. If the answer is "all runtimes that share X," the isolation has already failed and you discovered it by stress test rather than by incident — which is the better order to discover it.

Revocation checklist

1. Identify the compromised credential's runtime class and identifier.
2. Verify no other runtime references the same credential.
3. Generate a successor credential with a versioned identifier (e.g. machine:mcp-server-v2).
4. Update the runtime to use the successor.
5. Revoke the original at the credential authority.
6. Log the revocation event with reason, replacing identifier, and timestamp.

For any system with multiple AI runtimes:

• Enumerate all runtimes. Each gets its own row in a credentials registry.
• Assign each runtime its identity class (human, machine, agent, system).
• Issue a per-runtime credential with minimum required scope.
• Confirm no two runtimes share the same credential. If they do, this is a shared blast radius that must be split.
• Document the revocation procedure per runtime. Test the procedure in a non-incident window.
• Track credential expiry. Renewal is a deliberate action, not auto-renewal.

Any system with more than one runtime that touches sensitive state. The cost of implementation is one extra row in a credentials registry per runtime. The cost of not implementing it is total compromise from a single incident.

Anti-pattern: "We'll just rotate the shared token periodically." Rotation without isolation does not prevent the cross-runtime exploit window between incident and rotation.