Launching today
MonoCloud for Startups
One identity layer for your customers, APIs, and agents
212 followers
One identity layer for your customers, APIs, and agents
212 followers
MonoCloud is one identity layer for your customers, your APIs, and your agents. Most tools stop at a login box. We go past login into authorization and accountability: decide exactly what every user, service, and AI agent can access, prove what it did, and revoke it in an instant. Fine-grained Cedar authorization, passkeys and SSO, API protection, M2M, and mTLS with certificate-bound trust, all on one platform. Startups get the full platform free for one year.
Hey Product Hunt! 👋 Shivangi here, building MonoCloud with our founder Vishal @monocloud.
Auth always looks finished the day login works, but it never is. A customer asks for SSO. Your services need machine-to-machine keys. RBAC roles stop being able to express what you actually need. And now AI agents are acting on behalf of your users, and nobody can say what they are allowed to touch. Each piece gets bolted on separately, and a year later "auth" is five half-built tools held together with glue.
We built MonoCloud so you do not do that. It is one identity layer for your customers, your APIs, and your agents. Login is table stakes. The part that matters is what happens after: you decide exactly what every user, service, and agent can access, prove what it did, and revoke it in an instant, before an agent is ever issued a token.
Most tools make you pick a side. The login-box platforms stop at the sign-in screen. The enterprise suites are powerful but heavy and built for large companies only. MonoCloud is the one platform that covers customer identity, API protection, and agent identity together, from your very first user all the way to enterprise scale.
What you can do with it:
🔐 Every way your customers sign in: passwordless, passkeys, OTP, social, and SSO, ready on day one
🧩 Fine-grained authorization with Cedar, applied at the token, not just roles that stop being granular the moment your app grows
🤖 Identity for AI agents and workloads, with scoped access, on-behalf-of delegation, M2M, and SPIFFE, so an agent can only ever do what you allowed
📜 Certificate-bound trust and mTLS with instant revocation, plus full audit logs, so you can prove who did what and cut off access the second you need to
🛡️ Step-up authentication that forces fresh verification before high-risk actions like payments, transfers, or admin changes, plus attack and brute-force protection built in
We are building with 10 design partners across SaaS and AI companies right now, and their feedback is shaping what ships next. If identity is core 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 here, or reach me on LinkedIn, and I will follow up.
👉 For the Product Hunt community, startups get the full MonoCloud platform free for one year, every premium feature, no gates. Apply here: https://tally.so/r/ZjKMKB 👈
We will be here all day. The one thing I would really love your feedback on: how are you handling identity for AI agents right now, and where does it break first? That is the piece we are building hardest, and honest answers help us more than any upvote.
I am happy to get into anything, the product or the roadmap.
The agent-on-behalf-of-user piece is what most auth stacks punt on, so going straight at it with Cedar is the right call. Concretely: when an AI agent acts for a user, is its access always a downscoped subset of that user's own permissions (so it can never exceed what the human could do), and can you express that delegation in a single Cedar policy? And if you revoke mid-task, does an already-issued agent token stop on the next call or only at expiry?
MonoCloud for Startups
@hazy0 Good question, this is exactly what our API Access Policies are built for. Cedar runs at token issuance (the IssueAccessToken action), so it gates what the agent can get: which API, which scopes, which token settings.
Downscoping: yes, as a ceiling you author, default-deny, and forbid overrides permit. The agent is the principal, the user rides along as context.user, and requested scopes come in as context.requested_api_scopes, so a single permit can require that a real user is present, that the user is in an eligible group, and that requested scopes never exceed the ceiling you set.
Mid-task revocation depends on token type. Reference (opaque) tokens are checked against server state on every call, so revocation is immediate, the next call fails. JWTs are self-contained and live until exp. For agents that need instant revocation: set AccessTokenType = Reference, keep lifetimes short, and optionally BindTokensToSession so ending the user's session kills the agent's tokens too. Policies are re-evaluated on every issuance and refresh either way, so pulling the agent's permit stops new tokens at the next refresh — only already-minted JWTs survive to expiry.
Happy to walk through your exact agent setup on a call.
@maganuk That’s the tradeoff I was after — Reference for instant revocation, JWT for speed, and permits re-evaluated on refresh. The operational worry with Reference for agents: a high-frequency loop can fire hundreds of calls, so does each one introspect against MonoCloud’s servers, or is there short-TTL introspection caching so I’m not adding a round-trip per tool call? And does BindTokensToSession revoke synchronously, or is there propagation lag before the next call fails?
Congrats on the launch - it's an impressive offering!
I'm curious how MonoCloud tracks the agent acting on behalf of the user - is the agent treated as a separate identity?
And can I use Cedar to manage access to application-level entities? How does that work in practice?
I'm currently using Clerk, whose separation between development and production environments makes it easy to copy the configuration to production when launching. Do you offer a similar workflow or support migrations from other authentication providers?
MonoCloud for Startups
@mateuszkonik Yes, the agent is treated as a separate identity. It doesn't reuse the user's token. The agent obtains its own token to act on behalf of the user, so agent activity is always distinguishable from the user acting directly. Cedar comes in at token issuance: each API (a resource client in MonoCloud) can have multiple Cedar policies attached, and whenever that API is requested via the authorization or token endpoint, all of its policies are evaluated first. A token is issued only if every policy passes, so access to an API is gated by policy right at issuance. As for migrations, you can bring users over programmatically via our Create User endpoint (MonoCloud - Authentication Platform for Developers | SSO, Passkeys & Next.js - you can use user claims, private data and public data fields to capture all of the users properties from your current provider. Happy to dig into any of this further, and there's a lot more detail in the docs (https://www.monocloud.com/docs).
I'll be happy to walk you through the setup.
First of all a great congrats to @riya_pariyar @roguetink @maganuk
I am just curious that you've said you're building the auth layer for agentic products "from the ground up" instead of bolting agent support onto human auth. Concretely, what does a token look like when an agent calls another agent three steps downstream? How do you actually scope and audit that so the blast radius doesn't become "every permission that token ever carried"?
@arduvey29 Thanks! A token never inherits permissions, it's decided fresh at every issuance under default-deny, and you can forbid a sensitive API from ever sharing a token with others, so a token can't quietly widen to reach something it shouldn't. Tokens issued over mTLS, including X.509 SVIDs, are certificate-bound, so a copy is useless without the matching cert. If you want to see how that's written, there's a full guide with example policies at monocloud.com/docs/guides/api-access-policy
@thys_beesman You are right that it is already the wrong shape. A single service role key with full reach is where almost everyone starts, so you are in good company.
The second process is where it really starts to hurt. Once a billing job and an enrichment job are sharing one credential, a leak means you cannot even tell which one did what, and you end up rotating the key on both.
The way we think about it, each process should get its own scoped identity instead of everyone leaning on one key. You give that identity a policy for what it is allowed to do, so the enrichment worker can only enrich and the billing worker can only touch billing. If one of them is ever compromised, you revoke just that identity without taking the others down, and every action is logged against that specific agent instead of getting lost in generic DB logs.
I am curious, are these long-running services or short-lived jobs, and where do they run, somewhere like Kubernetes, Fly, or Railway? That is what will decide whether workload identity with SPIFFE or short-lived machine-to-machine tokens is the cleaner path for you.
the agent-as-a-separate-identity model is the right architecture, and Cedar for token-issuance policy is a solid choice over roles that stop scaling. the question I didn't see answered yet is the business side of the free year: what does year two actually look like pricing-wise for a startup that's grown into real usage by then, is it a predictable seat/request-based scale-up or more of a cliff where the free tier suddenly becomes an enterprise sales conversation? that's usually the thing that decides whether teams migrate off something core like identity later out of pricing fear rather than product fit.
@galdayan Fair question, and the right one to ask about anything as sticky as identity. There's no cliff. When the free year ends you move onto our standard published plans, not into an enterprise sales conversation, so it's a predictable, self-serve scale-up rather than a renegotiation. We kept the step up gradual on purpose, because a team that grew on us for a year and then churned over sticker shock would mean we got pricing wrong. If the jump ever looks steep for where you are, reach out before the year's up and we'll sort it out. The whole point of the free year is to take pricing off the table as a reason to ever leave something this core.
@roguetink predictable self-serve scale-up is the right answer, and saying it out loud (rather than leaving it as a sales-team surprise later) is what actually removes the fear. the 'reach out before the year's up' safety valve is a nice touch too - it means the free year is a real onboarding gift, not a bait-and-switch clock. appreciate the straight answer.
Everything in the thread assumes a human kicked the agent off. A good chunk of what I run is on a cron, hourly, nobody logged in, so there is no session to ride along as context.user, and that is exactly where "on behalf of" gets slippery: the agent is acting for an intent someone wrote down three weeks ago, not for a person who is awake to notice. Does that shape get its own principal, or does it collapse into a machine client with a service identity and you lose the delegation trail?
@dipankar_sarkar When there's no human, there's no user in the request. Machine-to-machine grants carry no user context, so the agent authenticates as its own principal, an agent client or a SPIFFE workload, not an anonymous session, and what it's allowed to do is set by policy on that identity. The grant-type and context detail is all written up here if you want it, monocloud.com/docs/guides/api-access-policy