fix(bootstrap): least-privilege policies grant no agent-registry actions — deliberate exclusion or coverage gap?

[vivibui]

Component: cdk (bootstrap policies)

Describe the bug

The least-privilege bootstrap policies grant no agent-registry:* actions at all, even though the stack creates an AWS::CloudFormation::Stack containing a Custom::AgentRegistry resource whose backing registry is a real, billable AWS resource.

$ grep -rc 'agent-registry' cdk/src/bootstrap/policies/
0

Nothing is broken today, which is why this has gone unnoticed: the registry's control-plane calls (CreateRegistry, GetRegistry, UpdateRegistry, DeleteRegistry) run under the custom resource's Lambda execution role, granted at cdk/src/constructs/registry.ts:90-104 — not under the CloudFormation execution role the bootstrap policies scope.

The question is whether that's the intended design. If deploy-role coverage is meant to span every resource type the stack creates, this is a gap. If routing resource creation through a custom resource's own role is an accepted pattern for preview services, it's worth saying so explicitly, because the asymmetry currently reads as an oversight.

Expected behavior

One of:

1. The bootstrap policies cover agent-registry actions, consistent with every other resource type the stack provisions; or
2. A comment in cdk/src/bootstrap/policies/ (or docs/design/DEPLOYMENT_ROLES.md) records that custom-resource-provisioned services are deliberately out of scope for the deploy role, and why.

Current behavior

No agent-registry actions anywhere in cdk/src/bootstrap/. A reader auditing the deploy role against the synthesized template finds a resource type with no corresponding grant and no explanation.

Reproduction steps

grep -rn 'agent-registry' cdk/src/bootstrap/          # no hits
grep -n 'agent-registry' cdk/src/constructs/registry.ts   # grants on the Lambda role instead

Possible solution

Decide which of the two above is intended, then either add the actions or document the exclusion. Worth checking at the same time whether cdk/test/bootstrap/synth-coverage.test.ts can be taught to notice this class of gap — it currently maps CloudFormation resource types to required actions, and a Custom:: resource whose real work happens under a different role is exactly the case it cannot see.

Notes

Found during review of #868 by @isadeks, who confirmed via git log -S that it is pre-existing and untouched by that diff, so it was deliberately kept off that PR.

Related: #865 — the same bootstrap policies also fail to authorize nested-stack resources, because they scope every ARN to the backgroundagent-dev-* prefix that nested-stack physical names do not carry. Both are bootstrap-coverage gaps found the same way and may be worth resolving together.

Environment

• Commit e96dc21e