Access key actions

[!caution]

This service is not deployed. There is no iam.shelfcs.com or sts.shelfcs.com in the published endpoint list, and no call on this page will answer. This page is the specification, not a description of something running.

For the identity system that does exist — the identity service users, one project, one role, and EC2 access keys — read Identity, as deployed.

Objective

Access keys are the credentials that sign API requests. These five actions issue them, list them, disable them, delete them, and tell you whether one is still in use.

Permissions

Action	Resource scope
iam:CreateAccessKey	user/<name>
iam:ListAccessKeys	user/<name>
iam:UpdateAccessKey	user/<name>
iam:DeleteAccessKey	user/<name>
iam:GetAccessKeyLastUsed	user/<name>

Called with no UserName, each acts on the calling identity — which means a credential able to call CreateAccessKey on itself can mint further credentials for itself. Scope this action deliberately.

Instructions

CreateAccessKey

Parameter	Type	Required	Notes
UserName	string	No	Defaults to the calling identity

Response

Element	Notes
AccessKeyId	Sent in the clear on every request thereafter
SecretAccessKey	Returned here and never again
UserName
Status	Active
CreateDate

<CreateAccessKeyResponse xmlns="https://iam.amazonaws.com/doc/2010-05-08/">
  <CreateAccessKeyResult>
    <AccessKey>
      <UserName>deploy</UserName>
      <AccessKeyId>AKIAIOSFODNN7EXAMPLE</AccessKeyId>
      <Status>Active</Status>
      <SecretAccessKey>wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY</SecretAccessKey>
      <CreateDate>2026-09-03T14:22:07Z</CreateDate>
    </AccessKey>
  </CreateAccessKeyResult>
  <ResponseMetadata>
    <RequestId>b1e2c3d4-5678-90ab-cdef-1234567890ab</RequestId>
  </ResponseMetadata>
</CreateAccessKeyResponse>

[!warning]

The secret is not stored in a form we can return. Support cannot retrieve it. If it is lost, delete the key and create another.

PROPOSED: two keys per user maximum. That limit is not arbitrary — it is exactly what makes zero-downtime rotation possible, and it is why the limit is two rather than one.

Not idempotent. A retry after a lost response mints a second key, and the first secret is unrecoverable. An automated caller should list keys before creating one.

Errors: LimitExceeded (409) when the user already holds two keys, NoSuchEntity (404).

ListAccessKeys

Parameter	Type	Notes
UserName	string	Defaults to the caller
MaxItems, Marker		Paginated

Returns AccessKeyId, Status, UserName, CreateDate for each key. Never returns a secret, because none is stored.

UpdateAccessKey

Parameter	Type	Required	Notes
AccessKeyId	string	Yes
Status	string	Yes	Active or Inactive
UserName	string	No

Deactivating is the reversible half of deletion, and it is the reason rotation is safe:

• An inactive key fails closed. Anything still using it breaks visibly, with InvalidClientTokenId, rather than continuing silently.
• It can be reactivated. Deletion cannot be undone.

PROPOSED: we publish the propagation time for a status change. A customer responding to an exposed key needs to know when the revocation is actually in force, and “eventually” is not an answer at that moment.

Requests already in flight and correctly signed will complete.

DeleteAccessKey

Parameter	Type	Required
AccessKeyId	string	Yes
UserName	string	No

Permanent. The key id is never reused.

Deleting a key that does not exist returns NoSuchEntity.

GetAccessKeyLastUsed

Parameter	Type	Required
AccessKeyId	string	Yes

Response: UserName, and a AccessKeyLastUsed structure with LastUsedDate, ServiceName and Region. LastUsedDate is absent if the key has never been used.

This action exists so that a key can be retired on evidence rather than on hope. It is the only way to answer “is anything still using this?”

PROPOSED: the value is updated asynchronously and may lag. We publish the bound, because a customer deleting a key relies on it: a stale timestamp is only evidence of disuse if the lag is much shorter than the observation window.

Rotation, in order

1. CreateAccessKey — a second key for the same user
2. Deploy it everywhere the old one is used
3. UpdateAccessKey with Status=Inactive on the old key
4. Wait, and watch for InvalidClientTokenId failures
5. GetAccessKeyLastUsed on the old key to confirm disuse
6. DeleteAccessKey

Steps 3 and 5 are the technique. Skipping straight to deletion turns a reversible mistake into an outage.

Go further

• Access keys
• User and group actions