marqeta 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-marqeta-api-basic

Custody

customer_vault

Injection

header (Authorization)

The Marqeta Core API authenticates with HTTP Basic authentication: the application token is the username and the admin access token is the password, per Marqeta's Core API Quick Start, and the keys are listed in the Marqeta Dashboard. The stored material must be the complete Authorization header value (scheme included: 'Basic <base64(application-token:admin-access-token)>'), held in the client's own secret manager under this reference. Issuance and rotation are external processes run by the operator against Marqeta, not by the agent or executor. On permission granularity, go by what Marqeta currently documents: Marqeta's self-service credential API (POST /credentials/apikeys/applications/self/accesstokens) can create admin access tokens with assigned roles — read, write, pci, program-manager — and a new token's roles cannot exceed the roles of the token calling the endpoint, but Marqeta labels this API limited release and gates access through a Marqeta representative. Where that access exists, use it to issue a token carrying only the roles this pack needs — read for the reads, write additionally for the card transitions, and never pci for this pack — with an explicit expires_at. Where it does not, the Dashboard-issued admin access token is broad program authority, and the deployment must treat it as such: least privilege then comes from what this pack registers, not from the credential. Expiry and revocation behavior: role-scoped admin access tokens expire — 90 days after creation by default, settable between 1 and 365 days via expires_at — so the external process must mint a replacement and repoint this reference before expiry; deleting an admin access token does NOT revoke it immediately but sets its expiration to seven days from deletion, so an emergency revocation still leaves a window and the deployment must plan for it. At execution time the resolved material exists in the executor process's memory for the moment of injection only — the deployment owns the executor's memory, log, trace and crash hygiene; the agent never receives it.

• marqeta-program (api, financial): https://your-program.marqeta.invalid/v3

The API host varies by environment — Marqeta's Core API Quick Start shows the shared public sandbox host sandbox-api.marqeta.com, and production programs run on dedicated hosts issued by Marqeta — so the registered authority your-program.marqeta.invalid is a placeholder on the reserved .invalid domain, not a reachable host. Replace it with the deployment's actual program host and keep the egress allowlist in step; the allowlist entry is the authority only. USER_TOKEN and ACCOUNT_HOLDER_TOKEN are path placeholders to replace before enabling. The card read is NOT enforced metadata-only: Marqeta's card object returns pan by default — the documentation's own sample card response carries a full PAN — the fields query parameter that shapes the response is caller-controlled on this registered GET (left blank it returns all fields), and show_pan and show_cvv_number are caller-settable query parameters on card endpoints; saying those parameters are not registered does not exclude them from a registered route. Required handling: the deployment must pin response shaping outside the agent's reach (an executor-fixed fields list that excludes pan and cvv_number), treat every response from this capability as potentially PCI-scope cardholder data until that pinning is verified, and keep such responses out of logs, traces and crash reports. The dedicated PAN- and CVV-bearing endpoints (GET /cards/{token}/showpan, POST /cards/getbypan) remain unregistered. The card-transition capability changes a card's state (for example UNACTIVATED to ACTIVE, or ACTIVE to SUSPENDED): a state transition is a card authorization control — activating enables the card for authorization subject to program configuration, funding and spend controls (not a promise that every transaction up to a limit will be honored), suspending withdraws that eligibility — and it is registered at the pay verb's R3 floor under the finance-pack rule that card authorization control sits with money-committing actions, even though no money moves at request time. This pack does not register card creation (POST /cards issues spending power and is left out until separately reviewed), user or business creation, user transitions, PIN endpoints, funding endpoints (/gpaorders, /fundingsources), program or intra-account transfers, spend-control management (/authcontrols, /velocitycontrols), webhooks, or the /simulate endpoints. AAES has not been certified by Marqeta; 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://www.marqeta.com/docs/core-api/cards (retrieved 2026-09-21)
• https://www.marqeta.com/docs/core-api/card-transitions (retrieved 2026-09-21)
• https://www.marqeta.com/docs/core-api/users (retrieved 2026-09-21)
• https://www.marqeta.com/docs/core-api/transactions (retrieved 2026-09-21)
• https://www.marqeta.com/docs/core-api/balances (retrieved 2026-09-21)
• https://www.marqeta.com/docs/developer-guides/core-api-quick-start (retrieved 2026-09-21)
• https://www.marqeta.com/docs/core-api/self-service-credentials (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.