MonoCloud for Startups
One identity layer for your customers, APIs, and agents
Start new thread

MonoCloud for Startups - One identity layer for your customers, APIs, and agents

by
•
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.

Add a comment

Replies

Best
Maker
📌

Hey Product Hunt! 👋 Shivangi here, building MonoCloud with our founder Vishal .

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: 👈

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.

One platform for users APIs and AI agents sounds super convenient but how do you prevent single point of failure issues as workloads scale heavily?
Maker

 Fair thing to push on, since we sit in the critical path for auth. The main thing is that MonoCloud is at token issuance, not in front of every single API call. If you use JWTs, your services verify them locally against our published keys, so a blip on our side doesn't stop in-flight requests, already-valid tokens keep working until they expire. The real dependency is at issue and refresh time, and you tune token lifetimes to balance fast revocation against resilience. Reference tokens are the exception since they check with us on every call, that's the cost of instant revocation, so you reach for those only where you truly need it. On the workload side the SVIDs are short-lived and rotated by your own SPIRE rather than by us, and once a token is issued your services validate it the same local way, so your steady-state API calls don't depend on reaching MonoCloud on each one. If you want the platform reliability side specifically, the redundancy and uptime details, happy to walk you through that directly.

Maker

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: 👈

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.

Maker

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: 👈

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?

Honestly, right now it's the unglamorous version: a single Supabase service role key that our enrichment pipeline uses to call the Claude API and write back to the database. It works because it's the only "agent" we run today, but it's already the wrong shape that key can touch every table, not just the columns it needs to enrich. Where it'll break first for us: the moment we add a second automated process (say, something that also handles billing or subscription logic), we've got two different "agents" sharing one all-or-nothing credential. There's no scoping, no per-task revocation, no audit trail beyond generic DB logs. Right now "identity for agents" for us just means "hope the key doesn't leak," which isn't a real answer, it's a gap.
Maker

 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-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?

Maker

 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.

 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 identity is one of those problems that only looks simple until you have to build it yourself Really Building authentication and identity is never as straightforward as it seems Excited to see products taking a fresh approach here Congratulations to the team and hope you have a fantastic launch

Maker

 thank you so much. it always looks like a solved problem until you're actually in it 😄 really appreciate the support!

Interesting that mTLS with certificate-bound tokens is a first-class thing here rather than an enterprise add-on. Most CIAM tools treat that as an afterthought. What's the story for revocation latency — how fast does a revoked cert actually stop working in practice?

Maker

 Revocation is checked live at validation time, before a client can get or use another token, not left until the token expires. You've got live OCSP for status, CRLs, and a local deny list to block a cert outright. How fast it actually takes effect comes down to the cache windows you control on the trust store, OCSP status is cached five minutes by default and CRLs fifteen, and you can tighten those toward near-instant. The full set of mTLS validation and revocation settings is laid out here if you want it,

Is the SPIFFE workload identity tied to a specific runtime, or does it work across mixed environments (some services on Kubernetes, some on bare VMs)? Trying to figure out how much of my setup I'd have to standardize.

Maker

 Not tied to a runtime, it's SPIFFE-based, so anything with a valid SVID works, whether it's a Kubernetes pod or a workload on a VM. If they share a trust domain one trust store covers both, and if they're separate domains it's one trust store each. The setup walkthrough is here if it helps,

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?

Maker

 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 ( - 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 (
I'll be happy to walk you through the setup.

Amazing, the product looks so good, the tiers are so generous, so excited to try it out 🥳

Maker
 Thank you. Would love for you to try it and share feedback with us.
123
Next