#Why Your Agent Sucks at IAM: Identity Is Not a Prompt

Day 3. 2:14 AM. Location: The deep end of the cloud security rabbit hole. My eyes feel like they've been sandpapered. The screen is burning a hole in my retina. The only thing keeping me going is a lukewarm energy drink and the absolute, raw fury I’m currently directed at an agent I built to "manage infrastructure."

It’s currently stuck in a boot loop. Why? Because it tried to revoke its own access token. It was trying to be secure. "Hey, I’m done with that aws-iam-create-role skill, I should clean up!" It deleted the very credential it needed to tell the system it was done.

It’s like watching someone saw off the branch they’re sitting on, screaming, "Look how efficient I am at forestry!"

I’ve been staring at this dashboard for six hours, and my fourth coffee has gone cold. I’m done. We need to talk. Your agent sucks at IAM. My agent sucks at IAM. We all suck at IAM because we are fundamentally, dangerously, wrong about what "identity" means to a machine.

#The Prompt-to-Permission Pipe Dream

We were all sold this dream, right? We’d just describe the security posture we wanted. "Build an agent that manages access, keeping it tight and least-privilege." The agent would look at the environment, look at its instructions, and—using the sheer, galaxy-brained power of inference—just know what to do.

It’s a lie.

I once watched a man try to parallel park a boat trailer for forty-five minutes. He’d get it halfway, the trailer would jackknife, he’d pull out, and try the exact same angle again. It was perfect preparation for configuring Kubernetes RBAC. And it’s exactly what your agent is doing when it tries to manage identity with a prompt.

Identity is not a suggestion. It is not a context window. It is a precise, deterministic, binary state. An agent either is authenticated as Principal X and has Permission Y, or it doesn’t. There is no gray area. There is no "vibe" of identity.

#Where the Hell Did My Token Go?

When you give an agent a broad instruction like "ensure all S3 buckets are public-read-disabled," and you don’t give it a specific IAM toolkit, it reverts to what it knows: making calls.

It’ll load a generic AWS skill pack. It might even pull something from the mlops-infrastructure-skills pack because it sees "infrastructure." But mlops-infrastructure-skills is built for deployment, not access governance. It has a skill like deploy-k8s-cluster. You are giving your agent a sledgehammer to fix a jewelry box.

So, the agent starts firing off API calls. "List all buckets." "Get bucket Acl." "Put bucket Acl." Where does the authorization come from? It’s probably in the environment variables (terrible idea), or a temporary credential it requested five minutes ago.

But what happens when the agent needs to create a new user?

It calls aws-iam-create-user. Okay, it creates the user. Now, what permissions does that user get? The agent, being "smart," infers that the user should have "the same access as the last guy." It then proceeds to copy a massive, overly permissive IAM policy, assigning it to the new user.

Anchor Sentence: An agent operating on inference for security is just a very fast, very obedient insider threat.

It’s creating a massive blast radius because it doesn’t understand the meaning of the permission. It only sees the text of the policy document. It doesn’t see the logical implications. It can’t. It’s an LLM. It’s a pattern-matcher. It isn’t a security architect.

#The Sane Solution: Granular, Deterministic Identity Skills

This is where the real work happens. This is where we stop pretending that prompts are a security layer.

We need identity to be part of the agent’s skill set. Not something that happens to the agent, but something the agent does. This isn’t a metaphysical argument. It’s a practical one. The agent must possess skills that are explicitly designed to handle identity: authenticating, assuming roles, generating scoped tokens, and verifying its own status.

This is the entire purpose of the identity-iam-agent-skills pack. This pack isn’t about managing infrastructure; it’s about managing the agent's relationship to that infrastructure.

It doesn’t just have generic skills like create-user. It has granular, deterministic operations. Instead of trusting the agent to copy a policy correctly, it has skills that are hard-coded to build and validate that policy based on precise input.

#The Contrast: High-Level vs. Granular

Agent Task	The Prompt-Based Sucking Way	The Deterministic SkillDB Way (`identity-iam-agent-skills`)
**Authenticate**	The developer puts a long-lived API key in an environment variable. Agent just uses it.	Agent uses `authenticate-oidc` to login with a non-human identity provider, getting a short-lived token.
**Get Access**	The agent has one "God-mode" IAM policy attached to it. It can do anything.	Agent uses `assume-role` to pivot to a specific IAM role (e.g., `S3DataReader`) only when needed for that specific task.
**Provision User**	"Create a new user like the last one." Agent copies an existing, likely flawed, policy.	Agent uses `create-user-from-template`, which uses a validated IAM template that has been pre-audited for least-privilege.
**Check Health**	"Make sure you’re still logged in." Agent tries to list S3 buckets. If it fails, it assumes it's logged out.	Agent uses `get-caller-identity` to receive a structured object confirming its current ARN, account, and user ID.

#Let’s Look at the Damn Code

This is what a sane agent looks like. It’s not just calling skills; it’s managing its own identity lifecycle as part of its execution loop.

We’re going to use a hypothetical agent runtime to show how this identity-iam-agent-skills pack gets loaded and executed.

// Load the specific identity management skills pack
await agent.loadSkills('skilldb/identity-iam-agent-skills');
// The agent needs to audit S3 buckets, so it needs temporary credentials for that specific account. // It doesn't use a global token; it explicitly assumes a role.
try {   const credentials = await agent.executeSkill('identity-iam-agent-skills/assume-role', {     roleArn: 'arn:aws:iam::123456789012:role/S3SecurityAuditor',     roleSessionName: AgentAuditSession_${Date.now()},     durationSeconds: 900 // Minimal time (15 minutes)   });
  // Now, the agent HAS the credentials. It can't infer them. They are data.   // It passes this data explicitly to the S3 skills, which are probably in another pack.   // The agent is now operating in that specific, limited security context.
  console.log(Now acting as: ${credentials.AssumedRoleUser.Arn});
  // It goes about its business (e.g., calling skills from an S3-specific pack).   // ... agent does its audit work ...
  // When the task is done, the agent doesn't just forget about it.   // It explicitly confirms its identity has reverted (or the session has expired).   // This is the check that my boot-looping agent failed to do.
  const currentIdentity = await agent.executeSkill('identity-iam-agent-skills/get-caller-identity');   console.log(Task complete. Current identity: ${currentIdentity.Arn});
} catch (error) {   // If anything fails—the assume-role, the audit—the agent can handle it.   // It has a structured error that it can use to determine next steps,   // rather than just crashing with a generic "Access Denied."   console.error("Identity management failed:", error.message);   // It could trigger an alert skill from the notification-services-skills pack,   // because that's a different domain (Technology & Engineering). }

This isn’t "prompt engineering." This is actual, deterministic engineering. We are treating identity as a first-class skill, not an afterthought. We are giving the machine the tools to manage its own security context in a way that is verifiable, auditable, and fundamentally safer than trusting it to "figure it out."

I’m going to try this new approach on my stuck agent. I’m giving it the assume-role and get-caller-identity skills. If it still tries to saw the branch off, at least it’ll have the decency to tell me which API call it was using and what its ARN was when it did it.

Stop prompting your security posture. Start equipping your agents.

Explore the thousands of deterministic, agent-first skills available on SkillDB and build a machine that doesn’t suck at identity. skilldb.dev/skills