Configuring AI agents access to AWS with OIDC/SSO

Here is the end state worth building toward: no agent in your fleet holds an AWS access key, every agent action against AWS-hosted infrastructure rides on access that expires in minutes, and the identity behind each action traces back to your OIDC/SSO identity provider. The agent never becomes an AWS principal. This post describes that target first, then the path to reach it.

The target end-state

In the finished setup the agent's identity comes from your OIDC/SSO provider, and a gateway in front of your AWS-hosted resources verifies that identity before granting a scoped, short-lived connection. The agent reaches a database on RDS, a cluster on EKS, or an instance through SSM, but it holds no AWS credentials and assumes no AWS role. The gateway authenticates itself to AWS with its own service identity. Nothing durable, and nothing AWS-shaped, lives in the agent. That is the picture to keep in mind while you wire it up.

Keep the two federations straight

The mistake that breaks an OIDC/SSO design for AWS is conflating two different federations:

• The agent to the gateway. The agent's identity is issued by your OIDC/SSO provider, for example Okta or Azure AD. hoop.dev is the relying party: it verifies the token, checks the issuer and audience, and reads group membership. This is the federation the agent participates in.
• The gateway to AWS. hoop.dev's gateway authenticates itself to AWS using its own IAM role. If the gateway runs in EKS, that role can be OIDC-federated through IRSA, so even the gateway holds no static AWS keys. This is hoop.dev acting as its own service identity, not the agent federating into AWS.

The agent never federates into an AWS IAM role and never runs an STS exchange. OIDC/SSO governs who the agent is into the gateway. The gateway, with its own identity, reaches the AWS-hosted resource.

How to reach it

1. Make your OIDC/SSO provider the source of agent identity and register hoop.dev as the relying party, so every agent connection carries a verifiable, provider-issued token.
2. Front the AWS-hosted resources with hoop.dev and give the gateway a scoped IAM role. Federate that role via OIDC (IRSA) where the gateway runs in EKS, so the gateway holds no static AWS keys either.
3. Scope the gateway's role to the exact actions and resource ARNs it needs to reach the resources it fronts. The role decides what the gateway can touch in AWS.
4. Write hoop.dev policy against the agent's verified identity. Map the OIDC group to specific connections, granted per session and expiring in minutes. This decides what the agent may reach through the gateway.
5. Close direct paths. Make the gateway the only route from the agent to AWS so the verification cannot be bypassed.

The reason this end-state is worth the setup is architectural. Federation moves trust from a stored secret to a verifiable, short-lived token, but only if the verification happens where the agent cannot tamper with it. If the agent holds AWS credentials and runs its own exchange, it can issue itself access on demand and the OIDC/SSO boundary stops meaning anything. Verification has to run at a point outside the agent. hoop.dev is built to be that point: a Layer 7 access gateway that consumes your OIDC/SSO provider as the relying party and reaches AWS-hosted infrastructure with its own service identity. The getting-started docs cover fronting an AWS-hosted resource, and the learn pages go deeper on the access model.

Verify you reached the end-state

Check the setup against the picture you started with. Confirm the agent holds no AWS access key by searching its environment and config. Trigger an action and confirm it succeeds through the gateway against the verified OIDC/SSO identity. Then force the failure case: present an expired or wrong-audience token and confirm the gateway refuses it. A federation that has only seen valid tokens has not been verified.

Pitfalls on the way

• Conflating the two federations. Believing the agent federates into an AWS role is the root mistake. The agent federates into the gateway through OIDC/SSO; the gateway reaches AWS as itself.
• Loose relying-party validation. A relying party that checks the signature without pinning the issuer and audience will accept a token minted for a different app. Pin both claims.
• A wide gateway role behind tight agent federation. OIDC/SSO decides which identity the gateway serves. The gateway's IAM role decides what it can do in AWS. A wide role behind tight federation is still wide.

FAQ

Does OIDC/SSO remove AWS access keys entirely?

For the agent, yes. The agent never holds an AWS key and never assumes a role; it reaches AWS-hosted infrastructure through the gateway. You can remove static keys from the gateway too by federating its IAM role via OIDC (IRSA), so AWS issues temporary credentials to the gateway rather than anyone storing a long-lived key.

Does the agent federate directly into an AWS IAM role?

No. The agent's OIDC/SSO identity is verified by hoop.dev, and hoop.dev reaches the AWS-hosted resource with its own service identity. The agent never assumes an AWS role or runs an STS exchange.

Do I still need a scoped role if the federation is tight?

Yes. OIDC/SSO decides which identity the gateway will serve. The gateway's IAM role decides what it can reach in AWS. Tight federation in front of a wide role still grants wide access, so scope both.

hoop.dev is open source. To reach this OIDC/SSO end-state in front of AWS-hosted infrastructure, start from the repository on GitHub.