Why every integration credential in Nexus is replace-only, never read back

A common admin-panel pattern is to store a saved API key or webhook secret and show it back to you later, sometimes masked, sometimes in full behind a "reveal" click. It is convenient, and it is also a design that assumes the only thing that needs protecting is the credential's value in transit. It ignores that a "reveal" button is itself a standing capability an attacker who compromises a session, an admin account, or a support tool inherits for free.

Every integration credential in Nexus — an API key, a webhook secret, a service account token — is write-only from the moment it's saved. You can replace it. You cannot retrieve it, not through the UI, not through support impersonation, not through an export. If you've lost track of a key, the answer is always to generate a new one and paste it in, the same motion as rotating it deliberately.

Why replace-only is the safer default, not just a stricter one

• It removes an entire class of exposure: a reveal endpoint is a target regardless of how well it is access-controlled, because access control can be misconfigured, bypassed, or abused by a legitimate but compromised session.
• It removes the insider-view risk: nobody on our side, including someone with full admin access to the platform, can pull a client's stored credential and read it — the encryption and the interface are both built so that path doesn't exist, not just so that it's logged if used.
• It makes rotation the path of least resistance instead of an inconvenience: if the only way to change a key is to replace it, "we rotate keys regularly" stops being a policy someone has to remember and becomes the only way the feature works.
• It matches what a security-conscious client actually wants to hear: the honest answer to "can Nexus staff see our integration secrets" needs to be no, structurally, not "we have a policy against it."

A "reveal" button is a capability, not a convenience. Removing the capability is a stronger guarantee than promising not to use it.

Underneath the replace-only interface, every stored secret is encrypted at rest, scoped per tenant, and never exists in plaintext outside the moment it's written or actively used by the integration it belongs to. None of this is unique to any one integration — it's the same pattern for every credential Nexus stores on a tenant's behalf, and it's a pattern worth asking any vendor about directly: not "do you encrypt secrets," which almost everyone will say yes to, but "can your own staff read one back." That second question is the one with a real answer.