aws v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-aws-sigv4-access-key-pair

Custody

customer_vault

Injection

header (Authorization)

An AWS access key ID and secret access key pair for a dedicated least-privilege IAM principal, held in the client's own secret manager under this reference. Be exact about what this reference is: a PROPOSED signer-input contract for a future signing-capable connector, not material for the current connector's verbatim Authorization injection. Do NOT feed the raw key pair to the current http injector — it would inject the stored value as a static header, which cannot produce a SigV4 signature, would fail authentication, and would expose the secret access key on the wire. When SigV4 wiring lands, the stored-material format needs fresh review (under signing, the signer computes the Authorization header per request, so 'key pair vs. complete header value' changes meaning), along with the principal's read-only policy, key rotation, and session-token handling: temporary (STS) credentials additionally require an x-amz-security-token on the signed request, a path no reviewed connector supports today, so long-term keys are assumed until that path is reviewed. None of these signing features exists now, and nothing in this note claims they do. Executor hygiene for the day wiring lands: key material must live only in executor memory for the duration of signing, must never appear in logs, and must be scrubbed on crash paths.

• aws-iam-account (api, pii): https://iam.amazonaws.com/doc/2010-05-08/
• aws-billing-account (api, financial): https://ce.us-east-1.amazonaws.com/
• aws-s3-bucket-prefix (bucket, internal): s3://BUCKET/OBJECT_PREFIX

WIRING GAP, stated plainly: the authenticated form of every AWS API these endpoints belong to requires Signature Version 4, which is a per-request HMAC-SHA256 computation over the canonical request (method, URI, query, signed headers, payload hash, timestamp) derived from the secret access key — it is not a static header value. The http connector (aaes/internal/connectors/http_executor.go + inject.go) applies custody by injecting one stored value verbatim into a header, query parameter or body field; it has no signing step, no notion of a region/service signing scope and no x-amz-date handling, so it cannot perform SigV4. A shared SigV4 signer exists in-tree at aaes/internal/surface/awsv4/awsv4.go, but it serves the native integrations (WorkSpaces, Connect, SES, KMS, Secrets Manager, Security Lake) and is not reachable through the http connector that this pack format wires. Until the http connector (or an AWS-specific connector) exposes that signer, NO capability in this pack can actually execute: the reads below are registered as the reviewed surface only. Do not install it expecting a working call; an install today registers the intent and the review, not a runnable integration. ONE QUALIFICATION on the signing claim above: 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. WHY THIS BOUNDED SET: the first thing an agent governance layer needs from a cloud account is 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. DOCUMENTED EXCLUSIONS: everything else AWS exposes is deliberately out. 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. PLACEHOLDERS to 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 (aaes/internal/custody/federation.go, broker.go), 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 verb 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 a reviewable default, not a vendor guarantee.

Review completed: 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUsers.html (retrieved 2026-09-21)
• https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRoles.html (retrieved 2026-09-21)
• https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccountSummary.html (retrieved 2026-09-21)
• https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API_GetCostAndUsage.html (retrieved 2026-09-21)
• https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html (retrieved 2026-09-21)
• https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv-create-signed-request.html (retrieved 2026-09-21)
• https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/Welcome.html (retrieved 2026-09-21)
• https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/CommonParameters.html (retrieved 2026-09-21)
• https://docs.aws.amazon.com/general/latest/gr/rande.html (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.