Skip to content

02-use-cases/pay-for-api-agent: add AgentCore Payments Pay-for-API#1504

Open
ggChris2 wants to merge 1 commit into
awslabs:mainfrom
ggChris2:pay-for-api-agent
Open

02-use-cases/pay-for-api-agent: add AgentCore Payments Pay-for-API#1504
ggChris2 wants to merge 1 commit into
awslabs:mainfrom
ggChris2:pay-for-api-agent

Conversation

@ggChris2
Copy link
Copy Markdown

…e case

Strands buyer agent that pays autonomously for a metered HTTP API via AgentCore Payments. The seller is a Fun Facts API behind API Gateway + Lambda that returns HTTP 402 with an x402 payment requirement; the agent consumes the requirement, calls ProcessPayment via the AgentCorePaymentsPlugin, retries the request with the signature header, and returns the fact along with the dollar amount spent.

Includes:

  • Fun Facts seller (CDK + Lambda + x402 facilitator integration)
  • Buyer agent (Strands + bedrock-agentcore plugin)
  • Two credential providers (Coinbase CDP + Privy)
  • Four payment instruments (EVM + Solana per provider)
  • AgentCore Runtime deployment via CodeBuild (no local Docker)
  • AgentCore Memory wiring for per-user session continuity
  • CloudWatch + X-Ray observability with vended log delivery
  • Privy Wallet Hub frontend (vendored from privy-io/aws-agentcore-sdk, Apache-2.0) for user signing-delegation in the notebook flow

Notebook walks through cred-provider setup, manager + connector + four instruments, two sessions, four (provider, network) local agent runs, and a runtime deploy with the same four-run matrix.

Amazon Bedrock AgentCore Samples Pull Request

Important

  1. We strictly follow a issue-first approach, please first open an issue relating to this Pull Request.
  2. Once this Pull Request is ready for review please attach review ready label to it. Only PRs with review ready will be reviewed.

Issue number:

Concise description of the PR

Changes to ..., because ...

User experience

Please share what the user experience looks like before and after this change

Checklist

If your change doesn't seem to apply, please leave them unchecked.

  • I have reviewed the contributing guidelines
  • Add your name to CONTRIBUTORS.md
  • Have you checked to ensure there aren't other open Pull Requests for the same update/change?
  • Are you uploading a dataset?
  • Have you documented Introduction, Architecture Diagram, Prerequisites, Usage, Sample Prompts, and Clean Up steps in your example README?
  • I agree to resolve any issues created for this example in the future.
  • I have performed a self-review of this change
  • Changes have been tested
  • Changes are documented

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

@review-notebook-app
Copy link
Copy Markdown

Check out this pull request on  ReviewNB

See visual diffs & provide feedback on Jupyter Notebooks.


Powered by ReviewNB

@github-actions github-actions Bot added the 02-use-cases 02-use-cases label May 14, 2026
Comment thread 02-use-cases/pay-for-api-agent/agent/container/agent.py Fixed
Comment thread 02-use-cases/pay-for-api-agent/agent/container/agent.py Fixed
@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 14, 2026

Latest scan for commit: 033dd13 | Updated: 2026-05-15 21:12:10 UTC

Security Scan Results

Scan Metadata

  • Project: ASH
  • Scan executed: 2026-05-15T21:11:52+00:00
  • ASH version: 3.0.0

Summary

Scanner Results

The table below shows findings by scanner, with status based on severity thresholds and dependencies:

Column Explanations:

Severity Levels (S/C/H/M/L/I):

  • Suppressed (S): Security findings that have been explicitly suppressed/ignored and don't affect the scanner's pass/fail status
  • Critical (C): The most severe security vulnerabilities requiring immediate remediation (e.g., SQL injection, remote code execution)
  • High (H): Serious security vulnerabilities that should be addressed promptly (e.g., authentication bypasses, privilege escalation)
  • Medium (M): Moderate security risks that should be addressed in normal development cycles (e.g., weak encryption, input validation issues)
  • Low (L): Minor security concerns with limited impact (e.g., information disclosure, weak recommendations)
  • Info (I): Informational findings for awareness with minimal security risk (e.g., code quality suggestions, best practice recommendations)

Other Columns:

  • Time: Duration taken by each scanner to complete its analysis
  • Action: Total number of actionable findings at or above the configured severity threshold that require attention

Scanner Results:

  • PASSED: Scanner found no security issues at or above the configured severity threshold - code is clean for this scanner
  • FAILED: Scanner found security vulnerabilities at or above the threshold that require attention and remediation
  • MISSING: Scanner could not run because required dependencies/tools are not installed or available
  • SKIPPED: Scanner was intentionally disabled or excluded from this scan
  • ERROR: Scanner encountered an execution error and could not complete successfully

Severity Thresholds (Thresh Column):

  • CRITICAL: Only Critical severity findings cause scanner to fail
  • HIGH: High and Critical severity findings cause scanner to fail
  • MEDIUM (MED): Medium, High, and Critical severity findings cause scanner to fail
  • LOW: Low, Medium, High, and Critical severity findings cause scanner to fail
  • ALL: Any finding of any severity level causes scanner to fail

Threshold Source: Values in parentheses indicate where the threshold is configured:

  • (g) = global: Set in the global_settings section of ASH configuration
  • (c) = config: Set in the individual scanner configuration section
  • (s) = scanner: Default threshold built into the scanner itself

Statistics calculation:

  • All statistics are calculated from the final aggregated SARIF report
  • Suppressed findings are counted separately and do not contribute to actionable findings
  • Scanner status is determined by comparing actionable findings to the threshold
Scanner S C H M L I Time Action Result Thresh
bandit 0 0 0 0 0 0 1.0s 0 PASSED MED (g)
cdk-nag 0 0 0 0 0 0 28.9s 0 PASSED MED (g)
cfn-nag 0 0 0 0 0 0 48ms 0 PASSED MED (g)
checkov 0 0 0 0 0 0 5.4s 0 PASSED MED (g)
detect-secrets 0 0 0 0 0 0 961ms 0 PASSED MED (g)
grype 0 0 0 0 0 0 40.4s 0 PASSED MED (g)
npm-audit 0 0 0 0 0 0 173ms 0 PASSED MED (g)
opengrep 0 0 0 0 0 0 <1ms 0 SKIPPED MED (g)
semgrep 0 0 0 0 0 0 <1ms 0 MISSING MED (g)
syft 0 0 0 0 0 0 2.2s 0 PASSED MED (g)

@ggChris2 ggChris2 force-pushed the pay-for-api-agent branch 6 times, most recently from 1c5c0c4 to 70724dc Compare May 15, 2026 20:26
@github-actions github-actions Bot added 01-tutorials 01-tutorials and removed 02-use-cases 02-use-cases labels May 15, 2026
@ggChris2 ggChris2 force-pushed the pay-for-api-agent branch 5 times, most recently from b7023a0 to b12c144 Compare May 15, 2026 23:21
…d use case

Strands buyer agent that pays autonomously for a metered HTTP API via
AgentCore Payments. The seller is a Fun Facts API behind API Gateway +
Lambda that returns HTTP 402 with an x402 payment requirement; the
agent consumes the requirement, calls ProcessPayment via the
AgentCorePaymentsPlugin, retries the request with the signature
header, and returns the fact along with the dollar amount spent.

Includes:
  - Fun Facts seller (CDK + Lambda + x402 facilitator integration)
  - Buyer agent (Strands + bedrock-agentcore plugin)
  - Two credential providers (Coinbase CDP + Privy)
  - Four payment instruments (EVM + Solana per provider)
  - AgentCore Runtime deployment via CodeBuild (no local Docker)
  - AgentCore Memory wiring for per-user session continuity
  - CloudWatch + X-Ray observability with vended log delivery

The notebook clones the Privy Wallet Hub frontend from
privy-io/aws-agentcore-sdk on first run (Apache-2.0, jointly maintained
by Privy and AWS AgentCore) and drives its lifecycle inline. The
clone target lives under privy-delegation/ and is gitignored so it
never re-enters the repo.
@ggChris2 ggChris2 force-pushed the pay-for-api-agent branch from b12c144 to df9f4d0 Compare May 15, 2026 23:24
role=build_trigger_role,
timeout=Duration.minutes(15),
memory_size=128,
code=aws_lambda.Code.from_inline(
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nit] Can be a .py file

"""Pay for API — buyer agent CDK stack.

Provisions the full AgentCore Runtime stack for the buyer agent **without
requiring Docker on the machine running `cdk deploy`**:
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also - why did you need a Lambda to provision runtime? I understand to work around the need for docker (smart!) but it looks like it's possible doing it without a provisioner lambda?

https://aws.amazon.com/blogs/machine-learning/iterate-faster-with-amazon-bedrock-agentcore-runtime-direct-code-deployment/

@@ -0,0 +1,363 @@
#!/usr/bin/env bash
# setup-roles.sh — create the four IAM roles the notebook assumes into.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we still need this file if you've set up roles via CDK?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

01-tutorials 01-tutorials

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants