canonical: https://jentic.com/apis/anchore.io/anchore # Anchore Engine API Server The Anchore Engine API is the primary external surface for Anchore Engine, an open-source container image scanning and policy evaluation service. Across 112 endpoints it covers accounts and users, image and repository management, archives of historical analyses, archive rules, events, policies and policy evaluation, registries, repository credentials, subscriptions, summaries, system health and configuration, and import flows for SBOM and analysis data. The spec uses HTTP Basic authentication and is typically deployed inside a customer's environment, so the base URL is whatever host the operator binds the service to. ## For AI agents Lets agents drive an Anchore Engine deployment - submit images for scanning, evaluate policies, manage archives, registries, subscriptions, and read events - across 112 endpoints with HTTP Basic auth. ## Scope Does not handle source-code SAST, runtime workload protection, or non-container asset management - use for Anchore Engine container scanning, policy evaluation, archives, and events only. ## Capabilities - Submit container images for analysis and pull policy evaluation results to gate CI/CD pipelines - Manage archive rules and archive image analyses to keep historical scan data without bloating the live store - Configure registries and repository credentials so Anchore can pull images from private registries - Create, update, and evaluate Anchore policies against scanned images - List and acknowledge events from the Anchore Engine event bus for incident workflows - Manage accounts and users, including per-account credentials and enabled or disabled state - Pull system health, configuration, and summary endpoints for monitoring the Anchore deployment ## Use cases ### Container Image Scanning in CI/CD DevSecOps teams can wire Anchore into a CI/CD pipeline so every image build is submitted to /images for analysis and the resulting policy evaluation gates the deploy step. The 112-endpoint surface covers everything from registry credentials to policy mapping, but a typical pipeline integration only needs the image-submit and policy-evaluation endpoints. Setup against an existing Anchore deployment usually takes a day. Example prompt: Submit an image to Anchore via POST /images, poll until analysis completes, then call the policy evaluation endpoint and fail the CI step if the evaluation status is 'fail' ### Vulnerability Triage Across Scanned Images Security teams operating an Anchore Engine deployment can pull events, summaries, and image queries to triage new vulnerabilities affecting already-scanned images. The events endpoint surfaces newly discovered vulnerabilities tied to images already in the catalog, so the team gets fresh CVE data without rerunning every scan from scratch. Example prompt: Call GET /events filtered to vulnerability events in the last 24 hours and group the resulting events by image digest ### Archive Lifecycle Management Long-running Anchore deployments accumulate analyses for images that are no longer in active use. The archives endpoints (/archives, /archives/images, /archives/rules) let an operator define rules to move stale analyses into an archive tier, list what is archived, and pull a specific archived analysis back when needed for an incident review. Keeps the active store cheap without losing historical data. Example prompt: Call POST /archives/rules with a rule that archives image analyses older than 90 days and confirm the rule appears in GET /archives/rules ### AI Agent Security Operations DevSecOps copilots can drive an Anchore Engine deployment through Jentic without storing the Basic-auth credentials in the agent context. The agent searches Jentic for an image, policy, or events intent, loads the operation schema, and Jentic injects the credentials at execution time. Useful for triage agents that need to pull recent events and trigger archive rules in response to incidents. Example prompt: Search Jentic for 'list Anchore events', execute the operation backed by GET /events with a since-timestamp filter for the last hour, and return the count of new events per image digest ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | / | Ping the service for liveness | | GET | /accounts | List user accounts (admin only) | | POST | /accounts | Create a new account | | GET | /archives/images | List archived image analyses | | POST | /archives/images | Archive an image analysis | | GET | /archives/rules | List analysis archive rules | | POST | /archives/rules | Create an analysis archive rule | | GET | /events | List events from the Anchore event bus | ## Key resources - **Images** — Submit images for analysis and query analysis state and policy results - **Archives** — Manage archived image analyses and the rules that move analyses into the archive tier - **Events** — List and acknowledge events from the Anchore event bus - **Policies** — Create, update, and evaluate Anchore policies against scanned images - **Registries** — Configure private container registries Anchore should pull from - **Accounts and Users** — Manage accounts, users, credentials, and enabled or disabled state - **System** — Health, configuration, and summary endpoints for monitoring the Anchore deployment ## Why Jentic - **Setup:** Wiring the Anchore Engine API Server by hand means managing HTTP Basic auth against your own Anchore host and finding the right routes across a 112-endpoint surface yourself. Through Jentic you install once, import Anchore Engine from the API Directory, store the Basic credentials once, and your agent calls it. - **Permission scoping:** Anchore Engine exposes collection routes like /accounts, /archives/images, and /events, so scope the agent to the operations it needs, such as listing events and submitting images. You choose the operations it may call, so account creation or archive-rule changes are not included unless you add them. - **Credential handling:** Your Anchore HTTP Basic username and password are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'submit an image to Anchore' or 'list Anchore events', and Jentic returns the matching operation with its input schema so the agent calls the right endpoint without navigating the 112-endpoint surface manually. ## Related APIs - **Snyk** — Hosted SAST and container scanning platform with its own policy engine - **SonarCloud** — Hosted code-quality and security platform that complements Anchore for source-level scanning - **Tenable** — Vulnerability management platform spanning hosts, containers, and cloud assets - **Abstract API** — Date and IP utilities used alongside Anchore for event-window normalisation ## FAQ ### What authentication does the Anchore Engine API use? Anchore Engine uses HTTP Basic authentication - a username and password sent in the Authorization header. Operators typically create scoped accounts and users via /accounts and /accounts/{accountname}/users, then issue per-user Basic credentials. Through Jentic, those credentials are stored in the vault and injected at execution time so the agent never sees them. ### Can I scan a container image with the Anchore Engine API? Yes. Submit the image to the /images endpoint, then poll the image record by digest until analysis completes. After analysis you can call the image's policy evaluation endpoint to get a pass or fail decision against your active Anchore policy. The 14-endpoint Images resource group covers the full submit-and-evaluate flow. ### What are the rate limits for the Anchore Engine API? Anchore Engine is typically self-hosted, so rate limits are whatever the operator configures at the ingress (nginx, ALB, service mesh). The Engine itself does not enforce per-tenant API rate limits in the open-source distribution. Plan for the deployment's ingress policy rather than a vendor-side cap. ### How do I create an analysis archive rule through Jentic? Search Jentic for 'create Anchore archive rule'. Jentic returns the operation backed by POST /archives/rules, you load the schema (the rule body specifies the analyzer state and age threshold), and execute. Jentic handles the Basic-auth injection. Run it through Jentic One, the self-hosted execution layer. ### Can I list and acknowledge events from the Anchore event bus? Yes. GET /events lists recent events with optional time and type filters, and Anchore Engine exposes paired endpoints (under /events) for retrieving individual events and clearing event types. Pair this with /event_types to discover what events your deployment is emitting. ### Does the Anchore Engine API require a hosted Anchore deployment? Yes. The base URL listed in the spec is just '/', which means the API is mounted on whatever host you run Anchore Engine at. There is no hosted-vendor URL - every integration points at a customer-operated Engine instance. ### Can I limit what my agent is allowed to do with the Anchore Engine API? Yes. Because you run Jentic One yourself, you decide which of Anchore's 112 operations the agent may call, so you can allow just the routes it needs, such as listing events under GET /events and submitting images to POST /images, while withholding everything else. Higher-impact operations like creating accounts under POST /accounts or writing archive rules under POST /archives/rules stay out of reach unless you explicitly grant them. Your own rules govern which operations and Basic-auth credentials the agent is permitted to use at execution time.