A user gives an agent a task. Maybe it needs to read invoices, update a CRM record, check an internal dashboard, or call a few APIs on their behalf. The easy model is to let the agent act with whatever access the user already has.
But I am not sure that makes sense once the user has a lot of authority. If I can delete a workspace, change billing, export customer data, or invite an admin, does an agent helping me with one task need access to all of that too Giving the agent its own identity and narrower permissions sounds safer. But then another question comes up: how narrow can those permissions be before the agent keeps hitting boundaries halfway through the task?
So I am curious how teams building agents are thinking about this today.
Does the agent inherit the user s authority? Does it get its own identity with access only to specific APIs or actions? Or are you handling this another way? And where do you draw the line between the user is allowed to do this and the agent is allowed to do this for the user ?
Vishal — the step-up-before-high-risk-action line caught me. If an AI agent, not a human at a keyboard, is the one about to trigger something like a payment or a live bid submission, can step-up auth even work — or does that whole model assume there's a human around to re-verify?
MonoCloud for Startups
@medal411 Sharp catch. Classic step-up does assume a human is there to re-verify, so re-prompting a fully autonomous agent for a passkey doesn't make sense. Two things cover the agent case instead. When a human should sign off, you use human-in-the-loop consent, pausing the agent before the sensitive action and requiring a fresh approval. When it's genuinely autonomous with no human, you don't step up at all, you gate the action with policy, a Cedar rule that decides whether that agent, with that scope, is even allowed to trigger the payment, rather than re-verifying someone who isn't there.
As someone who built auth from scratch on Cognito (custom role injection, multi-tenant org isolation, MFA, OAuth flows) — I have strong feelings about this space. The pain is real, especially for startups that underestimate auth complexity on day 1. What's your migration story like for founders already locked into Cognito or Auth0?
MonoCloud for Startups
@rachid_abadli You clearly know the depth here, custom roles and multi-tenant isolation on Cognito is exactly what people underestimate on day one. The good news is you don't rip and replace. It's standard OAuth and OIDC, so MonoCloud runs alongside what you have and you move one surface at a time, and you bring your users across programmatically through our Create User endpoint, carrying their claims plus private and public data so their properties come over from Cognito.
Honestly I'd point you to our startup program. You get the full platform free for a whole year with all the premium features, and our team will be hands-on with the migration so we can help wherever you get stuck. Past that, you get to focus on building your product instead of auth and identity. You can fill out the form here, https://tally.so/r/ZjKMKB
MonoCloud for Startups
Hey Product Hunt 👋 Vishal here, founder of MonoCloud.
Every company is racing to put AI agents into production. Almost none of them can answer one simple question. When an agent does something it should not, who is accountable?
The log will say an agent did it. But an agent has no intent. Someone gave it that access, and today most teams cannot say who, cannot prove it, and cannot pull it back fast. That gap is the biggest unsolved problem in identity right now, and it is why I built MonoCloud.
I have built authentication into products four times over my career. Every time, the login box took a weekend and everything that mattered took months. Passkeys alone were over 800 engineering hours before they were production ready. I learned the hard way that identity is not a feature you bolt on. It is infrastructure, and it decides whether you can be trusted.
MonoCloud is that infrastructure. One platform for your customers, your APIs, and your agents, where you decide exactly what each can access, prove what it did, and revoke it in an instant.
Two convictions shaped it, and I still stand by both:
🔹 Build on open standards, not shortcuts. Authorization runs on Cedar, workload identity on SPIFFE, and trust on mTLS with certificate-bound tokens. Anyone can demo a policy dashboard. Far fewer hold up in a real security review.
🔹 Treat agents as first-class identities from day one. Every agent gets a scoped identity, acts on behalf of a user only within the limits you set, and leaves an audit trail you can revoke in one click.
All of it is live today. Ten design partners across SaaS and AI companies are building on it now.
👉 Startups get the full platform free for one year, every premium feature, no gates. Apply here: MonoCloud for Startups - Free for One Year 👈
If identity is core to what you are building, we are opening a few more design partner spots. Leave a comment or reach me on LinkedIn.
I will be here all day. The one thing I want to hear is this. How are you handling identity for your agents today, and what happens the first time one does something it should not?
Identity layer that covers customers, APIs AND agents in one place is actually pretty rare. Most solutions handles only one or two of those well. Free for a year is generous, what happens at the end?
MonoCloud for Startups
The customers/APIs/agents split is a nice framing. When I’ve seen auth projects drag, migration is usually the painful part. Do startups get a path to adopt one surface first, or is it meant to replace the stack in one go?
MonoCloud for Startups
@xiaosong001 Yes, one surface first is exactly how it's meant to go, no big-bang replacement. Because it's standard OAuth and OIDC, MonoCloud runs alongside your current setup, so you can start with a single piece, customer login, or just your API auth, or only the agent side, and expand from there. Users come across programmatically through our Create User endpoint, carrying their claims plus private and public data, so you're not rebuilding profiles.
And if you're early, I'd point you to our startup program. You get the full platform free for a year with all premium features, and our team gets hands-on with the migration so you're not doing it alone. You can fill out the form here, https://tally.so/r/ZjKMKB
MonoCloud for Startups
Hey Product Hunt! 👋 Riya here. I do product marketing at MonoCloud, and I am one of the makers.
Most of my week is spent talking to founders about auth, and I keep seeing the same arc. In the beginning nobody wants to think about it, so they drop in a login box, ship, and move on.
Six months later, those same people are drowning in it.
A customer wants SSO.
A security review shows up with forty questions.
Their services need to talk to each other safely. And their AI agents are now acting on behalf of users with no real control over what they can reach.
The reason it keeps happening is that most identity tools were built for one slice of the problem.
The easy ones stop at the login screen.
The enterprise ones are powerful but slow and expensive to adopt. So teams end up owning the hard middle themselves, which is the exact part they have no time to build.
MonoCloud covers all of it on one platform, your customers, your APIs, and your agents, from your first user to enterprise scale. Not just who signs in, but what every user, service, and agent is allowed to do afterwards, with the ability to prove it and pull it back in an instant.
All of it is live today, not a demo or a waitlist. Ten design partners across SaaS and AI companies are already building on it.
👉 If you are a startup, you get the full platform free for a year, every feature, no gates. Apply here: MonoCloud for Startups - Free for One Year 👈
And if identity is central to what you are building and you want to shape where this goes, we are opening a few more design partner spots. Leave a comment or reach me on LinkedIn (link in profile).
I will be here all day and would genuinely love to know how you are handling identity for your AI agents right now, and where it falls apart first. That is the conversation I care about most.
This is the unglamorous part that makes agent work production-safe. Small teams often start with one all-powerful service key because it ships fastest, then the second or third automated process turns that shortcut into real operational risk. Per-agent identity plus fast revocation is the boring layer that lets you delegate without pretending the risk disappeared.
MonoCloud for Startups
@krekeltronics Exactly this. The one all-powerful key is where almost everyone starts because it ships fastest, and it stays invisible right up until the second automated process has to share it. Scoped identity per agent plus revocation you can actually trigger is what makes delegating feel safe instead of just hoping. Well put.