Temp credentials still valid despite deleted the s3 access grant

The answer provided previously is partially correct regarding how AWS STS works, but it misses why your "Revoke Session" attempt didn't stop the access immediately. In short: As far as I understand it, deleting an S3 Access Grant prevents new credentials from being issued, but it does not invalidate existing ones. To stop active sessions, you must use IAM Policies with an explicit Deny or a strictly configured Revoke Sessions policy with a timestamp set to the current moment.

So, when you use the get-data-access call, S3 Access Grants acts as a vending machine for temporary credentials. Once these credentials (Access Key, Secret Key, and Session Token) are issued, they are stateless. The S3 service validates the signature of the request using the token itself; it does not "call back" to the Access Grant instance to see if the grant still exists for every single subsequent request.

Why your Revoke Policy might have "failed"

You mentioned adding a revoke session policy to myTestRole. In AWS, revoking sessions usually involves an inline policy that denies any request where the aws:TokenIssueTime is older than a specific timestamp.

Common reasons this doesn't work instantly with S3 Access Grants:

• IAM Consistency: IAM is eventually consistent. It can take a few minutes for a newly attached policy to propagate across all AWS regions and endpoints.
• Condition Mismatch: If the get-data-access call happened after you set the revocation timestamp (even by a few seconds), the token is considered "new" and valid.
• Scope of the Deny: If the Revoke Policy was attached to the role but the S3 Access Grant session was already active, ensure the policy explicitly includes a Deny on s3:GetObject and s3:ListBucket with the time condition

However, if you need to kill access immediately after deleting a grant, consider these steps:

1. Explicit IAM Deny (The "Kill Switch")

Instead of relying on the deletion of the grant, attach an inline policy to myTestRole that explicitly denies access to that specific prefix. A Deny always overrides an Allow, regardless of how the credentials were obtained.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::your-bucket/testproject",
        "arn:aws:s3:::your-bucket/testproject/*"
      ]
    }
  ]
}

2. Use a shorter duration-seconds

For high-security projects, reduce the duration of the get-data-access request. While the minimum is 15 minutes (900 seconds), this significantly narrows the "window of vulnerability" after a grant is deleted.

3. S3 Bucket Policy (Emergency)

As a last resort, adding the role ARN to a Deny statement in the S3 Bucket Policy will terminate access globally for that role instantly, as Bucket Policies are evaluated at the resource level during every request.

I reckon that's how AWS permissions work. It follows similar to STS. Consider the grant is valid for a session, once the session starts, you cannot revoke the permissions - it will expire after the session has completed. As an alternative, you can try

• setting a shorter expiry time like 15 mins (the permissions will remain valid for 15 mins though). Better for long run recurring situation.
• updating bucket policy to block the permissions. Better for one-off situations.