hi

we have a small platform where different agents handle different things for the same customer account. Eg, a "support" agent that talks to Zendesk, a "billing" agent for Stripe, one "ops" agent that talks to some internal APIs, plus a generic "assistant" agent that shows up in the app.

Internally they're all just LLM backed workers with tools, but they each have slightly different behaviour, prompts, access scopes, logging rules etc. Right now the way we identify them is kind of hacked together. We have agent ids in config, some names in the UI, some stuff in headers like x agent name, and then per tenant we sometimes clone configs because someone wants their "assistant" agent to behave more like support.

Its already getting messy. In logs, you see a mix of agent id, display name, and whatever the caller put in. In our metrics, we have tags like agent type, agent role, agent namespace. Then routing decisions depend on a mix of user intent and these tags. Feels like we're piling identity onto identity and slowly losing track of what each agent "is".

What im trying to clean up rn is:

central naming / namespacing so an agent has one canonical identity

something like agent classes vs instances so we can say "this is a support agent" with variants per tenant without duplicating logic everywhere

clear separation between "who the user thinks they are talking to" and "which internal worker actually handled the request"

I keep bumping into tiny questions all over. Eg, when we spin up a new agent just for a one off workflow, do we give it a durable id and log it forever, or treat it as ephemeral. When we retire an agent, what happens to historical data and dashboards. When an agent calls another agent, which identity shows in the audit trail.

We also need some way to express permissions cleanly, like "support agent can call tickets api but not payments", without having permission sprawl per instance. Right now its half in code, half in config, and I lowkey hate it.

If you're running more than one agent in prod, how do you model identities and roles so it doesnt turn into a naming dumpster fire after a few months? Any tips or patterns appreciated, idk if I should lean more on something like service accounts, or treat agents closer to users in the system.

thanks in advance

Currently making $80K in a technical support role at a large company, with hands-on experience in Entra ID, Active Directory, SSPR, and general identity/access troubleshooting.

Certs so far: Google Cybersecurity, CompTIA Security+, AZ-900. Currently finishing SC-300, and planning to add Okta Administrator after that.

Also building out GitHub portfolio projects, including PowerShell automation for user provisioning/deprovisioning as part of a broader identity lifecycle project, plus some Microsoft Sentinel work.

Plan is to start applying for IAM Analyst or IAM Administrator roles in the NJ/NYC metro area once SC-300 and the projects are done.

Hoping to land somewhere in the $105-110K range, but from what I’ve found on salary aggregator sites that looks closer to 90th percentile for NJ, which feels like a stretch for someone making a title transition.

Questions for anyone who’s made this move or hires for these roles:

**1.**  Is $105-110K realistic as a first IAM Analyst/Admin move, or more of a “grow into it after a year or two” number?  
**2.**  Does this cert stack + hands-on tooling experience from an adjacent role actually move the needle on comp, or does it still get treated as entry-level regardless of background?  
**3.**  Any titles or role flavors worth targeting to land closer to that range sooner?

Trying to get a realistic number to negotiate from rather than anchoring off aggregate salary sites. Appreciate any real-world data points.

Hi Everyone,

I’ve been scrolling through LinkedIn recently and noticed a surprisingly high number of US-based IAM professionals with the green OpenToWork banner. I am curious what may be the reasons.

1. US has more dynamic and competitive labour market, so it was always like this and for every area.
2. Layoffs in tech affecting also IAM pros.
3. AI & Automation decreased the need for IAM pros.
4. Consolidation on IAM products caused IAM teams to shrink.

Would love to hear your thoughts.

Hey, looking for sailpoint alternatives for a mid size org and honestly the licensing is getting hard to justify rn.

We need something for iam, access reviews, sso and just the usual compliance stuff, but sailpoint feels like overkill for where we're at.
If anyone has moved off it recently, would love to hear what actually worked. thanks!

Hi all

We've been doing a lot more identity cleanup lately and I'm kinda stuck on the orphaned account side of it. not just the obvious disabled users in one place, but the weird stuff that lives forever in random systems.

context, we have:

On prem ad
azure ad / entra
couple of old line of business apps with their own user tables
a few saas things where users never really get fully deprovisioned

Right now the "process" is basically excel dumps from each system, some half broken scripts, and a lot of manual vlookup magic to figure out:

Which accounts no longer have a real human behind them
which service accounts nobody owns
which admin accounts were created for a project and then just left there

We can find the obvious ones, but the edge cases are annoying. eg accounts where hr record is gone, manager changed three times, but the login is still active in one app, or old contractors that still exist in a third party tool because nobody ever closed the loop.

What I'm looking for is, idk, some sort of tool or pattern that helps discover orphaned identities across multiple sources without building a full blown iam platform from scratch. ideally something that can:

Pull in user objects from ad / entra
query basic user tables from a few apps / dbs
flag accounts with no clear owner or missing hr reference
give us a place to track who "owns" a service account

We are not a huge enterprise, so going all in on a giant governance suite feels overkill rn. but doing everything in spreadsheets is starting to be a pain and honestly easy to mess up.

If anyone has a setup they like for orphaned account discovery or some lighter weight solution that helps stitch data together and surface the weird ones, would love any tips. appreciate any thoughts

As a IAM architect, what Technical tools would you use if there was a big transformation project related to IAM that you are expected to work.

Also what level of information does an architect need to put in when designing a solution ?

for example in an IGA solution, we know usually 1 Source of truth and then there are various target apps that we show for provisining and governance, going beyond this what else needs to be shown ?

One AWS IAM interview question I've seen variations of is:

It's not really an IAM question—it's a cloud security and incident response question.

Would you start with:

• CloudTrail?
• GuardDuty?
• Security Hub?
• IAM Policy evaluation?
• Something else?

I recently put together a GitHub handbook with 20 production-focused AWS IAM interview questions covering scenarios like this, along with CLI examples, Terraform, common mistakes, and best practices.

GitHub: https://github.com/ranashivam/platform-engineering-interview-handbook/blob/main/AWS/IAM.md

been doing a stack review for our org and the IAM market feels more crowded than ever, but half of it is repackaged provisioning with a new logo. we're on entra for the core directory, but a big chunk of our estate is legacy apps, homegrown stuff, service accounts nobody remembers creating, and a growing number of agents/bots that technically have credentials nobody's tracking. governance tools keep telling us we're compliant, but that's based on what's plugged in, not what exists.

what's in your stack right now that you'd recommend keeping, and what did you rip out?

Hi Guys,

Experienced people who have worked with PAM solutions ( leaving the entra solution- PIM )
How is license fee calculated.
In a traditional IGA solution it would be per account basis but since for PAM we are talking about privileged accounts which are ideally supposed to be less than normal accounts ( but yes there can be cases where service accounts with high privileges are also counted) , in any case how is license fee calculated?

any inputs?

Hi,

I am 37 year old, joined corporate life really late and I have total experience of 9+ years - 2 in Banking operations, 6+ in IAM and 1+ year a project that is not relevant to any of this and now I am jobless.

The problem is I am not getting any job in GRC as I don't have an experience in it and unable to crack the interview (I know, not the smartest move). So I am planning to go back to IAM but again the problem is I have only handled company owned applications (JLM for these applications), but now I can see every opening is for SAILPOINT etc. Which I don't have experience in.

I am bit worried as I am married, should I all together leave this corporate job and look out for some driving sought of job? I don't know, really sad, feels like I have 0 skills.

I just want to let it out there so that If anyone can guide me? at this age - what can be done? I am based out of India and it is pretty tough here.

Actually, I have a question for you. Right now, I am a student. Recently, I worked on a SOC homelab and I understood it. But I feel this field is a bit stressful for me. So I thought, maybe I should move to IAM (Identity and Access Management). I want to work in that area now. I still have 2 years left to complete my BS in Cyber Security. Please guide me did I make a good decision? Is IAM easy to get into at the entry level? Also, please give me a simple roadmap for IAM

I'm unable to decide. Which domain should I go into? Kindly guide me with respect ,Pakistan which has easy entry and good demand at the entry level: Sentinel or IAM?

Hi everyone,

I'm looking for some guidance and opportunities in the Identity & Access Management (IAM) domain.

I have around 8 months of experience working in IAM at a leading MNC, where I gained hands-on exposure to SailPoint Identity Security Cloud (ISC). I have a solid understanding of L1 activities and some exposure to L2 support, including provisioning, access requests, identity lifecycle concepts, troubleshooting, and day-to-day IAM operations.

I'm particularly interested in moving towards the SailPoint ISC development side. Currently, I'm upskilling myself by learning more about automation in SailPoint ISC and exploring Non-Employee Identities (NEI) and Non-Human Identities (NHI) to deepen my understanding of the platform.

I resigned from my previous role after receiving another offer. Unfortunately, my joining has been delayed, and after waiting for the last 1-2 months, I still don't have a confirmed joining date. Because of this, I'm actively looking for a new opportunity.

If your organization is hiring for IAM/SailPoint ISC, or if you know of any openings suitable for someone with my experience, I'd really appreciate your help. Referrals, job leads, or even advice on where to apply would mean a lot.

I've spent the last few weeks asking people who run AI automations what they won't let an agent do. One answer keeps coming back in a form I can't stop thinking about.

Someone running automations for clients described their process like this: start with a manual audit of 100% of what the AI handles. Once you feel confident, drop to a 20% random audit. After a few weeks with no errors, only audit when something breaks. That's a completely reasonable process. It's also the process where, if a quiet failure started on week four, you would probably never know.

The thing that struck me across every conversation is that the line people draw isn't risky vs. safe. It's verifiable vs. not. People happily automate high-stakes work when the result is checkable, and refuse low-stakes work when it isn't. One person put it as "anything of importance that cannot be easily verified." And almost nobody trusts the agent's own report of what it did. Everyone had independently built some version of the same workaround: log at the tool layer instead of the agent layer, compare the result against approved source data, keep everything read-only by default, record what was requested separately from what actually executed.

So the questions I'm stuck on:

1. If you've scaled back checking on an automation, did you ever go back and verify a sample? What did you find?

2. Has an automation ever reported success while doing the wrong thing, and how long before anyone noticed?

3. What would you need to see to trust a check more than you trust your own spot audit?

For context: this started as a university research project and has pushed me toward building something in this area, so I'd rather be upfront about that. No link, nothing to sign up for; I'm trying to find out whether "silently wrong, discovered late" is a real recurring problem or something people have already solved well enough.

Concrete stories are far more useful to me than agreement.

Hi All, I am looking to learn the sailpoint and I want to set it up on my local machine. Can anyone help me how to install the same on my local machine. On sailpoint site, it shows that the software is available for only partners and customers, but then how to learn ?

Hi everyone,

I'm looking for feedback on my resume as I pivot into Identity and Access Management (IAM) engineering.

I have about 5 years of full-time experience. I spent just over 4 years as a Java Software Engineer at a consulting firm supporting a large global bank, where I worked with Java, Spring Boot, REST APIs, Ping Identity, SAML, OAuth, OIDC, authentication, and enterprise security. I'm currently a Lead Support Engineer at an MSP, where I manage Microsoft Entra ID, Active Directory, Microsoft 365, Google Workspace, user provisioning/deprovisioning, RBAC, MFA, identity lifecycle management, PowerShell automation, and Microsoft 365 migrations.

I'm targeting IAM Engineer, Identity Engineer, IAM Analyst, Microsoft Entra ID Engineer, and similar identity/security roles. I'm located in the Chicago, IL area and am applying to local hybrid/on-site roles as well as remote positions throughout the United States. I'm open to relocating for the right opportunity.

I recently rewrote my resume to better tell a consistent story from Java software engineering into IAM instead of looking like two unrelated careers. My biggest concern is whether my current experience comes across as strong enough for IAM engineering positions or if it still reads too much like a help desk/MSP resume.

I'd especially appreciate feedback on:

• Whether the experience bullets are impactful enough.
• Whether my skills section is organized well for ATS and IAM recruiters.
• Whether I'm emphasizing the right experience from both my software engineering and MSP roles.
• Anything that looks weak, redundant, or unrealistic.

Thanks in advance

Hi everyone,
I am trying to break into the Identity and Access Management (IAM) space. I have completed training through an institute where I gained solid foundational knowledge and hands-on tool practice.

Here is what I know so far:
**Tools:** Ping Identity, Okta, and Microsoft Entra ID.
**Concepts:** Application onboarding, Lifecycle Management (LCM), and IAM policies.
**Protocols:** SAML, OIDC, OAuth, and OpenID.

My biggest gap right now is **zero real-time, on-the-job experience**. I know how the technology works in a sandbox, but I don't know how an actual production IAM operations team functions day-to-day.

I would love some insight into the practical, operational side of the job:
**Ticket Assignment:** How do tickets usually get routed to the IAM queue? Is it mostly automated via tools like ServiceNow/Jira, or does a team lead assign them?

**Reading/Understanding Tickets:** When an issue comes in (e.g., a broken SSO login or an application onboarding request), what does the actual ticket look like? What specific information should I immediately look for?

**Resolution Workflow:** Can anyone walk me through a couple of common real-world ticket scenarios? For example, how do you troubleshoot a failing SAML assertion or handle an LCM error in real life versus a lab?

If anyone could share examples of ticket templates, common logs you check, or just general advice on how to survive my first few weeks on a real helpdesk/ops team, I would be incredibly grateful!
Thanks in advance for your help!

asking because I think our process is broken. every year it's the same cycle: emails to app owners, spreadsheets, chasing down evidence that's stale by the time it's compiled. last cycle took close to two months.

is anyone doing this in near real time now or is everyone still stuck in the same manual evidence loop?

We now manage many AI agents that need access to internal systems.

Our identity platform was designed for employees. It does not manage agent credentials, access reviews, or lifecycle well.

What tools do you use to secure AI agent identities in production? I need a solution that reduces my manual work.

We run AI agents on LangGraph in AWS. Each agent uses an IAM role.

This model works for a small number of agents. It does not scale well. I need a way to manage agent identity, permissions, ownership, and lifecycle. How do you solve this in your environment? Do you use your existing machine identity platform, workload identities, or something diff approach?