Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#878 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
aws, typescript
Domain
authorization, cloud, infrastructure

Research direction

Start with cdk/src/bootstrap/policies/ and cdk/src/constructs/registry.ts:90-104, comparing the deploy-role policy scope with the custom resource Lambda role. Run the two grep commands in the issue, then read cdk/test/bootstrap/synth-coverage.test.ts to understand its resource-to-action mapping. Done means the intended ownership is established and either the required actions are covered or the exclusion is documented, with coverage behavior addressed if appropriate.

Written by the indexing model from the issue text.

Description

v1

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
Dominant language
TypeScript
Stars
158
Forks
49
Avg merge
3d 7h
Merged PRs (30d)
17

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from aws-samples/sample-autonomous-cloud-coding-agents

All issues in aws-samples/sample-autonomous-cloud-coding-agents

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.