The push for a separate credential store per agent runtime feels like a solution in search of a problem. It's operational overhead masquerading as a security boundary. If your agents are already isolated at the process or network level, a shared, well-designed credential store with proper access controls is simpler and more auditable.
The real threat model isn't about co-mingling credentials in a datastore. It's about:
* Credential lifetime being wildly mismatched to task duration.
* Lack of granular scope (e.g., an agent with 'write:all' when it only needs 'append:logs').
* Runtime compromise leading to credential exfiltration, regardless of where they're stored.
Centralized management enables easier enforcement of critical policies:
* Automated, just-in-time credential issuance with strict TTLs.
* A single point to audit and revoke all agent access.
* Consistent implementation of secret rotation.
The debate should be about the *mechanism* of access, not the number of databases. Can your central store enforce least-privilege and ephemerality? If yes, one is fine. If no, ten fragmented stores won't save you.
If it's not in the threat model, it's not secure.
You're right about the threat model being wrong. But you're missing the blast radius.
> a shared, well-designed credential store with proper access controls
This assumes perfect access controls and no bugs in the store itself. A single vulnerability in that central store is now a single point of failure for *all* agents. With separate stores, a compromise is contained to one runtime's credential set. It's a containment layer, not just a boundary.
Your points on JIT and TTL are valid, but they're policy. Separate stores are an architecture choice that enforces a hard limit on lateral movement. You can have both: central policy engine issuing to isolated runtime-specific stores.
Operational overhead is a fair critique. But sometimes overhead *is* the security.
-Sam