Adobe Acrobat Sign package v1.0.0

An Adobe Acrobat Sign OAuth 2.0 access token, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'Bearer', one separating space, then the access token — 'Bearer <token>'. customer_vault is the only generally-supported production custody model here — identity_federation and customer_broker are refused at startup and inline is lab-only. Acrobat Sign access tokens are short-lived: Adobe documents an access-token lifetime of one hour (expires_in 3600), with a refresh token that expires after 60 days of inactivity, so minting and refresh must be owned by an external deployment process that writes the fresh header value into the vault — the executor injects the stored value verbatim and performs no token lifecycle itself, and a stale value fails closed.

Tokens can be revoked via Adobe's /oauth/v2/revoke endpoint; revocation of a refresh token also revokes access tokens issued from it.

Least privilege: request only the OAuth scopes these capabilities need — 'agreement_read', 'library_read' and 'user_read' for the reads, plus 'agreement_write' for agreement creation and 'agreement_send' for the send — with the ':account' scope modifier (for example 'agreement_send:account') and the corresponding account-level authorization where the integration must act on account-wide resources rather than only the authorizing user's own; the v6 reference for POST /agreements lists the send permission as 'agreement_send:account'.

Note a documentation tension the deployment must resolve at app registration: Adobe's own v6 best-practices guidance marks 'agreement_send' as deprecated and not accepted for some v6 endpoints (for example transient documents) while the v6 POST /agreements reference and Adobe's API FAQ list 'agreement_send:account' for sending — confirm the effective scope set against the account before enabling.

Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

The endpoint host 'adobesign-account.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the account's own API access point host before enabling, in the endpoints, the resource locators and the egress allowlist — the allowlist matches exactly, so all three must be substituted together, and substitution is a required deployment step. Acrobat Sign shards accounts by geography; the real substitution shape is 'api.{shard}.adobesign.com' (for example 'api.na1.adobesign.com' or 'api.eu1.adobesign.com'), and the deployment resolves the account's access point via GET /api/rest/v6/base_uris as Adobe documents — a request to the wrong shard fails with INVALID_API_ACCESS_POINT.

This pack registers only endpoints the official Acrobat Sign REST API v6 documentation describes: listing agreements, listing library documents, listing users, and creating an agreement. Reads are collection reads: single-record reads (GET /api/rest/v6/agreements/{agreementId}, GET /api/rest/v6/libraryDocuments/{libraryDocumentId}, GET /api/rest/v6/users/{userId}), document retrieval and the POST /api/rest/v6/search advanced query are not registered by this pack.

Documented exclusions: this pack does not register agreement state transitions (PUT /agreements/{agreementId}/state, which can cancel an in-flight agreement), reminders (POST /agreements/{agreementId}/reminders, which emails participants), agreement sharing, transient-document upload, library-document creation and update, widget and MegaSign creation, webhook management, and user creation or update — deliberate exclusions, not approximated capabilities. Agreement content is contractual material about identifiable signers, so agreement data is classified as pii (personal data).

The credential-custody review was completed on 2026-09-21 against this pack's custody model (an OAuth access token held in the customer's vault and refreshed by an external process), with these findings, one per gated property.

Issuance authority and delegation: tokens are minted by Adobe's authorization server for an application the customer registers, and each OAuth grant delegates restricted access on the authorizing user's behalf, with the ':account' scope modifier delegating account-wide authority where the integration must act on account-wide resources.

Scope: the reviewed documentation enumerates the scope names this pack needs — agreement_read, library_read and user_read for the reads, agreement_write and agreement_send for creation and send — and documents a tension the deployment must resolve at app registration: v6 best-practices guidance marks agreement_send deprecated and not accepted for some v6 endpoints while the v6 POST /agreements reference and Adobe's API FAQ list agreement_send:account for sending, so the effective scope set is confirmed against the account, not assumed.

Audience: the retrieved docs document no audience claim — the bearer value authorizes against the account's own API access point (its shard host), and audience binding beyond that is not established. TTL: access tokens live one hour (expires_in 3600), and the refresh token expires after 60 days of inactivity.

Refresh ownership: minting and refresh are owned by an external deployment process that writes the fresh header value into the vault; the executor injects the stored value verbatim and performs no token lifecycle itself, and a stale value fails closed.

Revocation: Adobe's /oauth/v2/revoke endpoint revokes tokens, and revoking a refresh token also revokes the access tokens issued from it. Executor access and replay/exposure: the executor reads only the vault reference; the token is a bearer credential replayable within its one-hour TTL, and the 60-day inactivity expiry bounds an idle stolen refresh token.

Alternate access paths: the Acrobat Sign web app and other integrations retain access outside this pack, and revoking this grant closes only this path. The custody gate is documented and passed; remaining owner placeholders bind at deployment. Source note: the interactive v6 method reference at secure.na1.adobesign.com is a JavaScript-driven console whose per-operation content could not be fully extracted during this retrieval, so the operation definitions and OAuth security requirements cited here were taken from Adobe's developer-guide apiusage page (which documents POST /api/rest/v6/agreements with the IN_PROCESS send state and the agreement_send:account scope) and the best-practices page; a deployment reviewer should confirm the per-operation scope table in the interactive reference before enabling.