Who may send vs API key rotation hygiene

People permissions and API key hygiene look adjacent in a launch ticket, yet they answer different questions. Who may send is a roles map: which seat can submit production SMS, approve a campaign, or open an export.

IOSOR keeps the split hard. Granting a console role does not rotate a webhook secret. Rotating a secret does not grant send.

Separate seat grants from secret lifecycle

Seat grants answer who may click Send, Approve, or Export. They belong in roles-access reviews with named owners and a least-privilege matrix.

” The roles ticket lists seats and verbs. The Developers ticket lists secret owners, rotation windows, and cutover evidence.

Who may send is a role question

Sending production SMS spends prepaid holds and leaves an audit trail on the live path. The seat that may send must be explicit: campaign ops, on-call messaging, or an automation identity with a documented owner. Read-only finance, KYC reviewers, and export clerks must not inherit send from a shared admin role.

When someone leaves, revoke send before you rotate their laptop. Key rotation does not replace seat revocation — a departed engineer with a still-valid role can mint a new key if the seat still allows it. Partner admins on white-label surfaces need the same clarity: portal roles stay people maps, not a shortcut to production key paste.

Rotation and cutover stay on the Developers path

Webhook secret rotation without downtime, sandbox vs production keys cutover, and launch hygiene for keys are Developers jobs. They need dual-run windows, smoke on the new secret, and a cutover checklist that does not depend on who holds Export. If a role change includes “also rotate the API key,” route rotation to Developers. Roles-access closes when seats match verbs; Developers closes when the new secret is live and the old one is retired. Keep partner surfaces out of the rotation path.

Refuse hybrid grants that paste keys into role tickets

A spreadsheet that lists “Admin — has production key” trains the org to treat seats as key vaults. Publish two artifacts: the roles matrix (person → verbs) and the Developers key register (secret → owner → last rotation). When a partner asks for a send-capable login plus the live key in one email, answer with two links: roles-access for the seat, Developers for cutover.

Related ops paths

• Webhook secret rotation without downtime
• Sandbox vs production keys cutover
• Partner surface gate: no brand leak

Start with IOSOR

Audit your console seat permissions today to separate user sending rights from API credential management. Assign human roles strictly through your team access matrix while routing key rotation schedules into developer workstreams. Verify that no raw credentials or webhook secrets are stored inside seat provisioning tickets or operational logs.

IOSOR takeaway

Human seat grants answer who may trigger messages or view reports, while API key hygiene governs service credential lifecycles. Conflating user seat provisioning with secret management creates severe security risks and degrades operational accountability.

Do maintain a strict separation between user access matrices and developer key registers with documented owners and cutover windows. Don't permit hybrid grants or spreadsheets that paste production secrets alongside human role approvals.