How to give a contractor temporary AWS access (without a permanent IAM user)
To give a contractor temporary AWS access, give them an IAM role to assume rather than a permanent user. AssumeRole hands out temporary security credentials that expire after a set session, scoped to what the task needs, and for an outside party you set an external ID so only they can assume it. The permanent IAM user is the common default, and it’s the one that gets left behind.
Why a permanent IAM user is the wrong default
Creating an IAM user and emailing the access keys is fast, which is why people do it. The cost comes later. When the engagement ends, that user is still in your account with live, long-lived keys, because deleting it was nobody’s job. Long-lived access keys don’t expire on their own, so a key handed to a contractor two years ago still works today unless someone removed it.
That’s the real risk with contractor access on AWS: not what they do during the work, but the standing credential that outlives it. An assumed role removes the problem, because there’s no permanent user and no long-lived key to forget.
Set up the assumed role
Create an IAM role scoped to exactly what the task needs, and let the contractor assume it. AssumeRole returns temporary credentials, an access key, secret, and session token, that stop working when the session duration ends. You control that duration, so you decide how long the window stays open.
For a third party, the trust policy is where the safety lives. Set a condition requiring an external ID, a value you share with the contractor, so someone else can’t trick your role into being assumed on their behalf. If the contractor is another AWS account or a SaaS vendor, this is the standard, expected pattern, and it keeps you from handing over any long-lived credential at all.
The simpler version: access that expires
The assumed role is the right primitive, and it’s also fiddly to wire up per contractor: the role, the trust policy, the external ID, the contractor’s side. For a one-off vendor it’s often more setup than the job warrants, which is exactly why people fall back to the permanent user they shouldn’t use.
The pattern underneath it is just-in-time access: access granted for a task, as short-lived credentials, that expires when the window closes. Same expiry guarantee, far less per-contractor setup. There’s no permanent account to forget, and no long-lived key ending up in the contractor’s shell history after they’re gone.
Where Korvalis fits
A contractor is working in an unfamiliar system, which is exactly where an honest mistake is most likely. Korvalis covers both halves of that risk on AWS: it hands out access that expires on its own, so vendor access is temporary by default with no IAM user left behind, and it watches the live session and cuts off a destructive command before it finishes, whoever’s behind it, an engineer, a stolen key, a contractor, or an AI agent. It installs inside your own AWS account. When the work wraps up, offboarding an engineer from AWS covers the credentials people forget to revoke.
Frequently asked questions
How do I give a contractor temporary AWS access? Give them an IAM role to assume. AssumeRole issues temporary credentials that expire after a set session, and an external ID on the trust policy keeps an outside party’s access safe.
Should I create an IAM user? Usually no. A permanent user with long-lived keys is the thing people forget to delete. An assumed role expires on its own.
What’s an external ID? A shared value a third party must provide to assume your role, which prevents someone else’s access being used to assume it. Use one for any outside party.
If temporary AWS access without a permanent user sounds right, see how Korvalis does it or join the waitlist.