Credentials & Permissions

“Every button is greyed out or disabled”

Your account has the agency-scoped moderator permission, not admin. Moderators get full read visibility across the entire dashboard, but every mutating action — saving client config, buying credits or seats, inviting or removing team members, managing webhooks, editing chatbot settings, submitting an agent request — is hidden or disabled. This is enforced independently on almost every dashboard page, so it isn’t a single missing permission you can toggle; it’s the intended behavior of the moderator role.

Fix: ask a teammate with admin permission to either perform the action or promote you from Settings → Team. A member can’t promote themselves. See Team permissions within a Partner.

“A credential resolved to the wrong value”

Every credential (except Twilio and Postgres, which have no client-scoped override in most agent flows) resolves through a fixed waterfall, checked in this order:

1. The client’s own credential — set from their own Settings → Credentials.
2. Your agency-wide default — set from Settings → Integrations.
3. AgentLane’s own platform key — only for anthropic and openai, and only if neither of the above is set.

The most common surprise: a client that used to have their own Cal.com or Resend key set (even if nobody remembers setting it) will keep using it forever, silently overriding whatever you change at the agency level. Check that client’s own Settings → Credentials page first before assuming your agency-wide default is broken.

GET /credentials marks a row inherited: true when it’s actually just showing the agency’s default rather than a client-specific override — use that to tell the two apart quickly. See API Access → BYOK Credentials Vault for the exact response shape.

“A credential shows Configured in the request dialog, but I never set anything”

This is expected for anthropic/openai specifically — those two providers silently fall back to AgentLane’s own platform key when neither you nor the client has set one, so the request-agent dialog’s credential checklist marks them “Configured” even with nothing on file. Every other provider (Twilio, Cal.com, Resend, Postgres) has no platform fallback, so “Configured” for those always means a real key exists somewhere in the waterfall.

“Provisioning failed because of a credential, but I already set it”

If you set the credential at the agency level but the client has their own (possibly stale or invalid) override, provisioning uses the client’s — not yours. See Provisioning failures for what each specific error message means.

Secrets never round-trip back to the browser

By design, once a credential is saved (Anthropic key, Twilio token, Postgres password, etc.), the Portal never sends it back to any browser again — not yours, not the client’s. If you need to verify a key is correct, you can only overwrite it with a fresh value and watch whether the next pre-flight check (or a real execution) succeeds; there’s no “reveal” action anywhere in the product.