v0.3.7

v0.3.7: report the response body as a streamed (gateway-capped) resul…

v0.3.6

v0.3.6: CloudTrail API action is the primary (Title) facet; iam_actio…

v0.3.5

v0.3.5: reorder compact activity-log row (resource, account), hide re…

v0.3.4

v0.3.4: facet descriptions/title/detail_only + report status (HTTP co…

v0.3.3

v0.3.3: build against clawpatrol v0.3.1 (slimmer SDK; go.sum 519->103…

v0.3.2

v0.3.2: build against clawpatrol v0.3.0

v0.3.1

v0.3.1: key the AssumeRole cache by session name

The cache was keyed by role ARN only, so credentials minted for one
session name were reused for any caller assuming the same role. The
Organizations resolver assumes the management-account role with session
clawpatrol-orgresolve; that cached entry was then reused for the agent's
own calls to that account, so CloudTrail attributed them to
clawpatrol-orgresolve instead of clawpatrol-<profile>. Include the
session name in the cache key so each session keeps its own credentials.

v0.3.0

v0.3.0: operation-name actions, IAM action facet, org-resolved names,…

v0.1.3

Restrict operation-as-path parsing to an allow-list of services

v0.1.2 recovered the operation name from a lone CamelCase request-path
segment for every service except an S3 deny-list. That is fail-open:
execute-api (path is the customer's API route) and mediastore (path is
an object key) are non-S3 services with agent-controlled paths, so a
request like `DELETE /GetThing` was parsed as action "GetThing", matched
the Get read prefix, and was auto-allowed — forging a read verdict on a
mutation and bypassing the approval gate.

Invert to a fail-closed allow-list (restJSONOperationServices, currently
just savingsplans): only services confirmed to put the operation name in
the path get path-operation recovery; every other service falls through
to "METHOD path" and is gated as a mutation. Add tests for the exploit
shapes (mutation method + read-prefix-named segment on execute-api /
mediastore / s3 / empty service) and for multi-segment/dot-segment
paths.

v0.1.2

Classify REST-JSON operation-as-path services as reads

REST-JSON services such as savingsplans name the operation in the
request path (`POST /DescribeSavingsPlans`) rather than in X-Amz-Target
or an Action parameter. parseAction fell through to `METHOD path`, so
`DescribeSavingsPlans` became `POST /DescribeSavingsPlans`, matched no
read prefix, and landed in the approval queue.

Recover the operation from a lone CamelCase path segment. S3 is excluded
(object keys are arbitrary and could forge a read verdict on a write; S3
reads are gated by HTTP method, not action), and only a single
CamelCase segment matches, so resource-path REST services (lambda,
route53, apigateway) with lowercase or versioned multi-segment paths are
untouched.