​

Sharing Secrets

Share a secret with an external party the way you’d share a password in 1Password — but with three things a password manager can’t do:

• They never see the value. By default the recipient can use the secret (KnoxCall injects it into their API calls) but can never read the raw key.
• It’s locked to approved destinations. The secret can only be sent to hosts you choose (e.g. api.stripe.com). It cannot be exfiltrated to a URL the recipient controls.
• You can stop instantly. Revoke a share and the recipient loses access on their very next request — no rotation, no waiting.

Because there is a single canonical copy of the secret (yours), any change you make — a rotation, a new value — is instantly live for everyone you’ve shared it with. Nothing to re-send.

---

​

How it works

1. From a secret’s Sharing tab, you invite someone by email and pick:
   • an access level (below),
   • the destination domains the secret may be used against,
   • which environment’s value to share.
2. The recipient gets an email with a claim link. They are never added to your workspace — instead they sign up for (or sign in to) their own KnoxCall workspace, where a linked secret appears.
3. In their workspace, the linked secret behaves like any other secret in their routes — but it holds no value of its own. At request time KnoxCall resolves it to your canonical value, injects it, and (if it’s a use only share) never exposes it.

​

Access levels

Revealing a shared value takes the same fresh step-up verification as revealing any secret in the recipient’s own workspace (an authenticator code, a passkey or a security key, once per reveal), from the Owner, an Admin, or an Editor with Reveal secrets turned on. It is recorded as plaintext.reveal in both workspaces’ audit logs before the value is decrypted: the recipient’s entry names the person, and yours (the owner’s) names the recipient workspace. If either entry cannot be recorded, the reveal is refused. Use only is the headline capability — grant the ability to use a credential without ever handing over the credential itself.

​

Who can create a readable share

Creating a Can view or Can manage share lets the recipient read the value in their own workspace, so it is a reveal. In the dashboard this is a Class B reveal: only an Owner or an Admin can do it (an Editor cannot, even with Reveal secrets turned on; that setting covers secret values, certificates and credentialed workflow tests only), and every use asks for a fresh second factor (an authenticator code, a passkey or a security key; an emailed code does not count). Each use writes a plaintext.reveal entry to the audit log before anything is shown, and counts against the same per-person reveal budget as showing a secret’s value (60 per 5 minutes). If the audit entry cannot be written, or the budget cannot be counted, the request is refused rather than served. Shares are created in the dashboard only; the Management API (/v1) has no share endpoint. A Use only share is not a reveal: the recipient never sees the value and the domain lock bounds where it can be sent, so creating one is unchanged.

​

Domain-locking

Domain-locking is required by default. When you share a secret you choose the destinations it may be injected toward:

• exact hostnames — api.stripe.com
• a single wildcard label — *.example.com (matches a.example.com, not the apex)

At request time, KnoxCall checks the resolved upstream host against this list before sending anything. If a recipient points a route at a host you didn’t approve, the request is refused and the value is never transmitted. Choosing “any domain” is possible but is an explicit, audited opt-out — for a use only share it removes the only thing preventing the recipient from forwarding the value to themselves, so we don’t recommend it.

​

Revoking

Open the Sharing tab and choose Stop sharing on any recipient. Access ends immediately — the check happens on every request, uncached. Deleting a secret that is actively shared prompts you to revoke those shares first (or to revoke-and-delete in one step).

---

​

What “never see the value” actually means (the honest version)

This is important to state plainly. Linked secret sharing is recipient-opaque, platform-trusted, and destination-constrained — it is not zero-knowledge:

• Recipient-opaque: the value is never revealed to the recipient through any product surface, and it never leaves KnoxCall toward a destination you didn’t approve.
• Platform-trusted: KnoxCall’s control plane decrypts your secret server-side to inject it (exactly as it does for your own routes today). The “never reveal” guarantee is an authorization + destination boundary, not a cryptographic one.
• Your kill-switch: if you use customer-managed keys (BYOK), sealing your KMS revokes every share instantly and cryptographically — nothing can be injected.

In short: the recipient can use the credential against the destinations you allow, and can never see it or send it elsewhere — but they are trusting KnoxCall to hold the key, the same as you are.