Build an AWS Agent Registry: The Approval Gate Matters More Than Search

Set up AWS Agent Registry as a controlled publishing path: create an IAM-authorized registry with auto-approval disabled, add each agent, tool or MCP server as a draft, submit it for review, approve it separately and only then test discovery. Search is the acceptance test; the status transition to Approved is the control that keeps a first unreviewed revision out of the shared catalog.

Use the same consumer identity for a paired discovery test. Before approval, the new record must be absent; after approval and indexing, the identical query must return the expected name and version. Retain both outputs alongside the record status and approval evidence.

1. Separate publishing from approval

Decide who can administer registries, publish records, approve or reject submissions and consume approved entries before creating anything. Keep those IAM permissions in separate policies even when one operator temporarily holds several roles. In particular, a CI/CD publisher that can call SubmitRegistryRecordForApproval should not automatically receive UpdateRegistryRecordStatus.

Choose IAM inbound authorization when the required verification paths are the AWS console and CLI. JWT-authorized registries require direct HTTP or MCP clients for discovery because console, CLI and SDK discovery use IAM credentials. The AWS Agent Registry quickstart separates registry creation, record creation, submission, approval and approved-record discovery, and shows where to turn off Auto-approval in the console.

In the console, open Registry, choose Create registry, select IAM authorization and turn Auto-approval off. A reproducible CLI equivalent makes manual review explicit: aws agent-registry-control create-registry --name "production-agent-catalog" --description "Reviewed agentic resources" --approval-configuration '{"autoApprovalRules":[]}' --region us-east-1. Wait until the registry reaches READY, then store its ARN, Region and returned approval configuration as deployment evidence.

2. Create a draft with evidence attached

Prepare the descriptor and ownership metadata before publication. Give the record a stable name, an explicit version, a description of its capability and intended use, and an accountable owner. Use the supported descriptor shape for the selected record type: AGENT, MCP, SKILL or CUSTOM.

Create the record through Create record in the console, or keep the reviewed parameters in a JSON file and run aws agent-registry-control create-registry-record --cli-input-json file://record.json. Creation is asynchronous: wait for the record to move from CREATING to DRAFT before submitting it. Save the record ARN and ID, version, descriptor digest, source commit or build identifier, owner and command output.

Submit the draft with aws agent-registry-control submit-registry-record-for-approval --registry-id <registryId> --record-id <recordId> --region us-east-1. With an empty auto-approval rule list, the expected result is PENDING_APPROVAL. An immediate APPROVED result means the deployed registry configuration does not enforce the intended manual gate; stop the publishing run and inspect the live approval configuration.

3. Make Pending approval trigger validation

A submitted record should start evaluation, not merely notify an operator after publication. Create an EventBridge rule for the transition to Pending approval and route it to the validation workflow used by your organization. The AWS architecture walkthrough places EventBridge between submission and approval and identifies security scanning, deduplication and other organization-defined checks as possible parts of that workflow.

Validation can examine descriptor syntax, required ownership fields, duplicate names and versions, endpoint reachability, security findings and internal policy. These checks are implementation choices, not automatic proof supplied by a schema-valid descriptor. Define which failures block approval and which require manual review before enabling the EventBridge target.

Keep the record ID and version, descriptor digest, individual check results, reviewer or automation identity, decision time and status reason in a durable ticket or build artifact. Reject failures through update-registry-record-status with a specific reason. After all required checks pass, let a curator or narrowly scoped automation run aws agent-registry-control update-registry-record-status --registry-id <registryId> --record-id <recordId> --status APPROVED --status-reason "Validation evidence: <reference>" --region us-east-1.

4. Prove approved-only discovery

Before approval, assume the same IAM role that applications will use. Check the console’s Record directory, then run aws agent-registry search-discoverable-registry-records --search-query "<unique-name>" --registry-ids "<registryArn>" --filters '{"name":{"$eq":"<unique-name>"}}' --region us-east-1. A first-publication record must produce no match while its latest revision is DRAFT, PENDING_APPROVAL or REJECTED.

After approval, repeat the identical query until the expected record appears or a defined timeout expires. Check the authoritative control-plane value with aws agent-registry-control get-registry-record --registry-id <registryId> --record-id <recordId> --region us-east-1 before treating an initial discovery miss as an approval failure. Record the returned name, version and record ID rather than relying only on a non-empty result set.

Keep the negative and positive discovery outputs. The negative result demonstrates that a first unapproved publication stayed outside the consumer catalog; the positive result demonstrates that the approved revision became available. A test performed only after approval proves discovery works but does not test isolation of unfinished records.

5. Review revisions and make rollback explicit

An edit to an approved record follows a different discovery test. The AWS record lifecycle keeps the previously approved revision discoverable while the edited revision is DRAFT, and treats DEPRECATED as a terminal state. For an update, verify that consumers still receive the old approved version and never the draft replacement.

If an approved record is unsafe, retired or materially incorrect, change its status to DEPRECATED with a recorded reason, then repeat the same discovery query until it disappears. Preserve the management-plane record for audit evidence and publish any corrected replacement through a new draft-to-approved cycle. This keeps the operational rule precise: creation adds governed inventory, submission starts review, approval exposes a revision and deprecation removes it from discovery.

Also read:

• Best Secure Phones in 2026: Support Matters More Than a Privacy Label
• Restaurant SEO Is More Than Rankings: Make Local Search Lead to a Table
• Your Online Business Needs More Than Passwords: Build a Six-Part Security Plan