AWS Bedrock Agents

Amazon Bedrock reaches an outside capability two ways: an agent action group backed by an OpenAPI schema, or the AgentCore runtime speaking A2A. This platform generates both from the same registry the gateway checks at call time, so whichever you pick stays in step with what is actually enforced.

#Option A - an OpenAPI action group

curl -H "authorization: Bearer $TOKEN" https://app.authprior.com/api/orchestrate > priorauth.json

1. Attach the schema
   Create an action group on your Bedrock agent and give it priorauth.json as the API schema. Each registered agent becomes one operation, described in outcome terms rather than as a sequence of tool calls.
2. Back it with a Lambda, or an AgentCore Gateway target
   Bedrock invokes your handler; the handler forwards to AuthPrior with the channel token read from Secrets Manager. AgentCore Gateway can front the OpenAPI (or an MCP target) directly and hold the credential itself, without the Lambda.

#Option B - A2A through AgentCore

Register this platform as a remote A2A agent from its card at /api/agent-card. AgentCore discovers the skills and drives the task lifecycle; you still supply the channel identity.

#Two things that are not optional

1. Poll, do not retry
   An operation held at the release gate returns 202 with a task id. Bedrock's default is to retry a non-200 - which mints a duplicate authorization. The handler must treat 202 as "poll tasks/get", not as a failure.
2. The credential lives in the handler
   The channel token is a Secrets Manager secret the Lambda or gateway reads - never a value in the agent's instructions or model context. Bedrock authenticates as a channel principal bound to specific practices; a practice that has not authorised the channel is unreachable through it.

#What Bedrock should not be asked to do

• Approve or release anything - there is no operation for it.
• Enumerate practices - the spec exposes no listing.
• Poll faster than the payer moves - prior authorization is measured in days, not seconds.