AWS package v1.1.0

An AWS SigV4 key pair for the commercial partition, held in the client's own secret manager. The stored material is the JSON signer-input document {"access_key_id":"...","secret_access_key":"...","session_token":"..."} (session_token optional; when present the connector sends X-Amz-Security-Token and includes it in SignedHeaders, so STS temporary credentials are supported). The credential block declares sign: aws-v4: the http connector signs each request with Signature Version 4 and never injects this material verbatim.

Malformed or incomplete key material is refused by name at registration and at execution, before any network call; there is no unsigned fallback. Key rotation and least-privilege IAM policy remain the deployment's responsibility, as does executor memory/log/crash hygiene around the resolved material.

Request signing, reviewed 2026-09-21: the authenticated form of every AWS API these endpoints belong to requires Signature Version 4 — a per-request HMAC-SHA256 computation over the canonical request derived from the secret access key, not a static header value. The http connector now performs it: the credential block declares sign: aws-v4, the connector derives the signing scope from the endpoint host (us-east-1/iam, us-east-1/ce; the S3 capability carries an explicit us-east-1/s3 scope because its shipped placeholder host derives none), signs with the stored key-pair document, and refuses — by name, before any network call — when the material is malformed, the scope is underivable, or the caller supplied signer-owned headers.

Every capability states sign: aws-v4 explicitly. The inject: header / inject_name: Authorization fields beside it name where the computed SigV4 Authorization header goes, which the validators require for this signing mode; they do not mean a stored header value is injected. There is no unsigned fallback and no verbatim injection of the key material. Signing limit: SigV4 is not a general execution-denial control — S3 GetObject can permit anonymous reads of publicly accessible objects, so an unsigned GET against a public object would succeed. The intended custody model for aws.s3.object.get therefore REQUIRES the registered bucket to be private, with authenticated access enforced by the bucket policy, the IAM principal's policy and S3 Block Public Access; do not rely on the absent signer to deny anything.

Read scope of the 1.0.0 capabilities: they cover the read and audit path — who exists (IAM users and roles), what the account posture counters say (GetAccountSummary: users, roles, MFA state, quotas), what money is being spent (Cost Explorer GetCostAndUsage), and controlled reads of objects under one declared bucket prefix. Every AWS operation not named here is excluded.

Apart from the Amazon Bedrock operations registered in 1.1.0 and described below, all write and control-plane operations (any IAM create/attach/delete, any S3 PutObject/DeleteObject, EC2 RunInstances, and every other mutating call across every service) are excluded from this pack; each action's tier must be reviewed on its own before any of them is registered; so are all other services and all other read operations not named here — including STS AssumeRole and GetCallerIdentity, Organizations, CloudTrail lookup, Secrets Manager and KMS data-plane reads, and S3 ListBucket/ListObjectsV2 — none of them is registered because this review did not scope them. Replace before enabling: OBJECT_KEY and OBJECT_PREFIX, plus the S3 endpoint and egress allowlist authority.

The shipped S3 endpoint uses the reserved .invalid authority aws-s3-bucket.s3.us-east-1.amazonaws.com.invalid so the unbound pack resolves nowhere; before enabling, substitute the documented virtual-hosted S3 shape https://BUCKET.s3.REGION.amazonaws.com/OBJECT_KEY for your bucket and region, and substitute the egress allowlist authority in step. The resource locator s3://BUCKET/OBJECT_PREFIX declares the intended scope but does not enforce a prefix: the concrete key binding at enablement and the AWS IAM policy on the principal (s3:GetObject limited to that prefix) must implement the restriction. Credential model: customer_vault is the only generally supported production custody here — identity_federation and customer_broker resolvers fail construction without a TokenIssuer or BrokerClient, and inline is lab-only.

The IAM principal behind the access key should carry only the read permissions these five calls need (iam:ListUsers, iam:ListRoles, iam:GetAccountSummary, ce:GetCostAndUsage, s3:GetObject on the one bucket prefix); scopes are chosen at AWS, not in this pack. Cost Explorer is served only from the us-east-1 endpoint per the API reference and the AWS General Reference (commercial partition). The S3 read is registered at R0, the read floor: the validators enforce the action floors, and shipped-pack discipline requires registration at those floors rather than below or above them; object content under a bucket prefix is uncontrolled data, so policy should raise this tier at install.

Partition scope: every endpoint and example in this pack is scoped to the commercial AWS partition (*.amazonaws.com); the China and GovCloud partitions and specialized S3 endpoint forms (access points, dual-stack, FIPS) need separate review before use. AAES has not been certified by AWS; these endpoints are configuration to review and test; the vendor has not endorsed it.

Amazon Bedrock administration (added in 1.1.0): thirteen capabilities on the Bedrock control plane bedrock.us-east-1.amazonaws.com cover model access (list models, read one model's availability, accept a model access offer), guardrails (list, create, update, delete), Provisioned Throughput (list, buy, delete) and model invocation logging (read, set, delete). The host is a real AWS endpoint. For another Region, substitute bedrock.REGION.amazonaws.com in the endpoint and the egress allowlist together; the connector derives the SigV4 scope REGION/bedrock from that host. The FIPS hosts (bedrock-fips.REGION.amazonaws.com) need their own review. These capabilities name a separate key-pair reference, secret-ref-aws-bedrock-admin-sigv4-key-pair, so the read-only IAM principal above never holds Bedrock write permissions. Give that principal only the bedrock: actions for the capabilities you enable.

Tiers sit at the floor of the declared actions. Accepting a model offer declares approve, buying Provisioned Throughput declares pay, and every delete is R3; these are irreversible actions and need a person. Updating a guardrail and changing the logging destination are R2 by the action floor, and policy should raise them where they protect production traffic. Every other operation in the Amazon Bedrock API index is excluded, among them GetUseCaseForModelAccess and PutUseCaseForModelAccess, ListFoundationModelAgreementOffers and DeleteFoundationModelAgreement, GetGuardrail, CreateGuardrailVersion and the enforced guardrail configuration operations, GetProvisionedModelThroughput and UpdateProvisionedModelThroughput, account data retention, resource policies, custom models and their deployments, marketplace model endpoints, prompt routers, inference profiles, Automated Reasoning policies, evaluation, customization, import, copy and batch invocation jobs, and tagging. Inference (bedrock-runtime), ApplyGuardrail, agents and knowledge bases are separate APIs and are not registered either.