A contractor request does not make chat a safe place for keys

Describe the action before deciding what to grant

Keep the request itself as a work item: what the contractor intends to inspect or change, in which account, for which store, and who authorized that task. A request for “the payment keys” leaves each of those questions unanswered. Record whether the work is a Dashboard action, an application connection or a question that can be answered from non-sensitive configuration information.

The request should be narrow enough to compare with available permissions. Ask which action is blocked and why existing access cannot perform it. If the contractor only needs an owner to confirm a setting, the owner may be able to provide that confirmation without granting continuing access. If the task requires work inside the account, select the authorized route that supports that work rather than sharing the owner’s login.

A publishable key and a secret key do different jobs

Stripe documents publishable keys for front-end use and says they cannot create charges or read account data. Secret keys have unrestricted permissions. Restricted keys limit permissions but remain sensitive. Stripe says secret and restricted keys must not be shared through email, chat or other unencrypted channels. Do not treat the word “restricted” as permission to paste the value into the project conversation.

Record the category of credential requested, not its value. If the requester cannot identify the category or purpose without receiving the key first, keep access unresolved. A publishable key cannot stand in for a secret key needed by a server integration; the distinction determines the task’s access route, not a way to rename a sensitive value as safe.

The PCI Security Standards Council’s separate rule concerns unprotected primary account numbers: those must not be sent through email, instant messaging, SMS or chat. It is not the source of Stripe’s API-key rule. Neither rule requires a contractor to collect customers’ card details to understand the configuration question. Keep card numbers and authentication codes out of the brief.

Use a named role for human access and an approved route for software

Stripe’s team documentation describes the account owner inviting a person by email and assigning roles with the lowest permission the job requires. It also documents team-member activity logging. Compare the role’s permissions with the requested task before the invitation. Record who approved it and when its continued need will be reviewed; do not assume a contractor needs account-wide authority merely because the project involves checkout.

A team invitation and an application credential solve different access needs. If software needs a key, an authorized account or integration owner should determine the supported permissions, intended application and approved way to provision it into that application’s protected configuration. This guide does not prescribe a transfer channel for an unidentified provider or deployment. No verified credential route means that part of the task stays pending; it does not justify putting the key into a chat attachment.

For a provider other than Stripe, use that provider’s documented roles and credential controls. Stripe’s role names and key powers do not establish the permissions of another service. Keep the approving account owner identified even when the contractor operates more than one part of the store.

Close the request with an action record

Record the authorized action, the person or integration receiving access, the permission selected and the owner responsible for reviewing or ending it. Keep an access reference and activity-review reference, not a copied password or key. An invitation proves access was offered; it does not prove the intended work was completed. Close the work item only when the requested result and the access decision are both documented.

If a secret has already appeared in chat, do not forward it into another ticket or ask the contractor to quote it back. Notify the authorized account owner using the credential category and where it appeared, then use the provider’s current response instructions. This page does not establish whether anyone used it, and removing the visible message is not evidence of that.

For a Prism checkout-review consultation, describe the website, research-only products, requested work and unresolved access boundary without credentials or customer records. Confirm any assistance with access arrangements or implementation in the agreed scope, fees and terms. Prism’s public form is for the question; email follow-up does not turn it into a credential channel, an appointment or a processing application.

Access request boundary

Complete one sheet for one real contractor request. Use credential categories and internal references only. If the task, approving owner or authorized route is missing, record what must be clarified before granting access. Never enter a key, password, authentication code or card number.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.