plaid v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-plaid-client-secret

Custody

customer_vault

Injection

header (PLAID-SECRET)

The Plaid API secret for the deployment's own Plaid account, held in the client's own secret manager. Plaid authenticates every request with a client_id and secret pair, sent either as the PLAID-CLIENT-ID and PLAID-SECRET headers or in the request body; this pack injects the PLAID-SECRET header, and the stored material must be the complete header value — the raw secret, with no scheme prefix — while the non-secret client_id travels as the PLAID-CLIENT-ID header from the deployment's own configuration. Provisioning and rotation are external: the secret is issued, and can be rotated or revoked, in the Plaid Dashboard by the account's administrators; it remains valid until rotated or revoked there (no short automatic expiry is documented for the secret itself), so rotation cadence and revocation-on-suspicion are the deployment's process, and a revoked value fails closed. Privilege restrictions: the secret authenticates at the Plaid account level — the available restriction is the Dashboard's per-environment and per-product configuration of the account and its keys (Sandbox and Production secrets are different credentials), so point this reference at the Production secret only when the deployment is meant to read live account data, and confirm the enabled-product set there because link_token.create can request any of them. Executor hygiene: the resolved material must exist only in the executor process's memory for the moment of injection, must never be written to logs, traces or diagnostics, and must never appear in crash reports. SECOND SECRET — separate from this reference: each per-Item access_token the read capabilities spend is additional end-user credential material, minted outside this pack by the deployment's token-handling path; it must be held in a trusted per-Item vault and injected into the request body by the trusted executor with the same log/trace/crash protections, never exposed to the agent, prompts or ordinary request logs. This single registered injection does NOT implement that per-Item resolution and body injection — it is a deployment wiring item.

• plaid-items (api, financial): https://production.plaid.com

Plaid's API is JSON-over-HTTP and POST-only, including for reads, so the read capabilities here ride on POST methods; nothing about a POST method changes the read verb's meaning. Hosts are per environment — Plaid's docs name https://sandbox.plaid.com (Sandbox) and https://production.plaid.com (Production), and Items cannot be moved between environments — so this pack registers the Production host, and a deployment testing in Sandbox replaces the host in the endpoint and the egress allowlist in step. This pack does not register /item/public_token/exchange: the exchange returns the access_token, and Plaid's own guidance is that every token except the public_token and link_token is long-lasting and sensitive — that response is newly minted credential material, which a governed executor must not receive as call output, so the exchange belongs in the deployment's token-handling path, not in a capability. SECOND SECRET: the read capabilities take an access_token in the request body, and that per-Item token is end-user credential material — a second secret distinct from the pack credential (the client secret below). The deployment must resolve it from a trusted per-Item vault and have the trusted executor inject it into the request body, without ever exposing it to the agent, to prompts, or to ordinary request logs; this pack's single registered injection (the PLAID-SECRET header) does NOT implement that per-Item wiring — it is a deployment wiring item, and enabling these capabilities without it would push a live access_token into agent-visible request material. Link tokens: plaid.link_token.create covers both initial-linking Link sessions and update-mode Link sessions (re-authentication or permission repair for an existing Item, where the request carries that Item's access_token, with the same second-secret custody). Excluding Plaid's money-movement products (Transfer, Payment Initiation) from this pack does not constrain the Link configuration this call can request: an unrestricted /link/token/create request can name any product the Plaid account has enabled, so the deployment must either enforce an allowlist of products and other Link configuration at the wiring layer, or treat this capability as supporting the broader effects of every product enabled on the account. This pack does not register the processor-token endpoints. AAES has not been certified by Plaid; the endpoints here are a reviewable default, not a vendor guarantee.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://plaid.com/docs/api/ (retrieved 2026-09-21)
• https://plaid.com/docs/api/items/ (retrieved 2026-09-21)
• https://plaid.com/docs/api/link/ (retrieved 2026-09-21)
• https://plaid.com/docs/api/accounts/ (retrieved 2026-09-21)
• https://plaid.com/docs/api/products/transactions/ (retrieved 2026-09-21)
• https://plaid.com/docs/api/products/balance/ (retrieved 2026-09-21)
• https://plaid.com/docs/api/products/identity/ (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.