Client Credential Vault
Encrypted storage for client-supplied credentials used during onboarding and delivery work
What the Vault Is For
The Client Credential Vault is where sensitive client-provided access details are stored when the agency needs them to complete work. This includes things like domain logins, DNS access, or provider requests tied to delivery.
It is not meant to be a random catch-all password drawer. It exists for real operational handoff inside the platform.
Common Credential Types
| Type | Why it is used | Example |
|---|---|---|
dns_login | The team needs domain or DNS access | GoDaddy, Namecheap, Cloudflare |
domain_request | The client wants the agency to buy or set up a domain | Domain purchase approval |
sms_request | The client needs messaging setup help | Twilio request or setup handoff |
email_request | The client needs email or workspace setup help | Google Workspace or mail hosting request |
Status Flow
Credentials move through a simple lifecycle:
| Status | Meaning |
|---|---|
pending | Submitted by the client and waiting for agency action |
in_progress | Someone on the agency team is actively handling it |
resolved | The work is complete |
cancelled | The request is no longer needed |
Typical flow:
pending -> in_progress -> resolved
pending -> cancelled
How Clients Submit Credentials
In the portal, the client usually submits these details from the part of the workspace tied to the task, such as website, DNS, or communications setup.
Typical flow:
- The client opens the related setup area.
- They fill in the required credential or request form.
- The platform encrypts the payload.
- The encrypted record is stored in the vault.
Sensitive payloads are encrypted before storage so the database is not holding plain text secrets.
How Agency Operators Use the Vault
When the agency needs to act:
- Open the relevant client and delivery area.
- Review the vault item status and metadata.
- Access the credential only if it is needed for the task.
- Perform the work.
- Update the status so the rest of the team knows where it stands.
Keep status updates current. That is what turns the vault from a secret bucket into a usable operations tool.
Do not paste decrypted credentials into chat, docs, tickets, or logs. Use them only long enough to finish the task that requires access.
Security Model
The vault is designed around a few simple rules:
- credentials are encrypted at rest
- transport should stay on secure HTTPS routes
- client access is scoped to that client's own records
- agency actions are logged
- sensitive access should stay limited to the people doing the work
Troubleshooting
| Problem | What to check |
|---|---|
| Client cannot submit the request | Check that the client is in the right onboarding or delivery state. |
| Decryption fails | Verify the correct encryption key is available in the environment. |
Item stays in pending too long | The agency needs an operator to pick it up and move it forward. |
| Team is unsure whether work is done | Review the status and audit trail before asking the client again. |
Operator Advice
Treat the vault like a controlled handoff tool, not a convenience feature. The goal is to finish the client task with the least possible exposure of sensitive information.