An agent requests write access to a production DynamoDB table, and a human clicks approve in under three seconds without reading the request. That approval is technically a control and practically worthless. Approval workflows for AI agents on AWS only matter if the approval is a real decision with a real record, not a rubber stamp on a message that scrolled by.
So treat this as a checklist. Here is what an approval has to capture, where the decision has to run, and how to tell when the workflow is decorative.
What every approval must record
- Who or what requested. The named agent identity behind the request, not a shared role. If the approval cannot say which agent asked, the rest of the record is anchored to nothing.
- What was requested. The specific resource and action, scoped down to the table, cluster, or database and the operation, not a vague "production access."
- Why now. The task or context that drove the request, so an approver and a later reviewer can judge whether it made sense.
- Who decided. The approver identity and the decision, captured in the access record itself, not in a chat thread that nobody can later cite.
- What the grant became. The scope and lifetime that the approval issued, so the approval and the access it produced are one linked fact.
- What happened next. The session that ran under the approved grant, recorded so the approval can be checked against the actions it permitted.
Run an existing approval workflow against that list. The usual failure is the fourth and sixth items: the decision lived in a chat tool and the actions were never tied back to the approval, so you can prove someone said yes but not what they said yes to.
Where the approval decision has to run
A checklist of fields is not enough if the approval runs somewhere the agent can route around. The architectural requirement for approval workflows is that the decision sits in the access path, between the agent and the AWS-hosted resource, so an unapproved request cannot reach the resource at all. If approval is a notification the agent sends while it proceeds anyway, it is logging, not gating.
That is the line hoop.dev draws. The agent connects through hoop.dev, a Layer 7 access gateway, and a request for a sensitive scope is held at the gateway until policy or a person approves it. Only then does hoop.dev open the connection, reaching the AWS-hosted resource with its own scoped IAM role. The agent never becomes an AWS principal, and an unapproved request never becomes a live connection. The decision and the resulting session are recorded together on the gateway side. The getting-started docs show how to front an AWS-hosted resource, and the learn pages cover how approvals and recording are linked.