Conversation
…l ids `project status` prints ARNs, but the eval config-bundle, gateway, and online-eval commands sent the id straight into the request path. An ARN's slashes make the service parse the path as an unknown operation and return a misleading AccessDenied instead of a validation error. Normalize these ids with the existing serviceIdFromArn (ARN -> bare id, non-ARN passes through) at the core-method boundary: config-bundle get/update/delete/ version-list, online-eval get/update/set-status/delete, and the gateway lookup in createABTest.
|
Claude Security Review: no high-confidence findings. (run) |
There was a problem hiding this comment.
AgentCore Harness Review
Verdict: Looks good
The fix is well-targeted: normalizing IDs at the core-method boundary with the existing serviceIdFromArn (which passes non-ARN inputs through unchanged) is the right lever, and it's applied consistently to every touched entry point. The added test mocks only at the SDK client boundary and asserts the bare id lands in every command variant (get / list versions / delete / update-with-read).
One adjacent gap worth considering (optional, not a blocker for this PR since it's out of the stated scope):
src/core/eval.tsxlines 1161–1163 (setOnlineInsightExecutionStatus) and 1175–1177 (deleteOnlineInsight) do a pre-checkGetOnlineEvaluationConfigCommand({ onlineEvaluationConfigId: id })with the rawidbefore delegating to the now-normalizedsetOnlineEvaluationExecutionStatus/deleteOnlineEvaluationConfig. Because online-insight configs are the same underlying resource as online-eval configs, an ARN passed toeval online-insight pause/resume/deletewould still hit the same misleadingAccessDeniedon the pre-check. Fix would be a one-lineid = serviceIdFromArn(id);at the top of each method (or normalize once before theGetOnlineEvaluationConfigCommandcall). Fine to defer to a follow-up if that's out of scope here.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## refactor #2352 +/- ##
=========================================
Coverage 97.26% 97.26%
=========================================
Files 610 610
Lines 40590 40609 +19
=========================================
+ Hits 39480 39499 +19
Misses 1110 1110 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Per review: these ids should be bare, not ARNs. Instead of silently extracting the id from an ARN, reject it with an actionable InputValidationError naming the option, so the misleading AccessDenied is replaced by a clear "pass the bare id" message. Config-bundle, online-eval, and the createABTest gateway are guarded.
|
Claude Security Review: no high-confidence findings. (run) |
Problem
For
agentcore eval config-bundle list(and the other eval commands that take--id/--gateway/--online-eval), if you pass in an ARN instead of the bare id, the API throws a misleadingAccessDeniederror. (The ARN's slashes make the service misparse the request path as an unknown operation, which surfaces as a permissions error rather than a validation one.)Fix
I decided to validate that the id is not an ARN and throw an error — an actionable
InputValidationErrorinstead of letting the request go through and hit the misleadingAccessDenied:Guarded at the core-method boundary for config-bundle (
get/update/delete/listVersions), online-eval (get/update/setExecutionStatus/delete), and thecreateABTestgateway lookup (both A/B variants).Tests
Config-bundle core test: a full ARN rejects with the bare-id message before any SDK call; a bare id still works. Full eval suite green; typecheck clean.