Trust
You are granting a vendor visibility into your clients' credentials. This page explains exactly what EzKey can and cannot do.
What EzKey reads
EzKey's connectors list metadata: application registrations, credential names and expiry dates, Key Vault item properties, storage account key ages. For Microsoft tenants this comes from read-only Graph roles and Azure Reader access. EzKey never retrieves a secret value from your clients' tenants.
What EzKey refuses by design
EzKey never calls listKeys on a storage account. Retrieval evidence comes from Azure's own activity log instead. SAS tokens are never enumerated. During onboarding, role assignment happens with your administrator's own sign-in session; that token is held in the session only, expires within minutes, and is never written to storage.
How stored secrets are protected
When you choose to store a secret with EzKey, it is sealed with authenticated encryption, keyed per tenant. Revealing it requires a role that permits reveals and a written reason. The audit record is written before the secret is decrypted, so a reveal can never happen without a trail. Reveals are rate limited.
Tenant isolation
Client data in EzKey lives on scope-owned models whose manager refuses to build a query without a client in context, so one client's credentials cannot surface in another's pages, findings, or webhooks. Your organization gets its own subdomain, and each connection you route through the secrets gateway gets its own hostname.
Accountability
Every change your team makes lands in an append-only audit chain. Roles control who can manage tenants, reveal secrets, or change delivery. Ownership and attestation cycles keep every key claimed by a person, on a schedule.
Your data
EzKey stores what you register, what your connectors report, and the operational records that make the audit trail meaningful, such as the address a reveal came from. We do not sell or share your data. Deletion and export are handled on request.