fix(agent-advisor): agentcore.identity_oauth — new knowledge

[leon1418]

Opened by the knowledge auto-update pipeline. Draft — a human decides.

What changed upstream

Amazon Bedrock AgentCore Identity now offers a managed consent portal

Verdict: new_knowledge on agentcore.identity_oauth

• was — Identity: built-in (free), OAuth via enhanced Identity — no mention of consent/callback infra; Gateway used for external tool connections without managed consent UI.
• now — AgentCore Identity now offers a managed consent portal per Gateway (dedicated hosted web client + credential provider list), eliminating need for custom OAuth callback infrastructure for 3LO flows with third-party tools (GitHub, Salesforce, Slack); self-service connection status for end users; usable as auth surface for IDE-based agent clients.

Still true: Identity remains built-in/free and OAuth via enhanced Identity is still the underlying mechanism; this adds a managed UI/portal layer on top, not a pricing or session-cap change.

This is why the old value is not simply overwritten.

Proposed edits

Each row states its justification. No CI check can catch a badly reworded judgment, so the
"why" column is the only protection a reviewer has — please read it rather than the diff alone.

agent-advisor/references/decision-refs/agentcore.md:46 — value

- - Identity: built-in (free), OAuth via enhanced Identity
+ - Identity: built-in (free), OAuth via enhanced Identity — now includes a managed consent portal per Gateway, eliminating custom OAuth callback infrastructure for 3LO flows with third-party tools

Why: This line states the old fact verbatim ('OAuth via enhanced Identity') with no mention of the new managed consent portal capability; the announcement explicitly adds this as a new managed UI layer on top of the existing OAuth mechanism.

Evidence (verbatim from the announcement): "Amazon Bedrock AgentCore Identity now offers a managed consent portal that eliminates the need for custom OAuth callback infrastructure"

Filter false positives

The announcement scan flagged these files; the judge rejected them:

• gcp-to-aws/references/design-refs/design-ref-agentic-to-agentcore.md

Mirrored to migrate/plugins/migration-to-aws/skills

The same edits were applied to this second copy: 1 applied.

Known limits of this proposal

• Blast radius is not stable between runs. Two runs of the same input returned 9 and 13
  locations and neither was a superset of the other, so this list may be incomplete.
• Paths are relative to advisor/plugins/aws-startup-advisor/skills.
• The pipeline did not touch any file the judge did not name.

[leon1418]

[🤖 AI review 🤖]

Reviewed: all 2 changed files, full file context, PR description, cross-plugin parity, drift allowlist, CI, and merge state.

Head: fa2075248bae1d3e9d095a685131967906afbbba

Result: CLEAN — 0 findings.

This PR adds a single additive qualifier to the AgentCore Identity bullet in the service card (agentcore.md), noting the new managed consent portal capability announced for AgentCore Identity. The original value is preserved (appended, not overwritten), correctly reflecting that this is additive functionality on top of the existing OAuth-via-enhanced-Identity mechanism. The wording is accurate, specific, and factually grounded in the cited announcement.

Cross-plugin parity: ✅ PASS — both advisor/…/agentcore.md and migrate/…/agentcore.md share git blob 81bf49f6 (byte-identical). No drift allowlist entries added or bypassed.

CI: 8/8 SUCCESS (build ✅, gitleaks ✅, bandit ✅, semgrep ✅, checkov ✅).
Approvals: 0 — REVIEW_REQUIRED.
Mergeable: MERGEABLE.

MERGE-READY pending human approval.

[herosjourney]

Review — head fa20752

Knowledge auto-update pipeline PR: +2/−2, one bullet edit mirrored to both plugin trees. Verdict: approve — no findings.

Reviewed as a judgment review (no CI can catch a badly reworded fact), applying the pipeline-PR checklist:

1. Evidence vs primary source — fetched the Sept 2026 announcement. The verbatim evidence quote in the PR body ("managed consent portal that eliminates the need for custom OAuth callback infrastructure") is exact, and every element of the reworded value checks out: per-Gateway ("Each AgentCore Gateway receives its own managed consent portal"), 3LO / third-party tools ("OAuth 2.0 three-legged authorization (3LO)… GitHub, Salesforce, and Slack").
2. Splice grammar — the append after "OAuth via enhanced Identity" uses an em-dash, reads cleanly, and doesn't misattribute anything to a neighboring subject.
3. Target is the SSOT the title names — title agentcore.identity_oauth → the Identity line under "Six dimensions" in agent-advisor/references/decision-refs/agentcore.md, the canonical home for that dimension. The only other mention (confirm.md: "enhanced Identity (OAuth)") is a capability listing, not a restatement of the fact, so there's no stale duplicate to update.
4. "Still true" / not overwritten — built-in/free and OAuth-as-underlying-mechanism are preserved; the portal is layered on as a new managed UI, not a pricing or session-cap change. The was/now/Still-true reasoning is sound, and correctly not a blind overwrite.
5. False-positive rejection — dropping design-ref-agentic-to-agentcore.md is right: the consent portal is an AgentCore decision dimension (agent-advisor), not part of the gcp-to-aws agentic design flow.
6. New terms — "managed consent portal" is self-explanatory in context; no undefined jargon.

Mechanical gates

• mise run build on a fresh detached worktree at fa20752: PASS, exit 0 (markdownlint + dprint clean, fail 0 across DSL suites; checkov 244/0, gitleaks no leaks, grype no vulnerabilities).
• cross-plugin-drift.ts: OK (273 identical, 25 allowlisted).
• Twin byte-identity: the two agentcore.md copies are identical; a blast-radius grep across both trees found no stale copy of the old Identity value — this single Identity-dimension line was the only surface carrying it, so the edit is complete despite the pipeline's "blast radius unstable between runs" caveat.

Not verified

No live AWS / no console check of the portal — a factual doc claim verified against the primary announcement, which is the right bar here.

Net: accurate against the primary source, correctly scoped as an additive dimension update, byte-identical twins, gates green. Nothing to change.

[ayn-builds]

Separate follow-up, not this PR: architect-for-startups/references/agentcore.md:26 says AgentCore "doesn't scale to zero ... 1 vCPU / 2 GiB always-on," while this card says "$0 billing during I/O wait" (line 6) and "scale to zero" (line 25). Pre-existing, worth its own issue rather than widening this PR.

[ayn-builds]

The capability is accurate, but as written it is registered with neither freshness channel, and it drops the announcement's availability scoping.

The announcement scopes it: "This feature is available in all commercial regions where Bedrock AgentCore Identity is available." Commercial-only, so GovCloud is excluded. The card states it unqualified.

freshness.md:82-85 defines two verification paths: the main skill uses the volatile_facts entries from the winning runtime profile, and add-capabilities uses "the 'Hard limits' facts in the relevant service card (agentcore.md)". This edit sits in "Six dimensions" and adds no profile entry, so it is re-verified by neither path and never appears in the cached list in the footer. A GovCloud run therefore states an unavailable capability as settled fact. The Hard limits bullets already carry this exact shape of fact (line 36 launch regions, line 37 FedRAMP WIP).

Three changes, following the convention merged in #256 (43e7b81), which used ([AWS documentation](url); ... verified 2026-09-16.):

1/ This line:

Suggested change

	- Identity: built-in (free), OAuth via enhanced Identity — now includes a managed consent portal per Gateway, eliminating custom OAuth callback infrastructure for 3LO flows with third-party tools
	- Identity: built-in (free), OAuth via enhanced Identity — each Gateway gets a
	managed consent portal (hosted web client + credential provider list), removing
	custom OAuth callback infrastructure for 3LO flows with third-party tools
	([announcement](https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-bedrock-agentcore/);
	verified 2026-09)

2/ New bullet under ## Hard limits (verify via MCP — volatile), after line 37:

- Identity managed consent portal: all commercial regions where AgentCore Identity
  is available (2026-09) — not GovCloud; verify current list

3/ New entry in references/runtimes/agentcore.json volatile_facts. The profile's verification_key namespace already matches this PR's own commit title (agentcore.identity_oauth), alongside agentcore.instances_regions and agentcore.io_wait_billing, but no entry was added:

{
  "key": "identity_consent_portal_regions",
  "verification_key": "agentcore.identity_oauth",
  "value": "all commercial regions where AgentCore Identity is available",
  "verify_via_mcp": true
}

Neither agentcore.md nor runtimes/agentcore.json is on the cross-plugin-drift.ts allowlist, and both currently sit byte-identical across plugins, so all three edits need to land identically in the migrate copies or drift:check fails.

Minor and optional: the wrapped form above also matches the file's own style. The current single line is 176 chars while the Tool/Gateway bullet wraps at ~80 (lines 50-54). CI accepts either, since MD013 is disabled and dprint uses textWrap: maintain.

[leon1418]

Fixed in 95e3286; current head is aa9ba7a after updating the branch from main.

The Identity bullet now states the commercial-Region scope and includes the announcement and verification date. The same availability limit is in Hard limits, explicitly placing GovCloud outside that scope, and both runtime profiles now register identity_consent_portal_regions with verification_key agentcore.identity_oauth and verify_via_mcp: true. Both edited mirror pairs are byte-identical.

The update from main preserves its separate Registry freshness entry alongside the consent-portal entry. Local validation on the combined tree: 61 scoring tests per plugin (122 total), Markdown lint (894 files, zero errors), formatting on the four changed files, cross-plugin drift (273 identical, 27 allowlisted), and git diff --check passed. The PR diff against main remains limited to the four intended files.

GitHub CI for aa9ba7a is pending.

[ayn-builds]

Same three changes as on the advisor copy apply here. This file and runtimes/agentcore.json are not on the cross-plugin-drift.ts allowlist and are currently byte-identical across plugins (81bf49f6 and 228ed6db), so the region qualifier, the Hard limits bullet, and the volatile_facts entry all need to land identically on both sides.

[leon1418]

Applied identically in both plugin copies in 95e3286, retained in current head aa9ba7a: the commercial-Region qualifier and dated source, the Hard limits entry, and the runtime volatile_facts entry. Both service-card and runtime-profile pairs are byte-identical.

The main-branch update retains both the existing Registry verification entry and the new consent-portal entry. Local checks on the combined tree passed: 122 scoring tests, Markdown lint, formatting, drift, and whitespace checks.

GitHub CI for aa9ba7a is pending.

[ayn-builds]

Two findings on the new consent-portal fact, both scoped to the advisor/ copy - the migrate/plugins/migration-to-aws/... mirror needs the identical edit at the same line numbers. CI is green, but no test covers volatile_facts value types, so neither of these would be caught there.

[ayn-builds]

Cached value here is a prose sentence, where every sibling Region fact in this file is an array: instances_regions is [], regions is [], registry_regions is an explicit five-Region list. Two consequences.

First, per freshness.md step 4, this cached value is what gets used whenever the MCP isn't called or fails. As written it reads as unconditional availability in all commercial Regions, which is exactly the class of claim freshness.md's closing paragraph bars from cached values: "They cannot hard-eliminate a runtime and cannot support final pricing, availability, quota, or I/O-wait billing claims." The fallback path asserts the availability it's supposed to defer.

Second, it can't be resolved even in principle. It defers to AgentCore Identity's own Region list, and the regions fact two entries down is cached as [], so there is nothing to dereference. A reader of the fallback gets a promise instead of a list.

Also worth matching registry_regions, the closest precedent: it carries as_of and source. This entry has neither, so on fallback there's no snapshot date at the point of use, which the freshness-footer section explicitly asks for ("A cached number quoted in the body ... carries its own snapshot date at the point of use").

Suggest either an explicit Region array with as_of + source pointing at the announcement, or [] to mean "unknown, must verify" consistent with instances_regions. The prose belongs in the service card, not in a machine-read cached value.

[leon1418]

[🤖 AI review 🤖]

Fixed in 5b8f37b. Both runtime profiles now use value: [] for unknown cached Regions, with as_of: 2026-09-17 and the original announcement URL. The service card explicitly says the empty list means unknown, requires an intended-Region lookup in the consuming run, and keeps availability unconfirmed on fallback. The date/source describe the prior snapshot; no Region list or current-run AWS/MCP lookup is asserted.

Local validation: 61 scoring tests per plugin (122 total), a focused profile-loader/evidence probe, Markdown lint, formatting, cross-plugin drift, and git diff --check passed. The probe confirms cached metadata is not run-materialized evidence and unknown Regions do not eliminate AgentCore.

GitHub CI for this new head is pending.

[ayn-builds]

The "verified 2026-09-17" label marks a fact that is cached, not verified this run, and freshness.md's anti-fabrication rule scopes that word tightly: "a field may appear in the 'verified via MCP' list ONLY if you actually made an MCP call this run and observed its result."

The risk is concrete when combined with the cached value in runtimes/agentcore.json:61: a run that never calls the MCP reads this line, sees a verification date, and can copy the fact into the footer's "Facts verified via AWS Knowledge MCP" list, producing a Region-availability claim labeled MCP-verified on a run where no lookup happened. That's the footer's other template ("AWS Knowledge MCP not called this run; all facts are cached values") being bypassed by a date baked into the reference file.

Note this file already has wording for exactly this situation elsewhere, framing dated facts as snapshots to re-check rather than as verified. Suggest matching that, e.g. "snapshot 2026-09; verify current list", and keeping the announcement link as the source. The announcement does support the underlying claim, so this is about the label, not the fact.

[leon1418]

[🤖 AI review 🤖]

Fixed in 5b8f37b in both service-card copies. The baked-in label now reads snapshot 2026-09-17; verify current availability via MCP this run. The original announcement link and snapshot date are retained, and Hard limits now explicitly keeps availability unconfirmed without a successful lookup. This is cached source context, not evidence that the consuming run called MCP.

Both mirrors are byte-identical. Local validation passed: 122 scoring tests, the cached-versus-current-run evidence probe, lint, formatting, drift, and whitespace checks.

GitHub CI for this new head is pending.

[jkzietz]

Heads up: the aws-startup-advisor plugin has a new home

The plugin now lives in the Agent Toolkit for AWS, merged to main earlier today:
https://github.com/aws/agent-toolkit-for-aws/tree/main/plugins/aws-startup-advisor

We are beginning plans to deprecate this repository, so that's the copy to build on going forward — changes landed here won't reach customers once distribution repoints. Please re-open this PR against aws/agent-toolkit-for-aws.

Porting your diff: paths move from advisor/plugins/aws-startup-advisor/… to plugins/aws-startup-advisor/…. Two differences to expect:

• The plugin declares a single MCP server there — aws-mcp, the unified AWS MCP Server — and pricing is cache-only, with no live lookup.
• The destination enforces markdownlint's default rule set, which this repo does not. MD036 (emphasis used as a heading) and MD059 (descriptive link text) are the two that usually need fixing.

Happy to help with the move if anything doesn't map cleanly.