refactor: move harness resources to .github/harness/

[jesseturner21]

Summary

• Create .github/harness/ for AgentCore Harness resources (PR reviewer now, tester later)
• Move harness_review.py and prompts/ from .github/scripts/ to .github/harness/
• Add Dockerfile for the harness container (dual-token: CLONE_TOKEN for git clones, GITHUB_TOKEN for gh CLI/PR comments)
• Add README.md documenting the harness directory and build instructions
• Update pr-ai-review.yml workflow to reference new path
• .github/scripts/ stays untouched for Strands workflows

Test plan

• Built container image from new Dockerfile with finch build
• Verified CLONE_TOKEN clones repos inside container
• Verified GITHUB_TOKEN authenticates gh CLI and can post PR comments
• Triggered pr-ai-review workflow — ran successfully and posted review comment
• CI checks pass (format, lint, build, e2e)

[github-actions]

Package Tarball

aws-agentcore-0.11.0.tgz

How to install

npm install https://github.com/aws/agentcore-cli/releases/download/pr-992-tarball/aws-agentcore-0.11.0.tgz

[agentcore-cli-automation]

Tokens baked into image layers are extractable by anyone who can pull the image

The Dockerfile comment claims "Tokens are passed as build args only — not stored in env vars", but using build args in RUN commands still persists the token values into the image layers:

• Line 23 writes the CLONE_TOKEN into /root/.gitconfig in plaintext as part of that layer.
• Lines 26–30 write the GITHUB_TOKEN into /root/.config/gh/hosts.yml in plaintext as part of that layer.
• docker history --no-trunc <image> will also show the interpolated ARG values in the RUN command strings themselves (since the shell substitution happens before the layer is committed, the resolved command is what Docker records).

Anyone with pull access to the resulting image (e.g., the ECR repo the harness pulls from, any cached layers on build hosts, any mirror/backup) can extract both tokens. This is materially different from "not stored in env vars" — it's arguably worse, because env-var tokens die with the container while baked-in tokens live with every copy of the image.

A few options:

1. Don't bake the tokens in at all. Have the harness runtime mount /root/.gitconfig and /root/.config/gh/hosts.yml (or inject the tokens via env vars and let the entrypoint configure git/gh at container start). This keeps the image itself token-free and allows rotating tokens without rebuilding.

2. Use BuildKit secrets (RUN --mount=type=secret,id=clone_token …) so the token is available during build but never written into a layer. The git config / gh hosts.yml files would need to be generated at container start from the mounted secret, not at build time.

3. If baking in is truly intentional (e.g., the image is stored in a private registry with access equivalent to the tokens themselves, and rotation-via-rebuild is acceptable), then at minimum update the comment on line 18 to be accurate — something like "Tokens are baked into the image at build time; this image must be treated as a secret and stored only in a registry with equivalent access controls." The current comment reads as a security guarantee that isn't true.

Also worth noting: the README's finch build example passes tokens as plain --build-arg, which means they'll also show up in shell history and any CI build logs that echo the command. If you go with option 1 or 2, the README example should change too.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	43.01%	7793 / 18117
🔵	Statements	42.41%	8245 / 19439
🔵	Functions	40.4%	1347 / 3334
🔵	Branches	40.65%	5108 / 12564

Generated in workflow #2184 for commit 1633959 by the Vitest Coverage Report Action

[jesseturner21]

Thanks for the thorough review. Going with option 3 for now — updated the Dockerfile comment in ce006eb to accurately state that tokens are baked into the image at build time and the image must be treated as a secret (stored only in a registry with equivalent access controls).

This image is only stored in a private ECR repo with access scoped to the same principals that already have the tokens, and rotation-via-rebuild is acceptable for our use case. We can revisit with BuildKit secrets or runtime injection if the access model changes.