The Capability Library

Every value below renders from the pack files themselves. Each card links to a detail page carrying the full pack content — capabilities with endpoints and methods, the credential reference, the complete notes, the review block with its source URLs, and the pack's release identity. A retrieval date says when a source page was read; it does not by itself establish what the page said then.

Promoted on September 21, 2026 — and what promotion does not mean

aws, microsoft365, okta, and servicenow were promoted to library on September 21, 2026, after the external review completed; servicenow's change-request approval was removed as a documented exclusion along the way. Promotion attests a completed documentation review. It does not attest executable connectivity: the aws pack is library-state with its wiring gap retained — every AWS API it registers authenticates with Signature Version 4, the HTTP connector cannot perform SigV4, and no capability in the aws pack can execute today. That warning is on its card, in its notes, and on its detail page, and the library badge does not soften it.

Why 2 packs are draft

A draft badge is a finding, not a hedge. Each draft below states the blocker its own pack notes or review record gives; no admission rule beyond the per-pack record is claimed.

• salesforce (draft review record dated 2026-09-21): its notes state that the registered customer_vault model — a client-refreshed token — has not completed the custody review the capability-library plan gates any authentication mode on (issuance authority and delegation, scope, audience, TTL, refresh ownership, revocation, executor access and bypass paths), and name identity_federation — a per-decision token where the org supports it — as one candidate stronger model, not an automatic pass. No general rule about OAuth-first providers is claimed beyond what this pack's notes record.
• workday (draft review record dated 2026-09-21): the external promotion review of September 21, 2026 held it at draft pending verification of the recruiting and absence-management endpoints against provider-hosted documentation — Workday's authoritative REST Services Directory is gated behind a customer login, and no provider-hosted, dated document for those exact method and path pairs could be retrieved. The three unverified capabilities (job-postings.read, absence-balances.read, time-off-requests.create) were removed and are documented exclusions; the two verified reads remain. Its notes also name the open custody-review items: issuance authority and delegation, functional scopes and domain-security mapping, token audience, actual TTL as observed in the deployment, and executor access and bypass paths.

No pack on this page — library or draft — is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant. The library badge means a completed review against the dated provider documents the pack names, nothing more.

• Capabilities. Each capability is a pinned, versioned registration: a stable id, the endpoint and method it may reach, an exact egress allowlist (empty means nowhere, not everywhere), a data class, and the actions it may perform.
• Risk tiers. Every action has a minimum tier — reads at R0; writes, creates, updates, executes, and invokes at R2; the designated irreversible actions (delete, send, pay, deploy, approve, share, transfer) at R3 — and a registration may not sit below it. The shipped packs register at the minimum. The floors are lower bounds, not a business-risk assessment: effect-level irreversibility is not exhaustively classified by the verb floor — an R2 financial update can be irreversible in effect, and card issuance creates spending power — and R0 is not a low-confidentiality-risk designation. On supported, mediated execution paths, an action in the designated irreversible set requires approval by an authorized person, and no policy can configure that away; the guarantee does not cover bypass paths or observation-only registrations, which record reported activity and cannot stop the call.
• Custody wiring. The pack names a credential reference, a custody model, and where the resolved material is injected. Packs are designed to contain credential references, not secrets. The loader rejects selected known credential formats; this scan cannot prove that arbitrary text contains no secret. Custody paths differ in what crosses the trust boundary. On a grant path, AAES issues a short-lived, task-scoped AAES grant: an authorization, not a downstream credential. On a brokered-execution path, AAES executes the permitted call with the configured credential and returns the result without handing the downstream credential to the agent. A short-lived AAES grant does not make the downstream secret ephemeral. Observation-only registrations record reported activity and cannot stop the call. Custody models differ per capability, and not every model is available: the dated capability matrix records which are wired, lab-only, or refused at startup.
• Dated review sources. The review block records the state, the review date, the provider documents reviewed (each with its retrieval date), and an opaque reviewer id that resolves internally to the responsible reviewer. A pack review is not a vendor or examiner attestation.

What the review states mean. library is a completed manual review against the named sources, with every exclusion stated in the pack's notes. draft is internal work in progress and is never part of the distributable library. A pack without a review block renders unreviewed — a finding, not a default.

1. Scan what you already run. aaesctl estate report reads an export you are authorized to supply of the inventories you already have — AWS, Azure, and GCP resource lists, Kong declarative configuration, MCP server tool lists, and OpenAPI documents — fully offline: it writes no registry, uses no credentials, and claims no enforcement. Redaction scrubs credential material embedded in URLs and refuses a candidate carrying what looks like a known credential format; known formats only — absence cannot be proven, and offline processing alone does not establish confidentiality. The report prints its unknown-data-class and refusal rates over the candidates in scope of the supplied export, not necessarily rates across your whole estate. What passes the importer's implemented structural and registration validations is written as a draft pack — always draft, never library. Deploying that draft is a separate, human approval step, and it is distinct from the manual provider-document review that earns the library state: one is not a substitute for the other.
2. Select the packs. aaesctl pack list prints every pack with its capability count, highest risk tier, and review state — and says so next to a draft, because a draft is not part of the distributable Capability Library. aaesctl pack show prints one pack in full; the same content is published read-only on each pack's detail page, linked from the cards above. Removing capabilities from your copy is a supported review outcome — and a locally modified pack is a different artifact, which the digest check below makes visible.
3. Deploy under change control. aaesctl deploy plan and aaesctl deploy apply produce and apply one manifest binding the tenant, the change-ticket id, the recorded approver ids (recorded from your change-management system, not authenticated by the tool), and SHA-256 digests of the base registry, the rendered registry, and every pack installed. Apply re-verifies every digest against the files on disk and refuses on any difference. Recorded ids and digests do not establish authenticated approval, separation of duties, or an approved change ticket — approval must be enforced in your change-management system. A pack whose bytes changed — endpoint, tier, allowlist, or credential edited — fails the digest check, loses distributability, and renders MODIFIED rather than as the shipped reviewed artifact. The exact bindings and the refused-apply behavior are documented in the deployment-manifest runbook (docs/runbooks/DEPLOYMENT-MANIFEST.md, available with the evaluation materials); the command surface is in the CLI reference.
4. Map the evidence. aaesctl evidence map evaluates a regulation-mapped evidence map over one export, routing inputs onto obligations. It never verifies the export — verification stays with aaesctl evidence verify, and an optional records sidecar is bound to the exact export bytes, failing closed on a mismatch. Mapping records to obligations does not determine compliance or prove an obligation was satisfied. The verification procedure is public: Offline verification.

• Comparing AI agent governance approaches — the sourced comparison of the hyperscaler control planes, the workflow platform, and a program-governance product against the architecture AAES is designed to offer.
• Evidence Library — what AAES governs and records, and how to check an export. The Evidence Library documents product evidence; this page lists vendor packs. They are different documents for different questions.
• Capability matrix — the dated record of which custody models are wired, lab-only, or refused at startup, checked by automated site tests against the daemon's custody wiring.
• Guides — plain-language guides on human-in-the-loop oversight, governance platforms, spending controls, and regulatory compliance.

Read the CLI reference Discuss a design partnership