JFrog Artifactory package v1.0.0

A JFrog Platform access token, held in the client's own secret manager. Token issuance is external: an administrator creates a scoped token in the JFrog Platform UI (User Management | Access Tokens) or via the Create Token REST API, and the deployment's custody job stores the result under this reference. The stored material must be the complete Authorization header value (scheme included): 'Bearer ' followed by the access token — JFrog documents using an access token as a bearer token in the Authorization header. JFrog also accepts a reference token as the password half of HTTP Basic authentication; this pack registers the Bearer header form only.

Expiry and revocation behavior: tokens are created with an expiry (default one hour; zero means non-expiring and valid until actively revoked), and JFrog's revocable-expiry-threshold (default six hours) means a token created with a shorter lifetime cannot be revoked — it remains valid until it expires naturally. Disabling token issuance, or removing the creating admin, does not invalidate already-issued tokens; only an explicit revoke of a revocable token, or resetting the token certificates (which revokes all tokens), terminates one.

Prefer the shortest expiry that covers the deployment's renewal cadence, or a refreshable token renewed by the custody job; an expired value fails closed.

Least privilege: create the token with group scopes granting only the permissions the enabled capabilities need (read on the bound repositories; deploy/delete only where the write capabilities are enabled) — never an admin-scoped token for the read, AQL, deploy and item-delete capabilities. The repository create and delete capabilities are different: JFrog documents repository administration as requiring an administrator, so this pack registers those two capabilities against a SEPARATE reference (secret-ref-artifactory-admin-token) holding an admin-permission credential — a deployment that cannot justify an admin credential must remove those two capabilities rather than widen the main token.

Note also that delete operations require the user or group to hold delete permission per JFrog's documentation.

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 'artifactory-server.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's own JFrog Platform Deployment host before enabling, in every endpoint, in the resource locator and in every egress allowlist entry. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step. REPO_KEY and FILE_PATH in the endpoint paths are placeholders: bind them to the repository key and the item path this capability governs before enabling.

This pack registers only Artifactory's documented REST API: listing repositories, storage item info, AQL search, artifact deploy, item delete, repository create and repository delete.

Approval classification: reads and the read-only AQL query sit at the minimum R0 tier. Artifact deploy (PUT on the item path) is registered as create and update at the minimum R2 tier: uploading an artifact adds a new binary and, with Artifactory's default non-unique snapshot layouts or release paths, does not destroy other artifacts — but where a repository layout permits overwriting an existing path, a deploy replaces the stored binary, so the update action is declared, and this registration cannot restrict the bytes a caller uploads.

Repository create is R2 create; its request body is the full repository configuration, which this registration does not constrain. Item delete and repository delete sit at the minimum R3 tier: delete is one of the designated actions requiring human approval. Repository delete removes the repository and every artifact in it — Artifactory's trash can (when enabled) retains deleted ITEMS but not a deleted repository's configuration — and this registration makes no restoration claim.

Search scope: AQL is a POST carrying a query body (a raw AQL statement, Content-Type text/plain) used read-only — it performs no mutation, so it is registered as a read at the minimum R0 tier with the body shape noted here; the statement itself is unrestricted AQL and can enumerate anything the token's user may read.

Documented exclusions: this pack does not register permission-target management (PUT/DELETE /api/security/permissions/...), user or group management, the Access token REST API (token issuance is an external custody process — see the credential note), Empty Trash Can (POST /api/trash/empty — a permanent purge of soft-deleted items, distinct from item delete and deliberately left out), replication configuration, system import/export, and all Xray and Distribution APIs. Source basis: the individual JFrog operation pages were retrieved from JFrog's docs.jfrog.com markdown/OpenAPI mirror (the llms.txt operation index plus the per-operation.md pages for Get Repositories by Type and Project, Get Storage Item Information, Search AQL, Deploy Artifact, Create Repository, Delete Repository and Empty Trash Can, all listed in the review sources).

Every registered method and path was confirmed against JFrog's OpenAPI definitions on those pages: GET /artifactory/api/repositories, GET /artifactory/api/storage/{repoKey}/{itemPath}, POST /artifactory/api/search/aql (text/plain AQL body), PUT /artifactory/{repoKey}/{filePath}, DELETE /artifactory/{repoKey}/{filePath}, PUT and DELETE /artifactory/api/repositories/{repoKey}, and the excluded POST /artifactory/api/trash/empty (admin only). Confirm each path and request contract against the target deployment's own API documentation before enabling — documentation review is complete; target-deployment confirmation remains required before use.